View Full Version : [generale] la programmazione è un'attività scientifica o morale?
mad_hhatter
21-05-2009, 17:30
apro questo thread in seguito a una proposta avanzata in un'altra discussione (http://www.hwupgrade.it/forum/showthread.php?t=1985932).
la questione è questa:
E' che l'altro giorno ho riletto "Extreme Programming" di Beck e m'è venuta la solita incazzatura, ho visto quel "semplice" e non ho più resistito.
Il problema è sempre quello: l'informatica è una questione di quantità, non di qualità. Le cose sono zero, uno o mille, non sono "belle", "brutte", "facili", "difficili".
Tutte cose di cui già vaneggiai in altro notorio thread :D.
Immaginavo che fosse quello il pomo della discordia, ma volevo esserne sicuro. :D
Però, se ricordi, nessuno ha mai parlato di teorie, quanto di "best practices" dettate dall'esperienza e da prove empiriche. :fagiano:
Un po' come dire: "la programmazione a oggetti aiuta a scrivere codice migliore". E' un'affermazione puramente empirica, e come tale criticabile:
"Object-oriented programming is an exceptionally bad idea which could only have originated in California." --Edsger Dijkstra.
Inizio la discussione dicendo che mi trovo in disaccordo con PGI-bis: la programmazione è un'attività con una fortissima componente umana e creativa e, in quanto tale, non può essere ridotta a una mera questione quantitativa. Inoltre, la qualità del codice (misurabile attraverso un insieme di metriche - non universalmente accettate), ha ripercussioni quantitative evidenti.
magix2003
21-05-2009, 18:46
Il problema è sempre quello: l'informatica è una questione di quantità, non di qualità. Le cose sono zero, uno o mille, non sono "belle", "brutte", "facili", "difficili".
E' vero come tutte le discipline scientifiche lo scopo dell'informatica è quello di raggiungere uno scopo, un risultato.
Questo preambolo, però, non significa che non ci possano essere dei modi migliori rispetto ad altri per raggiungere un obbiettivo.
Se prendiamo in considerazione la matematica, un teorema può essere dimostrato in diversi modi, però noi alla fine impariamo quella considerata più semplice.
Nello stesso modo se dobbiamo sviluppare un'applicazione che svolge un compito ci sono miliardi di possibili soluzioni, ma alla fine cerchiamo di utilizzare best practices e design patterns che offrono delle soluzioni standard che siano più comprensibili anche ad altri.
^TiGeRShArK^
21-05-2009, 19:01
Programmare è un atto prettamente creativo.
Ridurla ad un insieme di uno e di zero è sminuirla, esattamente come ridurre le eleganti dimostrazioni matematiche ad una mera sequenza di numeri.
E come ogni cosa creativa, o artistica, imho è anche possibile giudicarne la bellezza ,esattamente come in certi teoremi (che però non è facile che apprezzino tutti.. :stordita: )
la programmazione è un lavoro :D
Quella ad oggetti, raccontandola come la dice il mio docente: è un metodo inventato per riusare vecchio codice e non reinventare l'acqua calda :stordita:
Energy++
21-05-2009, 20:26
secondo me il discorso della qualità del codice oggi è molto relativo...
la programmazione ad oggetti grazie al riutilizzo del codice ci ha permesso di trascurare questo fattore in quanto non dobbiamo più preoccuparci di creare gli algoritmi ex-novo... la maggior parte sono gia li belli e pronti.
Quindi il fattore qualità è determinante solo all'inizio, successivamente dominerà il fattore quantità.
tutto questo IMHO e :fagiano:
mad_hhatter
21-05-2009, 20:44
la programmazione è un lavoro :D
Quella ad oggetti, raccontandola come la dice il mio docente: è un metodo inventato per riusare vecchio codice e non reinventare l'acqua calda :stordita:
ecco come sminuire la programmazione ad oggetti e non trasmettere assolutamente nulla agli studenti.
mad_hhatter
21-05-2009, 20:46
secondo me il discorso della qualità del codice oggi è molto relativo...
la programmazione ad oggetti grazie al riutilizzo del codice ci ha permesso di trascurare questo fattore in quanto non dobbiamo più preoccuparci di creare gli algoritmi ex-novo... la maggior parte sono gia li belli e pronti.
Quindi il fattore qualità è determinante solo all'inizio, successivamente dominerà il fattore quantità.
tutto questo IMHO e :fagiano:
le librerie non nascono con l'OOP. L'importanza del paradigma OO è ben al di là del mero riutilizzo del codice
ecco come sminuire la programmazione ad oggetti e non trasmettere assolutamente nulla agli studenti.
non credo che sia sminuire: l'idea iniziale è stata quella del riutilizzo, poi sono nate altre esigenze
mad_hhatter
21-05-2009, 20:53
secondo me il discorso della qualità del codice oggi è molto relativo...
la programmazione ad oggetti grazie al riutilizzo del codice ci ha permesso di trascurare questo fattore in quanto non dobbiamo più preoccuparci di creare gli algoritmi ex-novo... la maggior parte sono gia li belli e pronti.
Quindi il fattore qualità è determinante solo all'inizio, successivamente dominerà il fattore quantità.
tutto questo IMHO e :fagiano:
ok, ma si scrivono pezzi di codice nuovo tutti i giorni, risolvendo problemi nuovi. Gli algoritmi noti in letteratura non esauriscono le necessità di programmazione in nessun ambito: sono una base di partenza per qualcos'altro. E il problema non è nella scrittura di algoritmi (che sono pezzi di codice tutto sommato di piccole dimensioni e che quindi pongono pochi problemi nell'ambito della gestione del progetto). La sfida sta nei sistemi (software) di grandi dimensioni per cui è necessaria una squadra di sviluppatori e di altre persone con competenze eterogee (e che possono non c'entrare con la programmazione vera e propria). E' in questi casi che entra pesantemente in gioco il fattore umano e la qualità (del codice, dell'ambiente di lavoro, dei rapporti umani, e via discorrendo) diventa ben più importante della quantità.
mad_hhatter
21-05-2009, 20:55
non credo che sia sminuire: l'idea iniziale è stata quella del riutilizzo, poi sono nate altre esigenze
ripeto: il riutilizzo del codice non nasce con l'OOP. Le motivazioni che hanno portato alla OOP sono tutt'altre e hanno a che fare, tra l'altro, proprio con il fattore umano.
ripeto: il riutilizzo del codice non nasce con l'OOP. Le motivazioni che hanno portato alla OOP sono tutt'altre e hanno a che fare, tra l'altro, proprio con il fattore umano.
cito solo una parte dell'articolo e ce ne sonon tanti dello stesso tipo. La prima questione è sempre di tipo commerciale, far costare sempre meno i programmi ma poi, come sempre accade, non va sempre come si pensa, difatti leggendo qui sotto si evince che scrivere OOP costa anche di più.
L’OO nasce come tentativo di risposta all’esigenza di avvicinare lo sviluppo del software a quello dell’industria hardware, basata sullo sviluppo di componenti, per poterli riutilizzare nel maggior numero di contesti possibile.
Sebbene l’OO permetta di affrontare problemi complessi semplificandoli, e faciliti il raggiungimento degli obiettivi rispettando i tempi stabiliti, il problema della riusabilità è oggi tutt’altro che risolto; in particolare l’autore dell’articolo segnala come lo sviluppo di un componente software riusabile costi circa il doppio rispetto ad uno non riusabile (in termini di ingegnerizzazione, generalizzazione, testing e documentazione). Particolarmente interessanti risultano le tre regole segnalate alla fine dell’articolo relative al costo della riusabilità.
http://209.85.129.132/search?q=cache:o9QavcMegzsJ:www.tecnoteca.it/sezioni/ingegneria/ood_oop+la+oop+nasce+come+esigenza&cd=1&hl=it&ct=clnk&gl=it
cdimauro
22-05-2009, 07:38
Non è così: http://it.wikipedia.org/wiki/Programmazione_orientata_agli_oggetti
La programmazione orientata agli oggetti può essere vista come una modulazione di oggetti software sulla base degli oggetti del mondo reale.
Per maggiori informazioni ti consiglio di leggere questo (http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html) che è estremamente illuminante su cosa abbia portato alla realizzazione di questo nuovo paradigma di programmazione.
In ogni caso posso affermare senza timore d'esser smentito che la programmazione a oggetti non ha portato nulla rispetto alla più tradizionale programmazione strutturata. Nessun miglioramento; nessun vantaggio, per essere precisi. :fagiano:
E sono assolutamente certo che nessuno possa dimostrare il contrario. :O
In poche parole: avremmo tranquillamente potuto farne a meno e continuare col classico paradigma. :fagiano:
Soprattutto si sarebbe potuto fare a meno di realizzare nuovi linguaggi che hanno posto la OOP alla loro base. Un lavoro inutile, e uno spreco di risorse. :O
banryu79
22-05-2009, 08:58
Avevo già letto "The Early History of Smalltalk" e l'ho trovato molto stimolante.
Sono d'accordo con il concetto che afferma:
...l'informatica è una questione di quantità, non di qualità. Le cose sono zero, uno o mille, non sono "belle", "brutte", "facili", "difficili".
Anche io penso che l'informatica, e nello specifico la programmazione (tanto per restringere un po' il contesto) sia un'attività prettamente scientifica, quindi un'attività di tipo tecnico, non artistico.
Fatta questa premessa, la cosa che mi "turba" un po' è il constatare alcune affermazioni/spiegazioni che ho letto circa la natura del paradigma OOP oggi.
Asserzioni di questo tipo:
La programmazione orientata agli oggetti può essere vista come una modulazione di oggetti software sulla base degli oggetti del mondo reale.
oppure considerazioni sul fatto che il paradigma OOP permetta al programmatore un modo per modellare un'astrazione con un meccanismo che nelle intenzioni vorrebbe essere simile al modo in cui la mente umana crea i propri modelli della realtà per evitare al programmatore un doppio passaggio di prospettiva [modello logico della soluzione in prospettiva mentale umana(si vorrebbe fosse la OOP) --> modello equivalente in prospettiva dell'elaboratore(procedurale) --> cristallizzazione del modello in codice sorgente del linguaggio xyz] mi lasciano più di qualche dubbio.
Questo perchè se il presupposto è la scientificità del metodo, è dura trovare una giustificazione prettamente scientifica per il paradigma OOP.
Questo quando ancora non sappiamo (scientificamente) come funziona la mente umana, nel suo toto.
Rispetto a questa affermazione invece:
In ogni caso posso affermare senza timore d'esser smentito che la programmazione a oggetti non ha portato nulla rispetto alla più tradizionale programmazione strutturata. Nessun miglioramento; nessun vantaggio, per essere precisi.
Non so come considerare la faccenda: mi mancano conoscenze ed esperienza.
Dopotutto sono uno "smanettone" e non un "programmatore", non ho una preparazione rigorosa in materia.
L'unica speculazione che posso fare è questa:
- Il paradigma OOP rispetto al paradigma procedurale, nello specifico quello della programmazione strutturata, è un paradigma "più vicino" al "modo di funzionamento" della mente umana?
- Oppure è solo un altro paradigma, con peculiarità e idiosincrasie differenti, che in sostanza non è "più vicino" al "modo di funzionamento" della mente umana, ma è solo un paradigma "diverso"?
Fosse anche "solo" il secondo caso, siamo proprio sicuri che non apporti nulla, nessunissimo vantaggio?
Se fosse solo un pradigma, ne migliore ne peggiore "in senso assoluto" del paradigma procedurale, un vantaggio potrebbe comunque esserci.
Ed è dato dalla varietà: i programmatori sono esseri umani.
Alcune menti possono trovarsi meglio lavorando con un paradigma piuttosto che con un altro.
Dato che per definizione un paradigma è un modello di riferimento, come tale delimita, quindi pone dei limiti alla libertà della mente umana.
La scienza non ci spiega come funziona la mente umana (e non a caso uso la parola mente e non la parola cervello), la scienza non è in grado di dirci quale sia il paradigma migliore.
E' difficile dire, secondo me, considerando il fattore umano, che il paradigma OOP non ha apportato nessun miglioramento, nessun vantaggio, in senso assoluto.
Non è così: http://it.wikipedia.org/wiki/Programmazione_orientata_agli_oggetti
La programmazione orientata agli oggetti può essere vista come una modulazione di oggetti software sulla base degli oggetti del mondo reale.
Per maggiori informazioni ti consiglio di leggere questo (http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html) che è estremamente illuminante su cosa abbia portato alla realizzazione di questo nuovo paradigma di programmazione.
In ogni caso posso affermare senza timore d'esser smentito che la programmazione a oggetti non ha portato nulla rispetto alla più tradizionale programmazione strutturata. Nessun miglioramento; nessun vantaggio, per essere precisi. :fagiano:
E sono assolutamente certo che nessuno possa dimostrare il contrario. :O
In poche parole: avremmo tranquillamente potuto farne a meno e continuare col classico paradigma. :fagiano:
Soprattutto si sarebbe potuto fare a meno di realizzare nuovi linguaggi che hanno posto la OOP alla loro base. Un lavoro inutile, e uno spreco di risorse. :O
*
ovviamente però è un gran rivoluzione, permettere di aggregare strutture di codice assieme semplifica e anche di molto come "ragionare" per risolvere un problema....
banryu79
22-05-2009, 10:29
semplifica e anche di molto come "ragionare" per risolvere un problema
Ecco, questo andrebbe dimostrato.
Perchè è solo una tua affermazione, che potrebbe avere un valore di verità diverso per gli altri; di certo non ha nessun valore di verità scientifica.
Stiamo considerando la prospettiva OOP, presumo perchè è il paradigma dominante del momento.
Ma la discussione verteva sulla scientificità o meno dell'informatica.
Partita da alcune considerazioni fatte da PGI-bis, circa le pratiche di refactoring e design patterns.
A PGI-bis, che mette in risalto la non scientificità di queste teorie, vorrei chiedere come si pone nei confronti della non scientificità del paradigma OOP.
La programmazione strutturata, da quel poco che so, è almeno giustificata da un teorema: il teorema di Bohm-Jacopini.
Il paradigma OOP, è giustificato da qualche teorema?
Una speculazione azzardata:
Se prendo un sorgente, prodotto nell'ottica della programmazione procedurale che fa uso del solo costrutto "go to", come input da passare ad un programma il quale in output produce un sorgente equivalente per "sequenza" all'input dato ma, con sostituzione dei costrutti "go to" con i costrutti di "selezione" e "iterazione" (e conseguente eliminazione delle ridondanze di codice a supporto), posso dire di aver "fattorizzato" il codice?
Se sì, confrontando il sorgente in input e quello in output, e presupponendo che il lettore possieda una parità di familiarità nel leggere i due tipi di strutturazione del codice, possiamo affermare che la comprensione del programma nella sua interezza e nelle sue parti durante la lettura del secondo codice sarà "più facile" rsipetto alla lettura del primo codice?
Se sì, possiamo anche affermare che, se lo stesso soggetto di prima, dovesse apportare una modifica ad alcune porzioni specifiche del sorgente per cambiare alcune logiche, troverebbe "più facile" ricercare e impiegherebbe meno tempo a localizzare i diversi punti di controllo del flusso di esecuzione del codice durante la lettura del secondo codice rispetto al primo?
Se sì, e per farla breve: non è almeno ragionevole (non certo scientifico) supporre per analogia che ciò sia anche con il codice prodotto in aderenza al paradigma OOP mediante le tecniche di refactoring?
Infine: dato che non ho una preparazione adeguata (accademica e di conoscenza specifica di alcune tematiche) sono grato a chiunque mi mostrasse e spiegasse qualsiasi errore abbia commesso.
mad_hhatter
22-05-2009, 13:33
credo vadano distinti due piani concettuali: quello del modello computazionale e quello dell'approccio allo sviluppo di applicazioni.
Per quanto riguarda il primo, abbiamo il teorema citato da banryu79. Ma questo livello di formalismo è possibile proprio perché siano sul piano dei modelli computazionali, che sono di per sè stessi modelli formali.
La OOP non modifica il modello computazionale che sta alla base delle nostre astrazioni: modifica il modo di modularizzare il codice, non il modello di esecuzione dello stesso. E modifica la concezione del sistema software, il punto di vista da cui viene osservato, analizzato, descritto. Le metafore, le astrazioni utilizzate. Ma non il modello computazionale sottostante.
E la suddivisione del codice in moduli non ha regole prestabilite e formalizzate. Sono stati approntati modelli formati per la descrizione dei moduli e delle loro relazioni, ma non per la loro determinazione. La determinazione di quali siano i moduli che compongono un sistema dipende da molti fattori, solo alcuni dei quali quantitativi, mentre gli altri sono basati sul buon senso e/o sull'intuizione degli sviluppatori.
Questa parte della programmazione è essenzialmente creativa e basata su una serie di compromessi. Ed è qui che entra in gioco il fattore umano.
Design pattern e refactoring sono pratiche, non hanno di per sè valenza teoretica.
^TiGeRShArK^
22-05-2009, 13:36
Anche io penso che l'informatica, e nello specifico la programmazione (tanto per restringere un po' il contesto) sia un'attività prettamente scientifica, quindi un'attività di tipo tecnico, non artistico.
anche la matematica mi pare sia prettamente scientifica, ma non per niente per dimostrare certi teoremi servono delle NOTEVOLI qualità creative e artistiche.
Se fosse possibile riportare l'informatica ad una mera sequenza di zero e di uno allora sarebbe possibilissimo scrivere un software che risolva da solo i problemi e non ci sarebbe + bisogno dei programmatori.
Ma non mi pare che fino ad oggi sia mai accaduto. ;)
Certe premesse della prospettiva orientata agli oggetti (dico certe perchè quali siano è tutt'altro che pacifico, Nygaard e Kay ad esempio non sono sulla stessa lunghezza d'onda al riguardo) sono scientifiche perchè falsificabili.
Le premesse sono tre.
La prima è che i calcolatori sono macchine procedurali: eseguono operazioni elementari (cioè non ulteriormente divisibili) su valori immagazzinati in registri di memoria.
La seconda è che il codice sorgente di un programma è la rappresentazione di un fenomeno reale o immaginario nella prospettiva del linguaggio di programmazione adottato.
La terza è che il fenomeno e la sua rappresentazione sono separati dalla prospettiva che l'osservatore adotta quando esamina il fenomeno.
La prospettiva è uno schema espressivo: un insieme di termini e relazioni tra quei termini a cui io devo rincodurre le cose affinchè possano dirsi espresse secondo quella prospettiva.
Diventa uno schema cognitivo, cioè uno strumento per acquisire conoscenza dei fenomeni, quando i termini e le relazioni adottati dalla prospettiva coincidono con i termini e le relazioni usate per razionalizzare i fenomeni (per ricordarseli e per poterli usare al fine di acquisire nuove conoscenze).
Il punto è che tra il fenomeno e la sua rappresentazione nel calcolatore abbiamo tre passaggi di prospettiva: fenomeno-osservatore, osservatore-programma, programma-calcolatore.
Ogni passaggio è una traduzione, la stessa cosa è espressa in termini diversi.
L'idea della prospettiva orientata agli oggetti è che poichè la tecnologia dei compilatori ci consente di automatizzare l'ultimo passaggio a prescindere dalla prospettiva del linguaggio se adotto un linguaggio che usi la stessa prospettiva dell'osservatore riduco il tutto all'unica traduzione:
fenomeno-osservatore
Magnifico mi risparmio un sacco di lavoro, tutto bene, via. No, ci sono una marea di problemi solo alcuni dei quali erano noti negli anni '50.
Il primo problema è che esiste nell'osservatore, ogni volta che questo sia un essere umano, una prospettiva innata.
Significa che non è possibile dire: "ok allora se osservo le cose da un punto di vista procedurale e le esprimo con un linguaggio procedurale ottengo un solo passaggio di prospettiva" perchè se esiste una prospettiva innata allora ciò è vero solo nel caso in cui tale prospettiva innata sia essa stessa procedurale.
Acquisiamo conoscenza in modo procedurale? No e da che Popper è esistito per dimostrarlo è sufficente che alla richiesta "descrivimi la prima cosa che trovi sul tuo tavolo" almeno uno di noi non inizi a dire "store load store load store load".
Negli anni '50 dominava la teoria classica secondo cui la prospettiva innata di cui parliamo era fatta di classi e gerarchie. Si riteneva che conoscessimo dividendo il fenomeno in insiemi caratterizzati dalla costante validità di talune affermazioni preconcette. Acquisiti i concetti di bianco e nero io esprimo un fenomeno in termini di cose che sono bianche o sono nere. Se conosco i termini colore e so che bianco e nero sono colori allora avrò le cose colorate, le cose non colorate e tra le cose colorate quelle che sono bianche e quelle che sono nere.
E' tutta storia, trita e ritrita.
Il punto è che è storia scientifica. E' scientifica perchè è criticabile nel senso che le premesse del discorso orientamento agli oggetti sono passibili di falsificazione.
Il calcolatore non è procedurale? Niente OOP.
Il codice non rappresenta un fenomeno? Niente OOP.
Tre trasformazioni sono meno di una? Niente OOP.
Non c'è una prospettiva umana? Niente OOP.
E così via.
Non è necessario uno studio ufficiale, non serve una pronuncia del consiglio dei saggi o l'approvazione della comunità per falsificare una teoria: è sufficiente portare alla luce un caso in cui l'applicazione della teoria dice A e invece capita B.
E' lo stesso punto della "semplicità". Cos'è semplice? Semplice in programmazione è tutto quello che richiede meno di tre minuti per essere scritto?. Questa sarebbe un'affermazione. Se impiego meno di tre minuti per scriverlo nel linguaggio di programmazione che uso allora è semplice. Altrimenti non è semplice. Non so quanto sia utile ma almeno è falsificabile.
Non ci si può rifugiare dietro a un "ma sì, non sono principi, sono linee guida" perchè dove ti guida una cosa che non vuol dire nulla?
E via con le danze!.
mad_hhatter
22-05-2009, 17:06
bene, ma in assenza di regole universali, cosa facciamo? smettiamo di parlare di metodi di programmazione perché non abbiamo altro che una serie di insiemi di criteri empirici non riconducibili ad una teoria unitaria, sistematica e falsificabile?
il problema è che stiamo parlando di una branca dell'attività umana che non può prescindere dall'essere umano stesso: ci sono temi sociali e cognitivi che di per sè non sono descrivibili scientificamente. Ma abbiamo necessità di parlare di questo genere di attività e di questo genere di tematiche. E quindi cosa facciamo?
In questo senso stiamo parlando di ingegneria del software più che di informatica in senso lato. E l'ingegneria del software non si può ancora chiamarla scienza.
Programmare è un atto prettamente creativo.
Ridurla ad un insieme di uno e di zero è sminuirla, esattamente come ridurre le eleganti dimostrazioni matematiche ad una mera sequenza di numeri.
E come ogni cosa creativa, o artistica, imho è anche possibile giudicarne la bellezza ,esattamente come in certi teoremi (che però non è facile che apprezzino tutti.. :stordita: )
sono d'accordo con te. come per tutte le cose anche nella programmazione è poi possibile svolgerlo per lavoro o per diletto. Come chi si occupa di design senza minimo gusto estetico ci sono moltissimi programmatori senza la minima competenza in riduzione di algoritmi e che fanno in 100 righe e 1 milione di calcoli del processore quello che altri fanno in 5 righe e 3 calcoli.
Per questo anche la misura del lavoro in quantità di codice la trovo alquanto riduttiva e poco corretta.
Uso il termine "quantità" nel senso di quantitativo, di misurabile. Non quantità di codice o gli zero e uno dei bit.
L'ingegneria del software è una scienza. E' come tutte le ingegnerie una scienza del metodo.
L'idea che un programma sia un quadro dipinto in un momento di estasi artistica a me suona quantomeno bizzarra.
Ci sono una valanga di cose misurabili in un programma. Dalle banali (output, tempi, quantità di istruzioni eccetera) a quella che io trovo più interessante: la corrispondenza del fenomeno rappresentato dal codice sorgente al fenomeno di partenza, quello che sia chiama sistema di riferimento.
Quello che i programmatori in erba a volte trascurano di considerarare è che ogni singola parola scritta in un linguaggio di programmazione ha una conseguenza dal punto di vista della corrispondenza del programma al fenomeno che si vuole rappresentare.
Tutto ciò di cui un programmatore dovrebbe occuparsi è proprio l'esatta, minuziosa, precisa corrispondenza di ciò che scrive al sistema di riferimento. E' questo che richiede una ferrea conoscenza degli strumenti che si usano (lingua e librerie, con tutte le loro sottigliezze).
Non "fallo semplice" ma "fallo esatto". Una volta che il programma è la copia conforme del sistema di riferimento ogni problema che sorge è del sistema non del codice.
E' il principio che anima(va) la programmazione funzionale di Dijkstra. Se il sistema di riferimento è matematicamente dimostrabile allora un programma che ne sia la diretta traduzione risulterà matematicamente esatto.
^TiGeRShArK^
22-05-2009, 17:40
Uso il termine "quantità" nel senso di quantitativo, di misurabile. Non quantità di codice o gli zero e uno dei bit.
L'ingegneria del software è una scienza. E' come tutte le ingegnerie una scienza del metodo.
L'idea che un programma sia un quadro dipinto in un momento di estasi artistica a me suona quantomeno bizzarra.
Ci sono una valanga di cose misurabili in un programma. Dalle banali (output, tempi, quantità di istruzioni eccetera) a quella che io trovo più interessante: la corrispondenza del fenomeno rappresentato dal codice sorgente al fenomeno di partenza, quello che sia chiama sistema di riferimento.
Quello che i programmatori in erba a volte trascurano di considerarare è che ogni singola parola scritta in un linguaggio di programmazione ha una conseguenza dal punto di vista della corrispondenza del programma al fenomeno che si vuole rappresentare.
Tutto ciò di cui un programmatore dovrebbe occuparsi è proprio l'esatta, minuziosa, precisa corrispondenza di ciò che scrive al sistema di riferimento. E' questo che richiede una ferrea conoscenza degli strumenti che si usano (lingua e librerie, con tutte le loro sottigliezze).
Non "fallo semplice" ma "fallo esatto". Una volta che il programma è la copia conforme del sistema di riferimento ogni problema che sorge è del sistema non del codice.
E' il principio che anima(va) la programmazione funzionale di Dijkstra. Se il sistema di riferimento è matematicamente dimostrabile allora un programma che ne sia la diretta traduzione risulterà matematicamente esatto.
Una cosa se è esatta non vuole affatto dire che non è artistica o che ci vuole un processo prettamente creativo per produrla.
Ritornando all'esempio di un teorema matematico, se davvero bastasse solo applicare in maniera esatta delle semplici leggi allora noi potremmo andare in pensione dato che i calcolatori sono INFINITAMENTE + bravi di noi per questa cosa.
Eppure non mi pare che i calcolatori dimostrino dei teoremi, ma piuttosto sono degli esseri umani particolarmente creativi, e portati a vedere le cose in un certo modo, da una prospettiva a volte molto diversa rispetto a quella usuale, a farlo.
mad_hhatter
22-05-2009, 18:02
Uso il termine "quantità" nel senso di quantitativo, di misurabile. Non quantità di codice o gli zero e uno dei bit.
L'ingegneria del software è una scienza. E' come tutte le ingegnerie una scienza del metodo.
L'idea che un programma sia un quadro dipinto in un momento di estasi artistica a me suona quantomeno bizzarra.
Ci sono una valanga di cose misurabili in un programma. Dalle banali (output, tempi, quantità di istruzioni eccetera) a quella che io trovo più interessante: la corrispondenza del fenomeno rappresentato dal codice sorgente al fenomeno di partenza, quello che sia chiama sistema di riferimento.
Quello che i programmatori in erba a volte trascurano di considerarare è che ogni singola parola scritta in un linguaggio di programmazione ha una conseguenza dal punto di vista della corrispondenza del programma al fenomeno che si vuole rappresentare.
Tutto ciò di cui un programmatore dovrebbe occuparsi è proprio l'esatta, minuziosa, precisa corrispondenza di ciò che scrive al sistema di riferimento. E' questo che richiede una ferrea conoscenza degli strumenti che si usano (lingua e librerie, con tutte le loro sottigliezze).
Non "fallo semplice" ma "fallo esatto". Una volta che il programma è la copia conforme del sistema di riferimento ogni problema che sorge è del sistema non del codice.
E' il principio che anima(va) la programmazione funzionale di Dijkstra. Se il sistema di riferimento è matematicamente dimostrabile allora un programma che ne sia la diretta traduzione risulterà matematicamente esatto.
la conformità è sempre misurabile in maniera precisa, non ambigua? Una volta che il sistema è esatto (o, almeno, sufficientemente esatto), abbiamo finito o possiamo voler modificare qualche parametro che non sia l'esattezza?
Non nego che possa esserci qualcosa di estetico in un programma ma un programma non può essere arte se ha una funzione che va oltre la propria esistenza.
Per la dimostrazione matematica i punti sono due.
Prima di tutto la "dimostrazione" in matematica è un procedimento logico deduttivo. Essere de-duzione significa che la dimostrazione è una conseguenza logica delle sue premesse. La dimostrazione è già nel teorema.
I calcolatori dimostrano teoremi e trovano anche nuove dimostrazioni a teoremi altrimenti già dimostrati.
Non sono un matematico e non saprei pertanto dire dove stia la difficoltà della dimostrazione ma, secondo punto, mi vengono in mente almeno due "problema della dimostrazione". Il primo è la quantità delle premesse da considerare e il secondo è il fatto che un teorema non dimostrato potrebbe anche essere falso (l'ultimo teorema di fermat ad esempio è diventato matematicamente vero solo nel '95).
L'aspetto artistico a cui fai riferimento è probabilmente la qualità del "genio" ma è una qualità ampiamente studiata e che in psicologia cognitiva si chiama "insight". E' una deviazione del processo cognitivo che porta persone particolarmente dotate (in genere anche da un punto di vista artistico) a trarre conclusioni logicamente valide senza un procedimento inferenziale.
la conformità è sempre misurabile in maniera precisa, non ambigua?
Sì se il sistema di riferimento è un sistema chiuso.
C'è un dettagliuzzo riguardante il fatto che i sistemi chiusi non sono esprimibili ma non stiamo a cercare il pelo nell'uovo, via :D.
cdimauro
22-05-2009, 20:23
La cosa più importante per il programmatore è che il programma che ha scritto soddisfi i requisiti del problema che gli è stato sottoposto (lo so ho scritto una banalità :D).
Supponendo di rappresentare un qualunque problema come funzione di un solo parametro (avere n parametri non cambia di una virgola il concetto), è dimostrabile che il codice che ho scritto riproduca esattamente il comportamento desiderato, per qualunque input?
Questa, a mio avviso, è la base da cui partire.
Se siamo in grado di dare una risposta affermativa a questa domanda, siamo a cavallo: non c'è paradigma che tenga (tanto uno vale l'altro) e possiamo dormire su due guanciali.
Se, invece, la risposta è negativa, si aprono diversi scenari che meritano di essere discussi e approfonditi.
La cosa più importante per il programmatore è che il programma che ha scritto soddisfi i requisiti del problema che gli è stato sottoposto (lo so ho scritto una banalità :D).
Mica tanto banale se iniziamo a colorare la programmazione di toni artistici.
Supponendo di rappresentare un qualunque problema come funzione di un solo parametro (avere n parametri non cambia di una virgola il concetto), è dimostrabile che il codice che ho scritto riproduca esattamente il comportamento desiderato, per qualunque input?
Questa, a mio avviso, è la base da cui partire.
Non possiamo dirlo in senso assoluto per via empirica. In questo senso potremmo farlo solo se l'insieme di input fosse finito e fosse finito anche l'insieme di prove che possiamo compiere. Che è un no secco: potrei testare il programma su tutti i PC di questo mondo e resterebbero comunque fuori tutti i PC ancora da produrre. E' la ragione per cui lo Unit Testing non dice nulla circa l'esattezza di un programma (ma dice molto riguardo ai suoi errori).
Possiamo invece provarlo relativamente e per via logica. Ad esempio se assumo di avere a disposizione un calcolatore che sia l'esatta implementazione dell'architettura x86 dati in input due interi a 16 bit è dimostrabile per via di sottoinsiemi che la somma dei due valori è un elemento dell'insieme degli interi rappresentabili con 32 bit. Allo stesso modo è dimostrabile che dati in input due decimali rappresentati con 16 bit la loro somma NON E' sempre un elemento dell'insieme dei decimali rappresentati con 32 bit.
Questo ultimo pezzo è più interessante del primo perchè se io ho un modello di riferimento che ad un certo punto prevede la somma di una qualsiasi coppia di numeri decimali a 16 bit e la realizzato con bel più tra numeri a 32 bit quella rappresentazione non corrisponde al modello di riferimento.
cdimauro
22-05-2009, 21:02
Queste dimostrazioni però sono molto "semplici" (scusa il termine :D).
Se aumentiamo le variabili in gioco, la loro tipologia, ma soprattutto aggiungiamo il "salto su condizione", sei ancora sicuro che si riuscirà a formalizzare una dimostrazione di correttezza per un qualunque programma "non banale"?
Io non riuscirei a dimostrare neppure che ho gli occhiali sul naso (avendoceli).
Ma dijkstra ad esempio lo riteneva possibile: se il mio modello è un modello matematico e io lo "programmo" in termini matematici allora esiste la corrispondenza che mi permette di dire il programma è esattamente conforme al modello. Se il modello è giusto sarà giusto anche il programma.
cdimauro
22-05-2009, 21:17
Godel non la pensava così. Anzi, il suo pensiero era diametralmente opposto e formalizzato in quello che si chiama teorema dello stop o dell'arresto.
Ecco, te possino, adesso devo andare a studiare Godel perchè non so manco chi sia.
Mi toccherà farmi una testa così sui libri per cui se alla fine scopro che era un vecchio ubriacone ti vengo a cercare!
Quello del teorema di incompletezza! Ahhh, e che cacchio, potevi dirlo subito. Non sapevo che fosse di Godel. Comunqe devo studiarlo :cry:
Sì, è quello del teorema di incompletezza (sono andato su wikipedia). E non dimostra l'indimostrabilità assoluta ma solo la necessità di definire degli assiomi per accertare la validità di affermazioni su sistemi aperti.
Assiomi di cui siamo pieni fin sopra i capelli.
Kralizek
22-05-2009, 21:34
io credo che una volta posto che un programma risolva un problema esiste uno spazio infinito di possibili di modi di implementare il tutto che possano rendere il risultato più o meno bello.
Non è il concetto di bello del quadro che ritrae una rosa ed una spina in più o in meno può fare la differenza. E' il concetto di "bello scientifico". Una classe che espone tutti e soli i membri che sia necessario esporre, utilizzare una struttura dati anzicchè un'altra, usare un tips CSS anzicchè una tabella e così via.
Parlo da programmatore web, sono tantissimi gli esempi. Alla fine la pagina arriva comunque al client. E' quello che c'è dietro, leggendo il codice che ti fa propendere verso il "bello" o "brutto".
Un esempio, in azienda le proprietà automatiche del C# sono poco utilizzate, ma scrivere
public string MiaStringa { get; set; }
al posto di
private string _MiaStringa;
public string MiaStringa
{
get { return _MiaStringa; }
set { _MiaStringa = value; }
}
facilita di molto la lettura pur lasciando invariato il codice generato dal compilatore. Se non è una definizione di "bello", è sulla buona strada.
Ci sarebbe tanto altro da dire, ma devo scendere! Però anche la progettazione di una funzionalità può essere "bella" o "brutta" pur rispondendo in entrambi i casi ai requisiti funzionali.
cdimauro
22-05-2009, 21:40
Sì, è quello del teorema di incompletezza (sono andato su wikipedia). E non dimostra l'indimostrabilità assoluta ma solo la necessità di definire degli assiomi per accertare la validità di affermazioni su sistemi aperti.
Assiomi di cui siamo pieni fin sopra i capelli.
Beh, senza gli assiomi non si va mica avanti: senza quelli di Peano possiamo dire addio a tutto. :D
Sì, comunque è quello il nocciolo della questione: l'indecidibilità di Godel. O, se preferisci, la versione informatica che è rappresentata dal teorema di Turing.
Perché se è vero questo (http://it.wikipedia.org/wiki/Problema_della_fermata):
È stato dimostato che non può esistere un algoritmo generale che possa risolvere il problema per tutti i possibili input.
allora questo
Se il sistema di riferimento è matematicamente dimostrabile allora un programma che ne sia la diretta traduzione risulterà matematicamente esatto.
è impossibile da dimostrare. Posto ovviamente che si stia parlando di un qualunque programma. Poi gli esempi banali in cui sia possibile farlo esistono e li possiamo anche facilmente costruire, ma il teorema di Godel o di Turing non perdono certo di validità. ;)
Siamo d'accordo su questo punto? :fagiano:
Attenzione, parliamo di algoritmo generale e parliamo di input infiniti. Il che ci lascia aperta la possibilità di un algoritmo "assiomatico" e ci lascia aperta la porta agli input finiti che per una macchina deterministica come il PC non sono pochi.
E attenzione due perchè il principio di incompletezza dice, per fare un esempio, che la transitività della relazione di inclusione (se A include B e B include C allora A include C) è vera se accettiamo di non poter dimostrare in termini matematici il concetto di insieme.
Ora io tra un assioma matematico indimostrabile per via del principio di incompletezza e un KISS be' francamente, dammi torto, propendo per il primo.
Una nota di colore: mentre su uno schermo pontifico di logica e corrispondenza a fantomaci modelli sull'altro sto rabberciando un programma di archiviazione "verificandolo" a colpi di System.out.println :D.
Della serie "predicava bene e razzolava nelle paludi" :D.
cdimauro
22-05-2009, 22:02
A dimostrazione che l'informatica rimane intrinsecamente pragmatica. :D
Comunque anche restringendo il discorso agli input finiti, per programmi "non banali" le loro combinazioni crescono esponenzialmente. Per cui, di fatto, per un algoritmo / programma diventa pressoché impossibile dimostrarne la correttezza.
E torniamo sempre al punto di prima. :stordita:
A dimostrazione che l'informatica rimane intrinsecamente pragmatica. :D
Comunque anche restringendo il discorso agli input finiti, per programmi "non banali" le loro combinazioni crescono esponenzialmente. Per cui, di fatto, per un algoritmo / programma diventa pressoché impossibile dimostrarne la correttezza.
E torniamo sempre al punto di prima. :stordita:
non c'è linguaggi formali e automi che permette di dimostrare quasi qualsiasi cosa ? :fagiano:
cdimauro
22-05-2009, 22:18
No. I teoremi che ho citato prima lasciano poche speranze agli informatici, sul piano prettamente teorico.
Diciamo che se dovessimo prenderli come riferimento assoluto, faremmo meglio a cercarci un altro lavoro, che ci garantisca più "certezze". :p
misterx, il punto di godel è "qualsiasi cosa tranne sè stessi".
Diciamo che ci sono programmi dimostrabili e altri non dimostrabili. Occupiamoci di quelli il cui output non è dimostrabile in principio o perchè la dimostrazione richiederebbe un tempo eccessivo.
Tu dici KISS, io dico fallo come ti pare purchè sia identico al modello.
Precisamente il mio "modello di sviluppo software" sarebbe questo.
Si parte da una descrizione formale e completa del sistema da realizzare (tipo fase uno del waterfall).
Il modello viene diviso in moduli e ogni modulo va in produzione.
Mentra lo sviluppo del modulo avanza le parti completate vengono sottoposte a "reverse engineering": dal codice ad un modello. Il modello inverso viene confrontato con il modello originale. Le differenze vengono annotate e il codice torna in produzione per essere modificato. Il ciclo continua finchè non vi siano più differenze rispetto al modello originale.
Eventuali modifiche al progetto vengono applicate al modello di riferimento e rilevate automaticamente durante i cicli di "analisi differenziale" (un nome che m'è venuto in mente adesso per quella roba là sopra).
Quando i cicli di produzione-analisi sono completi il programma è pronto.
E adesso tirate fuori il mio premio Turing se no m'incazzo! :D.
cdimauro
22-05-2009, 22:31
Se riesci a dimostrare che il programma che hai scritto è aderente al modello di riferimento che hai formalizzato, quel premio non te lo leva nessuno. :fagiano:
Be' quella lì è una corrispondenza semantica. E' solo un problema di tipi e operazioni. Il problema dell'esattezza di cui parlavamo prima è solo spostata: dal codice al modello. Però credo che il modello offra più possibilità di essere controllato da un punto di vista logico rispetto al codice.
E niente unit testing. O refactoring. O EXtreme Programming. Con mia grandissima gioia personale.
cdimauro
22-05-2009, 22:47
Non credo ci sia molta differenza fra codice e modello. Come dici tu, il problema è soltanto spostato.
Finché si parla di funzioni ricorsive primitive, tutto può funzionare.
Le maledizioni degli informatici arrivano con le funzioni ricorsive, che non sono "facilmente controllabili". E non c'è modello che tenga: prima o poi modellando un fenomeno "non banale" qualche cazzata viene fuori. Che chiamiamo "bug". :D
Be' quella lì è una corrispondenza semantica. E' solo un problema di tipi e operazioni. Il problema dell'esattezza di cui parlavamo prima è solo spostata: dal codice al modello. Però credo che il modello offra più possibilità di essere controllato da un punto di vista logico rispetto al codice.
E niente unit testing. O refactoring. O EXtreme Programming. Con mia grandissima gioia personale.
Anche volendo dimostrare l'esattezza del codice non dovresti usare Unit Testing e compagnia. Non è quello lo scopo per cui sono stati pensati. Io li vedo come degli strumenti che cercano di aiutare il programmatore a scrivere codice.
cdimauro
23-05-2009, 05:45
Su questo punto dobbiamo ancora arrivarci (il bello viene sempre dopo, no? :D).
Per adesso sbrogliamo la matassa "correttezza" / "indecidibilità", SE è possibile. :fiufiu:
a me fate venire in mente il teorema di Cantor
Su questo punto dobbiamo ancora arrivarci (il bello viene sempre dopo, no? :D).
Per adesso sbrogliamo la matassa "correttezza" / "indecidibilità", SE è possibile. :fiufiu:
Mi sembrava che l'avessimo già sbrogliata.
programmare è cercare di capire quello che vuole il cliente, cercare di metterlo in piedi, e fatturarlo.
programmare è cercare di capire quello che vuole il cliente, cercare di metterlo in piedi, e fatturarlo.
Hai dimenticato "e cercare di farsi pagare quella fattura". Specialmente se hai già versato l'IVA:
mad_hhatter
23-05-2009, 22:25
beh, che dire... io mi sono ufficialmente perso.
Vediamo di chiarire alcuni punti.
1. PGI-bis, definisci sistema chiuso per favore.
2. vediamo se ho capito il succo del discorso: per PGI-bis le metodologie suggerite da Beck non offrono alcun grado di formalismo, non sono quantificabili e quindi inapplicabili. Inoltre non fornendo alcun tipo di cornice assiomatica non sono falsificabili. Vado bene fin qui?
Il processo esemplificato da PGI-bis prevede la descrizione del modello del fenomeno, la sua traduzione in codice e la verifica iterativa del grado di aderenza del codice al modello.
Sto continuando bene?
A questo punto se ne esce il buon Cesare che gioca la carta del teorema di Godel: serve forse a dire che non e' detto che l'analisi differenziale appena citata non e' detto che sia sempre realizzabile? O a dire che un modello matematico del reale non e' realizzabile?
3. Mia osservazione. Partiamo dal discorso dell'analisi differenziale. Ammesso e non concesso che un modello matematico del fenomeno sia realizzabile, non dovremmo preoccuparci di vedere se quel modello e' equivalente al fenomeno? ma per popper, questo non e' impossibile? Ma ammesso e non concesso che sia possibile, il modello matematico che ne deriva e' sempre praticabile? Potrebbe derivarne un modello talmente complesso da non essere risolvibile dati gli attuali strumenti matematici, al che dovremmo accontentarci di un'approssimazione. E come scegliamo un'approssimazione sufficiente? In base a criteri che non sono solo matematici, ma anche economici, opportunistici, ecc...
Supponiamo poi di non avere conoscenza completa del fenomeno da modellare (e' il classico problema del cliente che non sa cosa vuole esattamente finche' non ha in mano un prototipo della soluzione che ha richiesto). Che cos faacciamo? PGI-bis dice di aggiustare il modello in modo iterativo. Ma questo procedimento converge sempre? O puo' divergere?
4. le considerazione di beck sono tutto tranne che tecniche rigorose. L'oboettivo di beck, a mio avviso, non e' quello di introdurre una metodologia univoca, ma di rendere conscio un team di persone di alcuni problemi e di alcune necessita' che emergono nello sviluppo di un sistema software. Mi pare di capire che le problematiche affrontate siano piu' che altro di carattere psicologico, sociale e manageriale piu' che strettamente tecniche.
Sono rivolte piu' che altro al buon funzionamento del team. Vengono date una serie di intuizioni, di spunti di riflessioni che sara' ogni singolo team a dover concretizzare stante la sua propria condizione. In quanto tali sono volutamente espresse in modo vago e qualitativo piuttosto che quantitativo.
Sto leggendo il testo Ingegneria del software di Ghezzi e Mandrioli e viene spesso ribadito il concetto secondo cui non esistono metodologie valide universalmente, e molto e' lasciato al buon senso e all'esperienza degli ingegneri coinvolti.
L'ingegneria e' piena di esempi in cui i modelli matematici si rivelano troppo complessi per risultare utili praticamente. Questo porta a dover mettere da parte i procedimenti deduttivi e a mettere in piedi sistemi di verifica basati sulla sperimentazione e/o sulla simulazione. Piu' o meno e' il fondamento dello unit testing.
Ancora, una volta realizzato un sistema corretto, non abbiamo esaurito le nostre necessita' produttive: dobbiamo mantenere e far evolvere il sistema. Alcune formulazioni del sistema sono piu' adatte di altre a questo scopo. A questo si aggiunga la necessita' di analizzare il codice stesso, di leggerlo e comprenderlo. Di nuovo, alcune formulazioni sono piu' adatte di altre. La definizione di adatto non e' univoca e dipende dal contesto in cui il sistema viene sviluppato. Da qui la necessita' del refactoring. Il come debba essere fatto e a cosa debba portare non e' specficabile in generale: dipende dal contesto.
In sostanza, siamo di fronte a una serie di considerazioni prettamente umane.
Godel dice che anche qualora io riuscissi a dimostrare tramite le regole della matematica l'esattezza di un teorema tale dimostrazione non potrebbe prescindere dalla presenza di assiomi ovvero di affermazioni considerate vere in quanto tali.
Prendi ad esempio la reductio ad absurdum. Data una premessa se le sue conseguenze logiche conducono ad una negazione della stessa si dice che la premessa è falsa per assurdo logico. Non è un falsità matematica. E' una falsità logica: non è possibile affermare e negare una cosa nello stesso senso, tempo e luogo perchè ciò condurrebbe ad un ciclo infinito di negazioni.
Il teorema di incompletezza dice che un insieme di regole non può trovare fondamento in sè stesso. Occorre sempre fare riferimento "a qualcos'altro" oppure convenire sul fatto che esista almeno un principio convenzionalmente dato.
E' la stessa cosa che capita quando si cerca di dare la definizione di una parola: devi usare altre parole. Ogni parola che usi può essere a sua volta definita tramite altre parole e così via. Il principio di incompletezza dice che questo circuito di parole è infinito. Per terminarlo devo per forza "convenire" su almeno una parola, dicedo che è essa è "definita in sè stessa".
Un sistema è chiuso se il numero di elementi di cui è composto è finito.
Ciò detto preciso che a me della dimostrabilità matematica di un programma non me ne importa un fico secco. A me la programmaziona funzionale ha sempre fatto schifo.
Quello che mi preme è invece l'esistenza di una corrispondenza tra il codice ed il modello e non dal punto di vista dell'output ma dal punto di vista del significato che il codice esprime (Verifica iterativa per consentire l'introduzione di cambiamenti in corso d'opera).
Per due ragioni. La prima è che grazie alle prospettive il modello può essere definito da persone che non abbiano necessariamente un background informatico. La seconda è che il modello può gestito da un numero ristretto di persone specializzate nel dominio del problema. E in questo io non vedo che vantaggi.
IMHO l'informatica non è quasi mai un'attività scientifica, perchè ha diversi livelli ed è punto di incontro sia di scienza sia di tecnica...
in pratica è una scienza che studia una tecnica.
-c'è il livello in cui "si usa roba" qui qualsiasi modello va a farsi benedire, e contano costi, tempo, e la guida del software;
-poi si sale sempre di più, fino magari a giungere alle simulazioni, ma oggi è impossibile una corrispondenza completa fra programma e modello...
questo perchè astrarre è spesso fonte di pesanti rallentamenti o peggio proprio impossibile.
Per cui credo che teoremi a parte, applicare esattamente un modello diverrà possibile quando si avrà abbastanza potenza da "sprecare" in layers di astrazione, e quando qualcuno avrà scritto questi ultimi...
l'evoluzione è tuttora in atto, basta paragonare la coerenza dei nuovi linguaggi con l'ammasso di hacks necessario per fare qualcosa in C :asd:
~FullSyst3m~
24-05-2009, 01:02
bene, ma in assenza di regole universali, cosa facciamo? smettiamo di parlare di metodi di programmazione perché non abbiamo altro che una serie di insiemi di criteri empirici non riconducibili ad una teoria unitaria, sistematica e falsificabile?
il problema è che stiamo parlando di una branca dell'attività umana che non può prescindere dall'essere umano stesso: ci sono temi sociali e cognitivi che di per sè non sono descrivibili scientificamente. Ma abbiamo necessità di parlare di questo genere di attività e di questo genere di tematiche. E quindi cosa facciamo?
In questo senso stiamo parlando di ingegneria del software più che di informatica in senso lato. E l'ingegneria del software non si può ancora chiamarla scienza.
Perchè l'ingegneria del software non è una parte, a mio parere importante, dell'informatica?
No. I teoremi che ho citato prima lasciano poche speranze agli informatici, sul piano prettamente teorico.
In che senso?
IMHO l'informatica non è quasi mai un'attività scientifica, perchè ha diversi livelli ed è punto di incontro sia di scienza sia di tecnica...
in pratica è una scienza che studia una tecnica.
-c'è il livello in cui "si usa roba" qui qualsiasi modello va a farsi benedire, e contano costi, tempo, e la guida del software;
-poi si sale sempre di più, fino magari a giungere alle simulazioni, ma oggi è impossibile una corrispondenza completa fra programma e modello...
questo perchè astrarre è spesso fonte di pesanti rallentamenti o peggio proprio impossibile.
Per cui credo che teoremi a parte, applicare esattamente un modello diverrà possibile quando si avrà abbastanza potenza da "sprecare" in layers di astrazione, e quando qualcuno avrà scritto questi ultimi...
l'evoluzione è tuttora in atto, basta paragonare la coerenza dei nuovi linguaggi con l'ammasso di hacks necessario per fare qualcosa in C :asd:
Qua il discorso è molto più ampio, ma a mio parere non si può considerare l'informatica come "non scienza". Per me è una scienza eccome. Basta guardare i cambiamenti, l'allargamento e le "scoperte" che sono state fatte dagli anni 50 fino ad ora.
cdimauro
24-05-2009, 08:11
Ciò detto preciso che a me della dimostrabilità matematica di un programma non me ne importa un fico secco.
Bene. Quindi un punto fermo l'abbiamo, e possiamo passare dalla teoria alla pratica. :D
Più precisamente, possiamo convenire che l'unica certezza che la teoria dà a noi programmatori è che... non v'è nessuna certezza di correttezza di ciò che sviluppiamo :D, sia esso un modello che il codice finale (tanto formalmente parlando non v'è nessuna differenza: sono entrambe rappresentazioni di un fenomeno, a un diverso livello di astrazione).
A me la programmaziona funzionale ha sempre fatto schifo.
A me piaceva quando ho studiato Scheme all'università. Poi, però, quando ho studiato subito dopo il Prolog, mi ha fatto schifo perché sono rimasto affascinato dalla programmazione logica (ed è interessante l'approccio di Erlang, che col suo meccanismo di pattern-matching mi ricorda molto l'approccio logico alla risoluzione dei problemi).
Detto ciò, può fare schifo o meno, ma un qualunque programma si può pensare espresso come un'unica funzione dotata di un unico argomento. E questo ai matematici farà molto piacere, come pure agli informatici teorici, perché ha permesso a Turing, Goedel, Kleen, Church di tirare fuori tante "belle cose" che, però, agli informatici più "pratici" fanno semplicemente ribrezzo. :asd:
In buona sostanza, sto parlando di quella robaccia che ho esplicitato a inizio messaggio. :D
Quello che mi preme è invece l'esistenza di una corrispondenza tra il codice ed il modello e non dal punto di vista dell'output ma dal punto di vista del significato che il codice esprime (Verifica iterativa per consentire l'introduzione di cambiamenti in corso d'opera).
Per due ragioni. La prima è che grazie alle prospettive il modello può essere definito da persone che non abbiano necessariamente un background informatico. La seconda è che il modello può gestito da un numero ristretto di persone specializzate nel dominio del problema. E in questo io non vedo che vantaggi.
Ma formalmente sai bene che utilizzare un modello piuttosto che un altro non ha nessuna importanza: uno vale l'altro.
La teoria s'è fermata al punto sottolineato sopra. E non può dirci alcunché sul fatto che un modello sia più "vantaggioso" di un altro.
Ciò proprio perché adesso ci siamo spostati su un piano che non è più rigoroso e, soprattutto, "formalizzabile". L'essere "vantaggioso" è, infatti, un concetto che ha un valore prettamente personale che trascende dalla teoria.
In altre parole, usciamo dalla "scientificità" ed entriamo nella "moralità". Che poi, se mi permetti, vuol dire entrare nella vita di tutti i giorni del tipico programmatore, che ha davanti un problema concreto da risolvere, e per il quale cerca delle soluzioni che per lui rappresentino un "buon compromesso" fra costi / benefici.
Costi e benefici anche qui difficilmente formalizzabili, perché l'ingegneria del software non è certo una scienza esatta, e quando mi parla di "qualità" del codice, di "manutenibilità", ecc. si affida a termini che sono più che altro convenzioni.
Da qui in poi subentrano le diatribe sui modelli di sviluppo del codice che ci sono tanto cari, ma per il momento mi fermo. :D
IMHO l'informatica non è quasi mai un'attività scientifica, perchè ha diversi livelli ed è punto di incontro sia di scienza sia di tecnica...
in pratica è una scienza che studia una tecnica.
ma non è così visto che si devono studiare teoremi scientifici che dimostrano che non tutti i problemi sono risolvibili da algoritmi.
E vi sono teoremi scientifico-matematici atti a dimostrare algoritmi ottimi et similia.
Anche a livello utente l'informatica permette di fare attività scientifica: vedi i vari programmi usati per fare ricerca; chiaramente lo sviluppo di un database, dipende a che livello, può non essere una attivitò scientifica se ci si limita ad usare gli strumenti a disposizione senza cercare l'ottimo.
IMHO
Hai dimenticato "e cercare di farsi pagare quella fattura". Specialmente se hai già versato l'IVA:
esatto. ora il vero significato di programmare è svelato.
...omissis...
Non v'è certezza assoluta ma può esserci certezza relativa accettando i famosi assiomi.
Concordo assolutamente sul fatto che un modello valga l'altro: per me il modello è arbitrario in linea di principio. Punto sulla "verificabilità" del codice in quanto adesione a quel modello. Nel codice potrei scrivere un'orripilante schifezza ma se quella schfezza esprime lo stesso significato del modello allora è perfettamente valida.
cdimauro
24-05-2009, 15:30
Bisogna vedere poi se il modello stesso sia "valido" (intendendo con ciò che tutti i requisiti del fenomeno modellato vengano rispettati e non ci siano "errori").
Parlare di codice o modello non fa differenza: quel che conta è sapere se la soluzione che abbiamo trovato faccia quel che ci aspettiamo. E qui, appunto, non v'è alcuna certezza. :D
Fissato questo punto possiamo lasciar perdere la teoria e addentrarci nella pratica. Cioé vedere se ha senso parlare di "vantaggi" di un modello piuttosto che di un altro, e quali potrebbero essere questi "vantaggi", in che modo si potrebbero "misurare" (vabbé, dico subito che di misurabile ci sarà ben poco, così non alimentiamo altre false illusioni :D), ecc.
In tre parole: fuoco alle polveri. :D
Se parliamo di programmazione parliamo di codice. E per me l'unico metro di valutazione obiettivo del codice è la sua corrispondenza al modello.
La definizione del modello, che riguarda diciamo lo "sviluppo" in generale più che la programmazione nello specifico, è come detto arbitraria.
Non essendo obiettivamente dimostrabile che un modello sia migliore di un altro ogni modello è valido alla stessa maniera.
Poi io ho quell'idea di ciclo di sviluppo software ma è una questione off-topic (ammesso che ci sia un off-topic in un thread sulla scienza e sulla morale :D). Per me si potrebbe fare così ma è un modo diverso di fare le cose, non necessariamente migliore.
cdimauro
24-05-2009, 16:00
Se parliamo di programmazione parliamo di codice. E per me l'unico metro di valutazione obiettivo del codice è la sua corrispondenza al modello.
La definizione del modello, che riguarda diciamo lo "sviluppo" in generale più che la programmazione nello specifico, è come detto arbitraria.
Non essendo obiettivamente dimostrabile che un modello sia migliore di un altro ogni modello è valido alla stessa maniera.
In buona sostanza, la diatriba nemmeno nasce: la discussione finisce qui senza neppure partire. :p
Poi io ho quell'idea di ciclo di sviluppo software ma è una questione off-topic (ammesso che ci sia un off-topic in un thread sulla scienza e sulla morale :D). Per me si potrebbe fare così ma è un modo diverso di fare le cose, non necessariamente migliore.
Anche perché poi dovremmo definire cosa s'intende per "migliore". :fiufiu: :D
Be' dipende se convieni o no con l'idea che il modello sia arbitrario e se convieni o no con l'idea che l'unico metro di giudizio del codice sia la corrispondenza al modello.
Insomma, tocca a voi vuotare il sacco adesso.
cdimauro
24-05-2009, 16:23
Il problema è che, appunto, il modello è arbitrario. E in teoria potrei costruirmi un modello (o prospettiva) per ogni codice che intendo scrivere.
Che poi alla fine è ciò che facciamo (mischiare ad libidium), perché non esiste nessun linguaggio di programmazione che sia assolutamente e perfettamente aderente al modello scelto. Nel senso che ogni linguaggio offre delle caratteristiche "prese in prestito" da diversi modelli (anche se uno è "dominante").
Ora non voglio tirare in ballo nuovamente la parola "semplice" per rompere le uova nel paniere per l'n-esima volta ma, per per fare un esempio pratico, le stringhe in Java non si costruiscono:
- creando un'istanza della classe String;
- eseguendo un "append" (o concat) un carattere alla volta di quelli che devono costituire la stringa.
Che non è esattamente "semplice" per qualunque essere umano che non sia un masochista autolesionista. Perché la gente "normale" preferisce i più comodi "shortcut" che consentono di specificare direttamente tutti i caratteri di cui è costituita la stringa.
Questo sempre se ho capito il tuo concetto di "modello" e se non ho detto delle assurdità. Nel qual caso hai fatto bene ad affilare la lama dell'ascia, perché la mia testa è pronta sul ceppo. :D
magix2003
24-05-2009, 16:41
Mi intrometto per dire che anche un linguaggio di programmazione può essere visto come un modello, così come qualunque altro linguaggio di rappresentazione della conoscenza...
Credo che non sia questo che io intendo per adesione al modello. Esempio. Supponiamo che il progetto dichiari la necessità che esista nel sistema una persona il cui nome è Mario. Uno potrebbe essere tentato di dire:
class Persona(object):
def __init__(self, aString):
self.name = aString
def getName(self):
return self.name
mario = Persona("Mario")
Ma è corretto nel senso di aderente al modello? Ovviamente no. Il significato del codice eccede quello espresso nel modello. Io definisco l'esistenza di molte persone, ognuna delle quali è caratterizzata dal possesso di un'infinità di nomi. In Python "Mario" non può che essere un modulo in cui è definita una funzione che restituisce una costante (il letterale "Mario") ed esiste una funzione che attribuisce a Mario la qualità di Persona in via esclusiva.
Questo è un esempio di ciò che intendo per adesione del codice al modello.
cdimauro
24-05-2009, 17:08
OK, ma come fai a essere sicuro che il codice soddisfi i requisiti del modello?
E' chiaro che
mario = Persona("Mario")
soddisfi quel vincolo, ma in maniera banale e, come dici tu, eccessiva. Ma lo soddisfa.
Le due funzioni di cui parli potrebbero fare il lavoro che dici, ma a questo punto a me viene in mente la TDD, e il "caro" Kent Beck... :D
Nel senso che con la TDD posso esprimere il vincolo di cui parli, e "forzare" il codice a soddisfarlo (non so se ho reso l'idea).
Tu parli di output ma io parlo di rappresentazione.
La TDD verifica gli eccessi dell'output di un programma rispetto ai limiti dell'insieme di valori a cui quell'output appartiene.
Il codice su riportato dice una cosa diversa da quella che è stata richiesta, diversità che è rilevabile dall'applicazione delle regole del linguaggio adottato (name non è una costante, Persona ammette sottotipi, Persona è istanziabile).
cdimauro
24-05-2009, 19:39
Io vedo il modello come la formalizzazione dei requisiti che devono essere soddisfatti dal progetto.
Se i requisiti vengono formalizzati, vedo "naturale" definire dei test che... li soddisfino.
Da questo punto di vista i test si possono considerare una rappresentazione dei requisiti.
Ricordiamo pure che a noi programmatori interessa che i requisiti debbano essere soddisfatti e, quindi, in ultima istanza proprio l'output della nostra applicazione.
Questo anche se non abbiamo alcuna certezza che il codice che abbiamo scritto li soddisfi. :fagiano:
akfhalfhadsòkadjasdasd
24-05-2009, 23:28
L'idea che un programma sia un quadro dipinto in un momento di estasi artistica a me suona quantomeno bizzarra.
Direi che è solo questione di semantica di quanto è rappresentato in quei due linguaggi.
Non "fallo semplice" ma "fallo esatto".
Ma forse è più questione: "se lo sai fare esatto vedi anche se riesci a farlo semplicemente". Lo dico perché altrimenti kiss non avrebbe senso, da solo :fagiano:
A me l'unico problema che pone Kiss è quanto semplice devo essere affinché la maggior parte della gente comprende quanto ho scritto. "Semplice" potrebbe anche voler dire scrivere più codice e per me complicare la questione. Kiss per me ha davvero senso se non sono l'unico a lavorare ad un programma oppure se dopo un paio di anni devo tornarci su a capire che ho fatto.
apro questo thread in seguito a una proposta avanzata in un'altra discussione (http://www.hwupgrade.it/forum/showthread.php?t=1985932).
Inizio la discussione dicendo che mi trovo in disaccordo con PGI-bis: la programmazione è un'attività con una fortissima componente umana e creativa e, in quanto tale, non può essere ridotta a una mera questione quantitativa. Inoltre, la qualità del codice (misurabile attraverso un insieme di metriche - non universalmente accettate), ha ripercussioni quantitative evidenti.La programmazione è umana e creativa semplicemente perché se ne occupano gli uomini.
Riguardo la OO dico che classificare è umano e la OOP si rifà alla classificazione delle cose, a dire cose di un oggetto per differenziarlo da altro. E' proprio così che conosciamo le cose.
cdimauro
25-05-2009, 06:10
Il problema è che non siamo e non possiamo essere assolutamente sicuri che il programma che abbiamo realizzato sia corretto.
Cioé che l'output che ci aspettiamo a fronte degli input previsti, sia quello desiderato.
Questa è l'unica cosa che c'interessa come programmatori, e di cui purtroppo non possiamo avere la sicurezza.
Hai parlato di semplicità, ma la semplicità non è formalizzabile. Però siamo esseri umani, e pur non potendo essere assolutamente rigorosi nel definire una cosa "semplice" o "complicata", riusciamo comunque a dare una (nostra personalissima) risposta.
Per me vuol dire una cosa: che dove si ferma la teoria subentra l'estro dell'uomo. Che ha portato alla creazione di prospettive e di metodologie di sviluppo. Che non diranno nulla sul piano formale, ma che una mano nel lavoro di tutti i giorni bene o male riescono a darcela. ;)
banryu79
25-05-2009, 09:31
Tu parli di output ma io parlo di rappresentazione.
PGI, non ho capito.
Di una applicazione creata: è più importante, inteso come risultato finale, l'aderenza più esatta possibile tra sistema di riferimento e sua rappresentazione nel linguaggio di implementazione oppure l'aderenza più esatta possibile tra output desiderati/attesi dal customer e output prodotti dall'applicazione?
C'è una correlazione diretta tra i due aspetti?
Sono sempre in proporzione diretta tra loro?
Io non lo so, la logica mi suggerisce che dovrebbero esserlo, ma "qualcos'altro" mi fa interrogare in proposito, e mi fa prendere in considerazione che non è detto che lo siano sempre.
Un motivo che mi fa "sospettare" questo è che nell'utilizzare un linguaggio XYZ di programmazione, per realizzare la traduzione del "modello di riferimento", avrò a che fare con le idiosincrasie e particolarità del linguaggio stesso (e del suo ambiente di sviluppo, inteso come librerie).
Se parliamo di programmazione parliamo di codice. E per me l'unico metro di valutazione obiettivo del codice è la sua corrispondenza al modello.
La definizione del modello, che riguarda diciamo lo "sviluppo" in generale più che la programmazione nello specifico, è come detto arbitraria.
Non essendo obiettivamente dimostrabile che un modello sia migliore di un altro ogni modello è valido alla stessa maniera.
Premessa:
- la definizione del modello è arbitraria;
- non è dimostrabile che un modello sia migliore di un altro modello;
[deduco che non resti che l'aderenza esatta del codice al modello scelto come unica certezza]
Aggiungo un'altra premessa:
- per il customer/utente è importante che l'output prodotto sia aderente all'output atteso.
Ipotesi:
- l'aderenza esatta tra codice del software e modello scelto non è importante.
- l'aderenza esatta tra output prodotto del software e output atteso dall'utente è importante.
E' leggittima questa deduzione o c'è un vizio?
La corrispondenza dell'output del programma all'output del modello (che è poi la rappresentazione di ciò che si pensa voglia il cliente) è una conseguenza della corrispondenza tra il programma e il modello. E' compreso nel pacchetto, insomma.
mad_hhatter
25-05-2009, 10:40
La corrispondenza dell'output del programma all'output del modello (che è poi la rappresentazione di ciò che si pensa voglia il cliente) è una conseguenza della corrispondenza tra il programma e il modello. E' compreso nel pacchetto, insomma.
certo, ma siamo sicuri che quello che vogliamo è la miglior rappresentazione possibile del modello? non possono esserci situazioni in cui è sufficiente una corretta funzione di trasferiemento?
Più che altro è l'unica cosa che si può controllare con esattezza.
mad_hhatter
25-05-2009, 10:51
Più che altro è l'unica cosa che si può controllare con esattezza.
che cosa? il modello o la relazione I/O?
no, la corrispondenza tra modello e programma (modello espresso in un linguaggio formale, ovviamente).
banryu79
25-05-2009, 11:27
no, la corrispondenza tra modello e programma (modello espresso in un linguaggio formale, ovviamente).
E' l'unica cosa che si può controllare con certezza.
Il programma è formalizzato e concretizzato dalla sua rappresentazione tramite codice sorgente, accessibile, e quindi verificabile, a tutti coloro che conoscono il linguaggio utilizzato e le eventuali librerie utilizzate.
Esso è anche una rappresentazione del modello di riferimento.
Ma il modello di riferimento concettuale, di per se, come può essere documentato? Perchè altrimenti come può essere fatto un controllo significativo che dica se la sua traduzione in codice è aderente all'idea originaria o meno?
Che dica quindi se il codice è sbagliato o meno, non tanto per via di bug tecnici, ma per "non aderenza" di rapprentazione del modello di referimento?
Ha senso fare questa distinzione, tra bug tecnici (errori di programmazione) e errori di rappresentazione del modello?
Ci sarebbe poi la questione di quale sia il sistema corretto di rappresentazione del modello di riferimento sotto forma di documento. Cioè di qualcosa di fruibile per tutte le persone coinvolte nello sviluppo del software.
Già il concretizzare questa rappresentazione implica una trasformazione dalla forma originiaria del modello di riferimento, fatta di un insieme di elementi concettuali ricavati da proposizioni e asserzioni fornite dal cliente al developer. Ma questo è un'altro problema.
Un linguaggio di "modeling" può esprimere un modello software nei più intimi dettagli. Basti pensare ai diagrammi UML: puoi arrivare fino al proverbiale pelo nell'uovo a colpi di diagrammi di classe, sequenza e stato. Ovviamente bisogna conoscerlo ma se uno conosce un linguaggio di programmazione può benissimo apprendere un linguaggio di modellazione.
mad_hhatter
25-05-2009, 11:48
Un linguaggio di "modeling" può esprimere un modello software nei più intimi dettagli. Basti pensare ai diagrammi UML: puoi arrivare fino al proverbiale pelo nell'uovo a colpi di diagrammi di classe, sequenza e stato. Ovviamente bisogna conoscerlo ma se uno conosce un linguaggio di programmazione può benissimo apprendere un linguaggio di modellazione.
ok, ma siamo sempre lì. come controlliamo che il modello UML sia corretto?
Un linguaggio di "modeling" può esprimere un modello software nei più intimi dettagli. Basti pensare ai diagrammi UML: puoi arrivare fino al proverbiale pelo nell'uovo a colpi di diagrammi di classe, sequenza e stato. Ovviamente bisogna conoscerlo ma se uno conosce un linguaggio di programmazione può benissimo apprendere un linguaggio di modellazione.
È vero che si può arrivare a specificare ogni singolo dettaglio dell'applicazione tramite uno strumento come UML ma ci vuole veramente troppo tempo prima di arrivare ad un prodotto finito da consegnare al committente. Secondo me quello che proponi non sarebbe fattibile economicamente nemmeno da grosse società.
banryu79
25-05-2009, 12:31
ok, ma siamo sempre lì. come controlliamo che il modello UML sia corretto?
e
È vero che si può arrivare a specificare ogni singolo dettaglio dell'applicazione tramite uno strumento come UML ma ci vuole veramente troppo tempo prima di arrivare ad un prodotto finito da consegnare al committente. Secondo me quello che proponi non sarebbe fattibile economicamente nemmeno da grosse società.
Ecco, è il nocciolo della questione.
Siamo partiti, nella nostra piccola indagine, a considerare l'aspetto di formalismo logico e teoria su cui si basa l'attività di programmazione fino a includere con il discorso gli aspetti pratici dello sviluppo software nella realtà; aspetti con cui bisogna fare i conti, pena il relegare tutte le considerazioni fatte in un mondo ideale fatto di sola teoria.
Perchè un conto è ragionare e stabilire cosa sia un software, cosa sia un modello; un conto decidere come produrre un software nella realtà dopo aver deciso come rappresentare il problema/soluzione che si va implementando nel software.
Il software non è il problema/soluzione; il problema/soluzione, di per se, è un altra cosa, è una cosa diversa dalla sua rappresentazione.
Proprio come la parola albero è un'altra cosa, non è l'albero, di per se, ne lo è il flusso di concetti che la parola 'albero' evoca dentro di noi.
Quello che voglio dire è che se "il rigore scientifico" espresso circa il modo di essere di una cosa o il modo di fare una cosa non trova riscontro nell'applicazione pratica della realtà, verrà inevitabilmente sostituito con qualche pratica non scientifica ma che produce il risultato desiderato, la dove ve ne sia un bisogno non soddisfatto.
Da cui Refactoring e compagnia bella.
Non sono scientifici: d'accordo. Ma sono dichiarati come utili, "utili" in senso pratico, sperimentale: può essere vero per me, che li ho provati e ne traggo un risultato che io dico per me vantaggioso in relazione al non utilizzarli; può non esserlo per te che li hai provati e ne hai tratto un risultato che tu dici svantaggioso in relazione al non utilizzarli (o all'utilizzare altro).
Che poi Flower e Beck non specifichino nei loro testi che "le asserzioni qui esposte non sono provate scientificamente", d'accordo.
Non penso nessuno (ho seguito anche i thread passati, come lettore) abbia mai sostenuto una presunta validità scientifica di tali metodologie.
Spero di non aver "dirottato" il thread... alla fine, anzi, all'inizio, non eravamo partiti da questa annosa questione?
cdimauro
25-05-2009, 12:54
Formalmente non v'è alcuna differenza fra un qualunque codice e un qualunque modello.
Come dicevo prima, il problema della correttezza è semplicemente spostato, quindi continua a valere quanto presente nella teoria della computabilità. Non cambia una virgola.
Dunque parlare di modelli e di codice è equivalente. Anzi, a mio avviso è del tutto inutile effettuare un distinguo, perché semplicemente si duplicano le considerazioni fatte per gli uni e gli altri.
Parliamo a questo punto di algoritmi, che è meglio, perché si abbraccia la qualunque: codice e modello.
E fissiamo anche un paio di punti.
Il primo è che non abbiamo alcuna certezza sull'aderenza o meno di un algoritmo ai requisiti che deve soddisfare.
Il secondo è che, come programmatori, a noi interessa che un algoritmo soddisfi i requisiti per cui è nato.
Detto ciò, possiamo anche abbandonare la teoria e passare alla pratica, che a mio avviso è molto più interessante (visto che è quella che ci fa portare il pane a casa :p).
akfhalfhadsòkadjasdasd
25-05-2009, 13:30
Dunque parlare di modelli e di codice è equivalente. Anzi, a mio avviso è del tutto inutile effettuare un distinguo, perché semplicemente si duplicano le considerazioni fatte per gli uni e gli altri.
Parliamo a questo punto di algoritmi, che è meglio, perché si abbraccia la qualunque: codice e modello.
Il secondo è che, come programmatori, a noi interessa che un algoritmo soddisfi i requisiti per cui è nato.
Non saprei... io se in teoria mi studio l'algoritmo del simplesso ho insiemi numerici infiniti a disposizione per trattare TUTTE le istanze. L'algoritmo come è formalizzato in teoria non prevede che si usino mezzi limitati... double, float... oppure un oggetto numero fatto appositamente (che però sarà sempre limitato dalla macchina).
In realtà io vedo un stacco netto tra modello e la modellazione in ambito reale su risorse reali e tangibili (mai infinite)
mad_hhatter
25-05-2009, 13:44
Formalmente non v'è alcuna differenza fra un qualunque codice e un qualunque modello.
Come dicevo prima, il problema della correttezza è semplicemente spostato, quindi continua a valere quanto presente nella teoria della computabilità. Non cambia una virgola.
Dunque parlare di modelli e di codice è equivalente. Anzi, a mio avviso è del tutto inutile effettuare un distinguo, perché semplicemente si duplicano le considerazioni fatte per gli uni e gli altri.
Parliamo a questo punto di algoritmi, che è meglio, perché si abbraccia la qualunque: codice e modello.
E fissiamo anche un paio di punti.
Il primo è che non abbiamo alcuna certezza sull'aderenza o meno di un algoritmo ai requisiti che deve soddisfare.
Il secondo è che, come programmatori, a noi interessa che un algoritmo soddisfi i requisiti per cui è nato.
Detto ciò, possiamo anche abbandonare la teoria e passare alla pratica, che a mio avviso è molto più interessante (visto che è quella che ci fa portare il pane a casa :p).
il fatto è che anche a livello cognitivo è così. ogni rappresentazione è di per sè un modello.
la stessa conoscenza scientifica non certifica mai la correttezza dei suoi modelli.
E in ogni caso, nella pratica subentrano tutta una serie di considerazioni e di fattori che la teoria normalmente non prende in considerazione. Nessuna dimostrazione si chiede se la soluzione abbia costi e tempi ragionevoli, se sia comprensibile e/o mantenibile, se l'affiatamento del team sia buono o meno. Vengono lasciate fuori fattori che nella quotidianità sono addirittura più importanti della soluzione in sè.
cdimauro
25-05-2009, 13:46
Non saprei... io se in teoria mi studio l'algoritmo del simplesso ho insiemi numerici infiniti a disposizione per trattare TUTTE le istanze. L'algoritmo come è formalizzato in teoria non prevede che si usino mezzi limitati... double, float... oppure un oggetto numero fatto appositamente (che però sarà sempre limitato dalla macchina).
In realtà io vedo un stacco netto tra modello e la modellazione in ambito reale su risorse reali e tangibili (mai infinite)
Vero, ma considera che le variabili in gioco fanno esplodere esponenzialmente le possibilità per cui la distinzione fra "finito" e "infinito" è trascurabile.
Esempio: se ho interi a 32 bit e utilizzo una variabile, le combinazioni possibili sono 2^32 = 4 miliardi circa. Se ho due variabili salgono a 2^(32 + 32) = 2^64 = 16 exabyte (miliardi di miliardi). E così via.
il fatto è che anche a livello cognitivo è così. ogni rappresentazione è di per sè un modello.
la stessa conoscenza scientifica non certifica mai la correttezza dei suoi modelli.
E in ogni caso, nella pratica subentrano tutta una serie di considerazioni e di fattori che la teoria normalmente non prende in considerazione. Nessuna dimostrazione si chiede se la soluzione abbia costi e tempi ragionevoli, se sia comprensibile e/o mantenibile, se l'affiatamento del team sia buono o meno. Vengono lasciate fuori fattori che nella quotidianità sono addirittura più importanti della soluzione in sè.
Ecco perché per me è più importante passare alla valutazione della "pratica" anziché fermarsi alla sola teoria. ;)
mad_hhatter
25-05-2009, 13:47
Non saprei... io se in teoria mi studio l'algoritmo del simplesso ho insiemi numerici infiniti a disposizione per trattare TUTTE le istanze. L'algoritmo come è formalizzato in teoria non prevede che si usino mezzi limitati... double, float... oppure un oggetto numero fatto appositamente (che però sarà sempre limitato dalla macchina).
In realtà io vedo un stacco netto tra modello e la modellazione in ambito reale su risorse reali e tangibili (mai infinite)
hai semplicemente a che fare con assunti o vincoli diversi. ma il concetto non cambia
banryu79
25-05-2009, 14:11
il fatto è che anche a livello cognitivo è così. ogni rappresentazione è di per sè un modello.
Ok.
Ma il problema ora è che il modo in cui tu ti [usi la mente sia come 'creatore' della rappresentazione che come osservatore della stessa] rappresenti a livello cognitivo la soluzione può differire dal modo in cui io me la rappresento, e può essere diverso ancora dal modo con cui il nostro terzo collega se la rappresenta... eccetera.
Stabilito che l'unica certezza deriva dalla controllabilità della corrispondenza tra modello e programma, e da una parte abbiamo codice sorgente, dall'altra cosa ci mettiamo, dato che non possiamo condividere la nostra rappresentazione cognitiva mentale tutti assieme?
UML dice qualcuno.
Pratico fino a un certo punto, dice qualcun'altro.
Rilancio con il TDD, a questo punto, considerandolo nel suo ruolo di strumento dell'Agile 'n' eXtreme Programming; e dentro sono incluse le pratiche di refactoring.
Poco scientifico? Forse, ma cosa avrebbe di diverso, diciamo dall'UML?
@EDIT:
l'UML è un linguaggio formale?
mad_hhatter
25-05-2009, 14:13
Ok.
Ma il problema ora è che il modo in cui tu ti [usi la mente sia come 'creatore' della rappresentazione che come osservatore della stessa] rappresenti a livello cognitivo la soluzione può differire dal modo in cui io me la rappresento, e può essere diverso ancora dal modo con cui il nostro terzo collega se la rappresenta... eccetera.
Stabilito che l'unica certezza deriva dalla controllabilità della corrispondenza tra modello e programma, e da una parte abbiamo codice sorgente, dall'altra cosa ci mettiamo, dato che non possiamo condividere la nostra rappresentazione cognitiva mentale tutti assieme?
UML dice qualcuno.
Pratico fino a un certo punto, dice qualcun'altro.
Rilancio con il TDD, a questo punto, considerandolo nel suo ruolo di strumento dell'Agile 'n' eXtreme Programming; e dentro sono incluse le pratiche di refactoring.
Poco scientifico? Forse, ma cosa avrebbe di diverso, diciamo dall'UML?
mi trovi d'accordo
banryu79
25-05-2009, 14:28
Si ma io volevo capire lo spirito dietro la critica mossa alla natura scientifica delle pratiche di Refactoring:
UML è un linguaggio formale, è cioè scientifico, perchè è falsificabile?
Mentre il presunto vantaggio derivante dalle applicazioni delle tecniche di Refactoring non sono scientifiche perchè non sono falsificabili in termini di teoria scientifica?
E' questo che vorrei capire.
mad_hhatter
25-05-2009, 14:48
Si ma io volevo capire lo spirito dietro la critica mossa alla natura scientifica delle pratiche di Refactoring:
UML è un linguaggio formale, è cioè scientifico, perchè è falsificabile?
Mentre il presunto vantaggio derivante dalle applicazioni delle tecniche di Refactoring non sono scientifiche perchè non sono falsificabili in termini di teoria scientifica?
E' questo che vorrei capire.
credo che il problema sia dato dal fatto che non c'è un obiettivo formalizzato per il refactoring. Come stabilire cosa rifattorizzare? Come stabilire se un refactoring è un progresso o un regresso? Come stabilire quando ho finito? Credo PGI intenda questo. Però non mi trova d'accordo, o almeno, non completamente
cdimauro
25-05-2009, 14:50
UML è un linguaggio, al pari di qualunque altro. Pertanto utilizzare UML o Python o altro per creare un modello è indifferente.
banryu79
25-05-2009, 16:15
UML è un linguaggio, al pari di qualunque altro. Pertanto utilizzare UML o Python o altro per creare un modello è indifferente.
Benone, ma se lavoriamo in 4 in un progetto in Python e il modello del sistema di riferimento lo scriviamo direttamente in Python con che cosa lo facciamo il confronto per stabilire se il codice sorgente del programma aderisce appunto al modello del sistema di riferimento?
Perchè se sono da solo a lavorarci, il confronto lo posso anche fare (forse) con il modello del sistema di riferimento che ho nella mia mente, non negli altri casi (sviluppiamo in due o più).
E se ne va al diavolo anche l'unica certezza che fin qua avevamo stabilito :D
no, la corrispondenza tra modello e programma (modello espresso in un linguaggio formale, ovviamente).
E' l'unica cosa che si può controllare con certezza.
magix2003
25-05-2009, 18:01
Ok.
@EDIT:
l'UML è un linguaggio formale?
Si, UML, come quasi tutti i linguaggi concettuali, può venire tradotto in una teoria logica di primo ordine. (ancora meglio in una description logic (http://en.wikipedia.org/wiki/Description_logic))
Questo significa anche che è possibile ragionare su un modello UML e vedere se è consistente.
cdimauro
25-05-2009, 19:45
Benone, ma se lavoriamo in 4 in un progetto in Python e il modello del sistema di riferimento lo scriviamo direttamente in Python con che cosa lo facciamo il confronto per stabilire se il codice sorgente del programma aderisce appunto al modello del sistema di riferimento?
Perchè se sono da solo a lavorarci, il confronto lo posso anche fare (forse) con il modello del sistema di riferimento che ho nella mia mente, non negli altri casi (sviluppiamo in due o più).
E se ne va al diavolo anche l'unica certezza che fin qua avevamo stabilito :D
L'unica cosa che ci interessa è sapere se un qualunque linguaggio è Turing-completo oppure no. Se è Turing-completo is applica tutto ciò che ho detto finora riguardo alla teoria della computabilità e, quindi, sull'assenza di certezza per quanto riguarda l'aderenza o meno ai requisiti dei programmi scritti in tale linguaggio.
Dunque la domanda da porsi è questa: UML è un linguaggio Turing-completo?
La risposta a quanto pare è sì, a partire dalla versione 2.0 di questo linguaggio, ossia da quando sono state introdotte le "action semantics".
Fine della certezze anche per l'UML. :D
Vediamo se possiamo fiondarci finalmente sulla pratica. :p
_Claudio
25-05-2009, 20:18
L'unica cosa che ci interessa è sapere se un qualunque linguaggio è Turing-completo oppure no. Se è Turing-completo is applica tutto ciò che ho detto finora riguardo alla teoria della computabilità e, quindi, sull'assenza di certezza per quanto riguarda l'aderenza o meno ai requisiti dei programmi scritti in tale linguaggio.
Dunque la domanda da porsi è questa: UML è un linguaggio Turing-completo?
La risposta a quanto pare è sì, a partire dalla versione 2.0 di questo linguaggio, ossia da quando sono state introdotte le "action semantics".
Fine della certezze anche per l'UML. :D
Vediamo se possiamo fiondarci finalmente sulla pratica. :p
Concordo, a fronte delle specifiche, prima si verifica che un problema è di classe P perchè della classe NP non sappiamo che farcene e tantomeno cercheremo di risolvere problemi indeterministici.
In caso si verifica se è riducibile (riducendo quindi le specifiche) e poi si possono usare tutti i modelli (UML), linguaggi e algoritmi che si vuole, ma l'importante è realizzare qualcosa di pratico, funzionante e aderente alle specifiche (ridotte) se queste sono accettabili.
Trastullarsi oltre il necessario sulla teoria e i formalismi non porta soldi sul conto a meno che non si è ricercatori informatici o matematici... spesso malpagati.
cdimauro
27-05-2009, 07:12
Up. :fagiano:
^TiGeRShArK^
27-05-2009, 07:32
Up. :fagiano:
mah...
io sarà talebano forse, ma per me tutta questa discussione sulla teorica possibilità di confrontare la correttezza di un programma con quella del modello è inutile.
Infatti chi ci dice che il modello che ci siamo creati è giusto?
Anzichè buttare sangue a crearci un modello giusto con un linguaggio formale e poi a tradurlo in codice e verificare che anch'esso sia giusto, trovo MOLTO + pratico utilizzare le varie tecniche dell'extreme programming.
Prima fra tutte il continous design, dato che mi pare che sia OVVIO a tutti (e se non lo è, dovrebbe esserlo) che tra teoria e pratica c'è un abisso e mettendosi a lavorare su un modello teorico che non ha la minima aderenza col prodotto finale si ignorano tutti gli aspetti di cui si potrà essere a conoscenza solo ed eslcusivamente scrivendo codice e ritrovandosi a sbattere la testa contro problemi che no si erano minimamente presi in considerazione.
E dato che anche il miglior programmatore al mondo NON è dio, ci sarà SEMPRE qualcosa che non si è presa in cosiderazione, ma, anzichè riprogettare l'intero modello con il linguaggio formale, sarà semplicemente possibile correggere il tiro tramite il continuous design.
Ecco, ora crocifiggetemi pure. :asd:
cdimauro
27-05-2009, 08:13
Allora dovrebbero preparare almeno due croci. :p
Secondo me c'è un problema di comunicazione e linguaggio ad ogni livello. Non solo tra modello ideale e rappresentazione nel codice.
Tipo cosi:
http://www.linuxkungfu.org/images/fun/geek/project.jpg
banryu79
27-05-2009, 08:48
"How the project was documented" è fantastica :rotfl:
mad_hhatter
27-05-2009, 13:55
mah...
io sarà talebano forse, ma per me tutta questa discussione sulla teorica possibilità di confrontare la correttezza di un programma con quella del modello è inutile.
Infatti chi ci dice che il modello che ci siamo creati è giusto?
Anzichè buttare sangue a crearci un modello giusto con un linguaggio formale e poi a tradurlo in codice e verificare che anch'esso sia giusto, trovo MOLTO + pratico utilizzare le varie tecniche dell'extreme programming.
Prima fra tutte il continous design, dato che mi pare che sia OVVIO a tutti (e se non lo è, dovrebbe esserlo) che tra teoria e pratica c'è un abisso e mettendosi a lavorare su un modello teorico che non ha la minima aderenza col prodotto finale si ignorano tutti gli aspetti di cui si potrà essere a conoscenza solo ed eslcusivamente scrivendo codice e ritrovandosi a sbattere la testa contro problemi che no si erano minimamente presi in considerazione.
E dato che anche il miglior programmatore al mondo NON è dio, ci sarà SEMPRE qualcosa che non si è presa in cosiderazione, ma, anzichè riprogettare l'intero modello con il linguaggio formale, sarà semplicemente possibile correggere il tiro tramite il continuous design.
Ecco, ora crocifiggetemi pure. :asd:
Allora dovrebbero preparare almeno due croci. :p
siamo a tre :D
Ma facciamo anche quattro :asd:
per quanto l'"eXtreme programming" mi sembra più che altro una nerdata (a cominciare dal nome :D ) pure pensare che io mi devo prefigurare ogni singolo possibile caso e quindi solo dopo partire, e se trovo un imprevisto faccio tutto da capo, mi sembra pazzia...
cdimauro
27-05-2009, 20:30
Togli pure il sembra: E' una pazzia. :D
Se c'è una cosa che un programmatore sa, è che i requisiti cambiano, spesso e pure in corso d'opera.
E un'altra cosa che sa è che se il cliente torna dopo 2 settimane a vedere a che punto siamo, preferisce di gran lunga un form con un bottone "OK" che magari non fa nulla, a dei fogli con dei diagrammi che non gli dicono proprio nulla. ;)
banryu79
04-06-2009, 11:57
Scusatemi se riporto "up" questa discussione in maniera veramente deplorevole con un copia-incolla da wikipedia, ma il concetto espresso nel quale mi sono imbattuto mi è sembrato in qualche modo appropriato al thread:
...
Turing poté dimostrare che un tale strumento , dalle caratteristiche così rigidamente definite, è in grado di svolgere un qualsiasi calcolo, ma non si fermò qui; egli capì che la calcolabilità era parente stretta della dimostrabilità e dunque, così come Gödel aveva distrutto i sogni di gloria dei Principia Mathematica di Russell e Whitehead, così le sue macchine potevano definitivamente chiudere la questione dell' Entscheidungsproblem.
Considerazione aggiuntiva:
Il problema di Turing, come i teoremi di Gödel, ha come sfondo l'autoreferenzialità. Ma entrambi per la loro natura "statica" mal si adattano ad una realtà "dinamica". L'apparente indecidibilità di un problema può effettivamente essere risolto alla luce del dato esperenziale. Non si vuole entrare qui nei meandri delle logiche decisionali, ma con un esempio comprensibile il miglior algoritmo evolutivo è quello che sopravvive nel tempo, ovvero alla prova dell'esperienza. La grande differenza tra una macchina di Turing e la mente umana è proprio il dato esperenziale che viene improvvidamente negato, in nome di un "meccanicismo platonico", alla prima. È proprio il dato esperenziale, aggiunto alla base assiomatica, che (pare) permettere di risolvere il problema dell'autoreferenzialità e quindi l'incompletezza. Questa dimostrazione è ancora ad uno stato preliminare di controllo e, allo stato attuale, deve intendersi quale congettura.
nota:
: la macchnia di Turing, naturalmente.
B|4KWH|T3
04-06-2009, 14:29
Non è l'induzione?
(da non confendere col principio di induzione in matematica)
banryu79
04-06-2009, 14:33
Se questa domanda:
Non è l'induzione?
(da non confendere col principio di induzione in matematica)
era riferita alla citazione nel mio precedente post:
Turing poté dimostrare che un tale strumento , dalle caratteristiche così rigidamente definite, è in grado di svolgere un qualsiasi calcolo, ma non si fermò qui
alora la risposta è no: si intende proprio la MdT
B|4KWH|T3
04-06-2009, 16:41
Se questa domanda:
era riferita alla citazione nel mio precedente post:
alora la risposta è no: si intende proprio la MdT
No no, scusami non ho quotato.
Mi riferivo a questa parte:
La grande differenza tra una macchina di Turing e la mente umana è proprio il dato esperenziale che viene improvvidamente negato, in nome di un "meccanicismo platonico", alla prima. È proprio il dato esperenziale, aggiunto alla base assiomatica, che (pare) permettere di risolvere il problema dell'autoreferenzialità e quindi l'incompletezza. Questa dimostrazione è ancora ad uno stato preliminare di controllo e, allo stato attuale, deve intendersi quale congettura.
banryu79
04-06-2009, 17:01
Ah, allora non saprei.
Quando parla di qualcosa di (neccessariamente) aggiunto "alla base assiomatica", credo faccia riferimento al limite della MdT, il problema della fermata, e per estensione, proprio per il fatto che parla di base assiomatica, al teorema dell'incompletezza di Godel: fatti che già sono emersi durante tutta la discussione nel thread e che ci hanno portato verso certe conclusioni piuttosto che altre.
Dice che questo qualcosa in più che fa la differenza fondamentale tra la mente umana e una MdT sia il 'dato esperienziale' (specifica che 'pare' sia questo e che sia in corso un non meglio identificato tentativo di dimostrare questa asserzione).
Mi par di capire che tu sostituiresti nell'asserzione il 'dato esperienziale' con 'l'induzione', intesa come processo induttivo della mente?
Ripeto, non saprei, anche se preferisco la tua asserzione a quella che da per buono il 'dato esperienziale' (qualunque cosa intenda con questo termine) perchè mi sembra troppo svilente nei confronti della mente umana, se è come l'intendo io (dato esperienziale: raccolta di esperienze, cioè una memoria storica).
cdimauro
04-06-2009, 20:01
Se di memoria si tratta, la possono avere anche le macchine. ;)
Per cui al momento questa congettura non mi dice nulla di nuovo e particolare.
banryu79
05-06-2009, 08:18
Se di memoria si tratta, la possono avere anche le macchine. ;)
Per cui al momento questa congettura non mi dice nulla di nuovo e particolare.
Ma infatti :)
Se fosse così la ritengo un'opinione fortemente svilente della mente umana.
A meno che, implicitamente, con 'dato esperienziale' non si volesse intendere solo la memoria in quanto raccolta di dati esperienziali, nuda e cruda, ma si volesse anche includere ciò che la mente umana ci fa con la memoria (più interessante, secondo me). Ma anche in questo caso si tratterebbe solo di considerare un processo in più.
Io credo che la differenza tra una mente umana e una MdT vada ricercata in un'altra direzione.
E che se di una MdT conosciamo tutto, perchè, in ultima analisi è il prodotto di menti umane, dovremmo prima approfondire seriamente la conscenza della mente umana, la nostra stessa mente, tanto per cominciare.
Però qui, vedo quello che sembra un primo problema: un'analogia con il problema della indecidibilità di Godel, e con il problema della fermata di Turing, se vogliamo. E cioè il fatto che un'indagine sulla mente umana condotta da una mente umana, per usare le parole del testo citato in precedenza, ha come sfondo l'autoreferenzialità.
cdimauro
05-06-2009, 08:33
Esatto. Quindi mettiamoci l' "anima" in pace. :p
banryu79
05-06-2009, 08:35
Esatto. Quindi mettiamoci l' "anima" in pace. :p
Obbedisco :O
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.