[generale] la programmazione è un'attività scientifica o morale?

[mad_hhatter]

apro questo thread in seguito a una proposta avanzata in un'altra discussione.

la questione è questa:

Originariamente inviato da PGI-Bis

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 .

Originariamente inviato da cdimauro

Immaginavo che fosse quello il pomo della discordia, ma volevo esserne sicuro.

Però, se ricordi, nessuno ha mai parlato di teorie, quanto di "best practices" dettate dall'esperienza e da prove empiriche.

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]

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^]

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.. )

[misterx]

la programmazione è un lavoro
Quella ad oggetti, raccontandola come la dice il mio docente: è un metodo inventato per riusare vecchio codice e non reinventare l'acqua calda

[Energy++]

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

[mad_hhatter]

Originariamente inviato da misterx

la programmazione è un lavoro
Quella ad oggetti, raccontandola come la dice il mio docente: è un metodo inventato per riusare vecchio codice e non reinventare l'acqua calda

ecco come sminuire la programmazione ad oggetti e non trasmettere assolutamente nulla agli studenti.

[mad_hhatter]

Originariamente inviato da Energy++

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

le librerie non nascono con l'OOP. L'importanza del paradigma OO è ben al di là del mero riutilizzo del codice

[misterx]

Originariamente inviato da mad_hhatter

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]

Originariamente inviato da Energy++

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

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]

Originariamente inviato da misterx

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.

[misterx]

Originariamente inviato da mad_hhatter

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...&ct=clnk&gl=it

[cdimauro]

Non è così: http://it.wikipedia.org/wiki/Program...a_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 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.

E sono assolutamente certo che nessuno possa dimostrare il contrario.

In poche parole: avremmo tranquillamente potuto farne a meno e continuare col classico paradigma.

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.

[banryu79]

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.

[arcer]

Originariamente inviato da cdimauro

Non è così: http://it.wikipedia.org/wiki/Program...a_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 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.

E sono assolutamente certo che nessuno possa dimostrare il contrario.

In poche parole: avremmo tranquillamente potuto farne a meno e continuare col classico paradigma.

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.

*

ovviamente però è un gran rivoluzione, permettere di aggregare strutture di codice assieme semplifica e anche di molto come "ragionare" per risolvere un problema....

[banryu79]

Originariamente inviato da arcer

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]

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^]

Originariamente inviato da banryu79

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.

[PGI-Bis]

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]

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.

[Hactor]

Originariamente inviato da ^TiGeRShArK^

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.. )

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.