continuazione da "imparare a programmare"

[fek]

Originariamente inviato da PGI-Bis

Per inciso, le rilevazioni statistiche su cui è fondata la metrica del software non dimostrano un bel nulla. Rilevano e basta. E qui immagino che si aprirà il cielo.

Non si apre il cielo. Vieni semplicemente rimandato a studiare l'amplissima letteratura in merito e invitato ad informarti meglio sull'argomento in questione. La correlazione e' ampiamente dimostrata e universalmente accettata. La tua opinione in merito e' del tutto ininfluente.

[PGI-Bis]

Non è mia quell'opinione. E' di un tale di nome Popper, un povero diavolo che starà facendo i doppi e tripli salti mortali nella tomba.

[fek]

Originariamente inviato da PGI-Bis

Non è mia quell'opinione. E' di un tale di nome Popper, un povero diavolo che starà facendo i doppi e tripli salti mortali nella tomba.

Ora scopriamo che Popper oltre ad essere stato uno dei piu' importanti filosofi della scienza, era anche un ingegnere del software.
Non si finisce mai d'imparare.

[DioBrando]

scusate ma non ho resistito

Originariamente inviato da fek

Ora scopriamo che Popper oltre ad essere stato uno dei piu' importanti filosofi della scienza, era anche un ingegnere del software.
Non si finisce mai d'imparare.

Non sapevate che Popper era pure un Ingegniere del Softuar?







....Sapevatelo!


Su Rieduchescional Ciannel!













...SubbAqqQQui!!!!

[PGI-Bis]

Se uno non sa basta che chieda. Una gentile risposta è sempre pronta ad accoglierlo.

Popper è colui che disse, tra l'altro, che una prova sperimentale può solo confutare una teoria ma mai dimostrarla. Ovviamente non lo disse e basta: lo dimostrò pure. Con l'unico strumento che è in grado di dimostrare qualcosa: la logica. Il nostro evidenziò infatti come la prova sperimentale dovesse essere data per ogni possibile caso ed essendo infinita la varietà fenomenica così pure avrebbe dovuto essere il numero di prove fattuali. E' la nota regressio ad infinitum. Poichè la regressio ad infinitum causa, se ammessa, l'inconoscibilità assoluta qualsiasi affermazione che ad essa conduca deve essere rifiutata.

Ecco perchè una prova fondata su rilievi statistici non dimostra: al massimo confuterebbe una teoria.

Tutto qua. Non sono particolarmente sorpreso dal fatto che alcuni lo scoprano solo ora.

[k0nt3]

posso fare numerosi esempi di codice più lungo che non incrementa la probabilità di sbagliare, ma al contrario la diminuisce.
uno l'ho già fatto un pò di pagine fa e riguarda il fatto che un linguaggio con tipizzazione statica richiede più righe di codice di uno con tipizzazione dinamica (per via delle numerose dichiarazioni), ma questo si traduce in meno possibilità di errori in quanto il compilatore può fare più controlli sui tipi.
un'altro esempio è lo unit testing scrivere un test implica senza ombra di dubbio aggiungere righe di codice in più, ma dubito che un test avrebbe senso se introducesse ulteriori errori.
lo stesso vale per i linguaggi che supportano la programmazione by-contract.
tutto questo è indipendente dai salti condizionati e altre "metriche" che sono state citate. che poi "metrica" è un termine preso in prestito a sproposito dalla matematica solo per far sembrare più importante il concetto.
in realtà non sono metriche ed è facilmente dimostrabile data la definizione di metrica, io le chiamerei euristiche.

[fek]

Originariamente inviato da PGI-Bis

Ecco perchè una prova fondata su rilievi statistici non dimostra: al massimo confuterebbe una teoria.

Mi sembra evidente che non hai neppure fatto lo sforzo di provare a capire il discorso che si sta facendo. Non si sta dimostrando un teorema, si sta dimostrando empiricamente una correlazione statistica fra due quantita'.
Ma non scopriamo ora che sei a digiuno anche dei concetti piu' elementari di Ingegneria del Software.
E a quanto pare anche di Epistemologia della Scienza.

Originariamente inviato da k0nt3

posso fare numerosi esempi di codice più lungo che non incrementa la probabilità di sbagliare, ma al contrario la diminuisce.

Fanne uno. Ma per cortesia non confondere le dichiarazioni con le istruzioni, le prime non producono punti funzionali.
Anche tu stai ignorando il concetto di correlazione statistica fra due quantita'.

lo stesso vale per i linguaggi che supportano la programmazione by-contract.
tutto questo è indipendente dai salti condizionati e altre "metriche" che sono state citate. che poi "metrica" è un termine preso in prestito a sproposito dalla matematica solo per far sembrare più importante il concetto.
in realtà non sono metriche ed è facilmente dimostrabile data la definizione di metrica, io le chiamerei euristiche.

No, metrica in software metrics e' il termine corretto usato per definire un concetto ben preciso in Ingegneria del Software che e' profondamente diverso dal concetto di euristiche. E' un concetto spiegato in qualunque corso di Ingegneria del Software.

Quando si inizia a cambiare il significato dei concetti come state facendo pur di darsi ragione, per me il discorso si conclude.

[k0nt3]

Originariamente inviato da fek

Fanne uno. Ma per cortesia non confondere le dichiarazioni con le istruzioni, le prime non producono punti funzionali.
Anche tu stai ignorando il concetto di correlazione statistica fra due quantita'.

ne ho fatti 3 di esempi e tu me ne hai contenstato 1.
in ogni caso pensavo che stessimo parlando di righe di codice e non di istruzioni, la parola istruzione mi è nuova e devo ammettere che migliora un pochino l'euristica pur rimanendo ancora problematica da trattare

Originariamente inviato da fek

No, metrica in software metrics e' il termine corretto usato per definire un concetto ben preciso in Ingegneria del Software che e' profondamente diverso dal concetto di euristiche. E' un concetto spiegato in qualunque corso di Ingegneria del Software.

Quando si inizia a cambiare il significato dei concetti come state facendo pur di darsi ragione, per me il discorso si conclude.

ciò non toglie che chi ha pensato di chiamarla così l'ha fatto a sproposito perchè non definisce affatto una metrica nel vero senso della parola. è una cosa che succede spesso quando si importano concetti propri di altre discipline in altre discipline.
oltretutto "metrica software" lascia intendere che sia un sottoinsieme delle "metriche" e la cosa è abbastanza fuorviante.

in cosa il concetto di "metrica software" differisce da "euristica" per l'esattezza?
http://wordnet.princeton.edu/perl/webwn?s=heuristic

[PGI-Bis]

Originariamente inviato da fek

Mi sembra evidente che non hai neppure fatto lo sforzo di provare a capire il discorso che si sta facendo. Non si sta dimostrando un teorema, si sta dimostrando empiricamente una correlazione statistica fra due quantita'.
Ma non scopriamo ora che sei a digiuno anche dei concetti piu' elementari di Ingegneria del Software.
E a quanto pare anche di Epistemologia della Scienza.

Se hai delle opinioni le rispetto come quelle di chiunque altro. Se hai delle argomentazioni ne valuterò con pacatezza la sostenibilità come faccio con tutto ciò che leggo.

Se invece vuoi buttarla per l'ennesima volta sul personale vomitando insulti io per l'ennesima volta ti ripeto che non mi impressioni.

E, onde evitare che qualcun'altro lo sia, concedimi di correggerti amichevolmente. Il termine che avresti dovuto usare è Gnoseologia della Scienza perchè Epistemologia significa già ricerca della verità scientifica.

[cdimauro]

Originariamente inviato da PGI-Bis

Messaggio n# 43:

Hai sintetizzato troppo.

Vorrà dire che, nonostante ne avessi parlato già non poche volte in passato, la prossima volta specificherò che il contesto è quello del mondo reale...

Questo non c'entra. Per due ragioni. La prima è che parliamo di lunghezza del codice a prescindere dalle sue istruzioni. E, ribadisco, qui mi sembra lecito affermare, per induzione (cioè non logicamente) che la lunghezza di per sè non sia causa di errori.

Il contesto è quello delle applicazioni reali, costituite da un insieme di istruzioni che includono salti condizionati.

A scanso di equivoci e visti i precedenti, mi vedo costretto a fare un esempio di cosa intendo per "applicazione reale": la JVM.

La seconda è che non puoi portare a dimostrazione del rapporto tra salti condizionati e complessità una deduzione che riguarda sequenze di istruzioni prive di salti condizionati. Perchè essa nulla dice riguardo al codice che abbia dei salti condizionati. In effetti la teoria della computabilità dice anche che una sequenza parzialmente ordinata di istruzioni genera un flusso di esecuzione prevedibile in tutti i casi in cui l'ordine parziale sia deterministico.

Se vogliamo formalizzare, mi riferivo a questo: http://it.wikipedia.org/wiki/Funzion...siva_primitiva

"La classe più ampia delle funzioni ricorsive è definita aggiungendo la possibilità di avere funzioni parziali e introducendo un operatore di ricerca non limitato."

Il che ovviamente NON dimostra che il solo fatto di aggiungere dei salti condizionati porti inevitabilmente alla non prevedibilità di un algoritmo, cosa che non mi sono mai sognato di dire.
Infatti mi sono limitato a parlare dell'introduzione del CONCETTO di salto condizionato e delle relative implicazioni.

Inoltre:

La prevedibilità del comportamento tout court è irrilevante ai fini della gestione "umana" della complessità. Anche lo spostamento di un corpo in un campo di accelerazione ideale è perfettamente prevedibile ma ciò non significa che un essere umano sia in grado di dire dove si troverà il corpo in un certo istante senza ricorrere a calcoli più o meno onerosi.

Indubbiamente, ma il problema dello stop non afferma di certo che non sia possibile costruire programmi che si fermano, nonostante facciano uso di salti condizionati: afferma che non è possibile costruire un programma che sia in grado di determinare che un QUALUNQUE programma datogli in pasto termini o meno.

Comunque qui ci stiamo incartando su questioni teoriche che conosciamo più o meno tutti. Io, come dicevo prima, mi riferivo ad applicazioni reali e non a pezzi di codice creati ad arte per portare la questione sul piano puramente teorico.

Perché se dovessimo tenere in considerazione soltanto questo, potremmo smettere di programmare e andare a fare i magazzinieri.

Ma anche se c'è la mannaia del teorema dello stop a pendere sulle nostre teste, ciò non impedisce a qualcuno di sviluppare ugualmente delle applicazioni e... venderle, addirittura.

Per cui preferisco rimanere coi piedi per terra e limitare le mie considerazioni al mondo reale e a ciò con cui mi confronto tutti i giorni.

In quel caso abbiamo l'assegnamento di un UndefinedObject ad un UndefinedObject.

Come immaginavo. OK, grazie.

Una categoria è un oggetto (teoricamente lo è solo se sia possibile darne una definizione autonoma ma semplifichiamo).

Sì, ne avevi già parlato.

Perché allora si è deciso di introdurre il concetto di classe e non di oggetti in linguaggi come Java et similia?

Questo mi sembra strano perchè firme diverse generano dichiarazioni diverse salvo il caso dei generici in cui è possibile che firme diverse conducano a dichiarazioni identiche per via della mancata reificazione. Ma qui sai bene che io sono il primo dei critici nei confronti dell'introduzione dei generici in Java.

Sì, lo so.

Ti faccio direttamente il caso più rognoso, in modo da arrivare subito al nocciolo del problema senza ambiguità.

Immaginiamo di avere due interfacce che espongano entrambe un metodo getValue, ma che ognuna lo definisca come segue:

int getValue();
String getValue();

Se la mia classe le estende entrambe, cosa succede? A naso, al posto del compilatore, alzerei le mani in segno di resa.

L'API può avere un bug o può essere stata usata male. Tieni presente che la massimizzazione delle finestre, così come l'accesso alla modalità schermo intero, in AWT/Swing è condizionata dall'esistenza di un supporto ad hoc nella piattaforma di esecuzione, supporto rilevabile attraverso metodi forniti dall'API stessa. Vale a dire che AWT/Swing non dichiara "i frame sono massimizzabili" ma "se possibile i frame sono massimizzabili". Ciò significa che un codice in cui si dia per scontato il possesso di tale caratteristica è errato per divergenza dalle capacità dell'API.

Allora il caso che citavo è simile a quello di AWT/Swing: l'API in questione non garantisce il blocco del framebuffer (e quindi l'utilizzo esclusivo) per qualunque implementazione.

La cosa strana è che non ci sono impedimenti di carattere tecnico, ma nonostante ciò su Windows funziona e su Linux (quando ho fatto le mie prove).

Devi o non devi ricorrere ad una regola del linguaggio per stabilire che le parentesi graffe dichiarino un dizionario? Se sì è implicito altrimenti è esplicito. Lo stesso vale per gli altri punti che non cito. Ed è proprio qui che, secondo me, si gioca la partita dell'idoneità all'apprendimento. Quante norme è presupposto che io ricordi affinchè possa comprendere il codice che scrivo?

Tutte quelle che sono definite nel linguaggio.

Spiegami, allora, una cosa. Sia in Python che in Java, io posso scrivere questo (a parte, col primo, la mancanza del punto e virgola per terminare l'istruzione):

Pippo.SetSize(10)
Pippo.SetTitle('Ciao')

In questi casi sto invocando due metodi dell'oggetto Pippo, che accettano un parametro.

Anche in questo sono necessarie delle regole (esattamente due regole) per determinare che nel primo caso ci troviamo di fronte a un numero intero e nel secondo caso a una stringa.

Ma anche se i linguaggi ci obbligassero a specificare il tipo del parametro al momento della chiamata, magari scrivendo una roba come questa:

Pippo.SetSize(int 10)
Pippo.SetTitle(string Ciao)

avremmo bisogno di imparare una regola: quella che ci impone di specificare il tipo prima del dato che viene definito subito dopo.

Se, come dici tu, il terreno del confronto si dovesse spostare sulla mera quantità delle regole del linguaggio, onestamente dubito che Java ne possa uscire vincitore: Python, al contrario delle apparenze, è un linguaggio molto semplice e con poche regole, grazie anche al fatto d'esser dinamico, amorfo e puramente a oggetti (infatti il compilatore è fra i più semplici da realizzare, e Guido ha imposto che la sua grammatica sia sempre di tipo LL e non LR o LALR, come accade con altri linguaggi).

Non sono certo le regole dedicate alla creazione di pochi specifici oggetti a fare la differenza.

[PGI-Bis]

Originariamente inviato da cdimauro

Perché se dovessimo tenere in considerazione soltanto questo, potremmo smettere di programmare e andare a fare i magazzinieri.

Il "codice creato ad arte" l'ho proposto esattamente per riportare la questione della lunghezza sul piano reale. Ognivolta in cui parliamo di lunghezza del codice come indice di complessità dobbiamo ricordarci che parliamo di codice che non è solo "tanto" ma è anche tanto articolato. Se mi dicono che Python è meglio perchè permette di scrivere meno io rispondo dicendo che quest'unico fatto non è rilevante. Nulla più di questo.

Perché allora si è deciso di introdurre il concetto di classe e non di oggetti in linguaggi come Java et similia?

In generale io penso che linguaggi più vecchiotti dispongano delle classi per motivi storici. E' quella faccenda delle teorie degli anni '50 in cui la gerarchia di tipi, quella in stile Linneiano (mammifero -> felino -> gatto), appariva la migliore dal punto di vista della corrispondenza all'interpretazione umana dei fenomeni. Ritengo anche possibile che in Java le classi siano state preferite agli oggetti perchè le classi erano strumenti tradizionalmente noti al momento della creazione di questo linguaggio, così che il passaggio dalle lingue OO di allora (C++ e Smalltalk per dirne due) a Java risultasse meno esotico. Una sorta di meretricio. E' solo un mio sospetto.

Sì, lo so.

Ti faccio direttamente il caso più rognoso, in modo da arrivare subito al nocciolo del problema senza ambiguità.

Immaginiamo di avere due interfacce che espongano entrambe un metodo getValue, ma che ognuna lo definisca come segue:

int getValue();
String getValue();

Se la mia classe le estende entrambe, cosa succede? A naso, al posto del compilatore, alzerei le mani in segno di resa.

E' un caso simile a quello delle eccezioni dichiarate: qui l'ereditarietà multipla di Java non funziona perchè int e String sono reciprocamente invarianti. Funzionerebbe se i due tipi restituiti fossero in rapporto di covarianza e la classe dichiarasse come tipo restituito il covariante (es. Object e String, con la classe che dichiara la restituzione di String). A scanso di equivoci sì, questo è un punto in cui Java non è particolarmente facile da apprendere. Non è l'unico.

Spiegami, allora, una cosa. Sia in Python che in Java, io posso scrivere questo (a parte, col primo, la mancanza del punto e virgola per terminare l'istruzione):

Pippo.SetSize(10)
Pippo.SetTitle('Ciao')

In questi casi sto invocando due metodi dell'oggetto Pippo, che accettano un parametro.

Anche in questo sono necessarie delle regole (esattamente due regole) per determinare che nel primo caso ci troviamo di fronte a un numero intero e nel secondo caso a una stringa.

Ma anche se i linguaggi ci obbligassero a specificare il tipo del parametro al momento della chiamata, magari scrivendo una roba come questa:

Pippo.SetSize(int 10)
Pippo.SetTitle(string Ciao)

avremmo bisogno di imparare una regola: quella che ci impone di specificare il tipo prima del dato che viene definito subito dopo.

Non è malvagia come idea.

Se, come dici tu, il terreno del confronto si dovesse spostare sulla mera quantità delle regole del linguaggio, onestamente dubito che Java ne possa uscire vincitore: Python, al contrario delle apparenze, è un linguaggio molto semplice e con poche regole, grazie anche al fatto d'esser dinamico, amorfo e puramente a oggetti (infatti il compilatore è fra i più semplici da realizzare, e Guido ha imposto che la sua grammatica sia sempre di tipo LL e non LR o LALR, come accade con altri linguaggi).

Non sono certo le regole dedicate alla creazione di pochi specifici oggetti a fare la differenza.

Hai ragione nel senso che il confronto su quante regole abbia una lingua non sarebbe utile a determinare quale delle due sia più agevole da apprendere. Lo dico perchè avrei dovuto ricordarmi della difficolta intrinseca nell'apprendimento di regole che risultino eccezionali rispetto ad altre regole.

[Lyane]

Originariamente inviato da PGI-Bis

Per inciso, le rilevazioni statistiche su cui è fondata la metrica del software non dimostrano un bel nulla. Rilevano e basta. E qui immagino che si aprirà il cielo.

Originariamente inviato da fek

Non si apre il cielo. Vieni semplicemente rimandato a studiare l'amplissima letteratura in merito e invitato ad informarti meglio sull'argomento in questione. La correlazione e' ampiamente dimostrata e universalmente accettata. La tua opinione in merito e' del tutto ininfluente.

Come fatto notare da PGI-Bis una serie di rilevazioni statistiche, non dimostra nullla, ne puo' essere utilizzata per avallare una dimostrazione di una teoria. Se misuro per un milione di volte la temperatura di ebollizione dell'acqua e per un milione di volte ottengo 100°C questo non dimostra affatto la correttezza di una teoria che sostiene che la temperatura di ebolllizione dell'acqua sia 100°C, al massimo puo' confutare una teoria che sostiene che l'acqua non puo' bollire a 100°C.

Magari potessi dimostrare qualcosa, con una serie di rilevazioni statistiche.

[cdimauro]

Originariamente inviato da PGI-Bis

Il "codice creato ad arte" l'ho proposto esattamente per riportare la questione della lunghezza sul piano reale. Ognivolta in cui parliamo di lunghezza del codice come indice di complessità dobbiamo ricordarci che parliamo di codice che non è solo "tanto" ma è anche tanto articolato. Se mi dicono che Python è meglio perchè permette di scrivere meno io rispondo dicendo che quest'unico fatto non è rilevante. Nulla più di questo.

Visto che parliamo di applicazioni reali, per me era implicito (ok, lo so: sono un caso disperato ) che il codice non fosse "banale" / "semplice", ma "complesso". Quello, appunto, presente nelle applicazioni reali.

La LoC non è certamente la migliore delle metriche (sì, metriche: è così che vengono definite in qualunque corso decente di ingegneria del software), ma dà comunque una misura, ovviamente sperimentale. Ce sono altre a mio avviso migliori, ma è comunque un dato utile all'osservazione del fenomeno della "proliferazione" dei bug, che mette in correlazione con la quantità di righe codice ovviamente.

In generale io penso che linguaggi più vecchiotti dispongano delle classi per motivi storici. E' quella faccenda delle teorie degli anni '50 in cui la gerarchia di tipi, quella in stile Linneiano (mammifero -> felino -> gatto), appariva la migliore dal punto di vista della corrispondenza all'interpretazione umana dei fenomeni. Ritengo anche possibile che in Java le classi siano state preferite agli oggetti perchè le classi erano strumenti tradizionalmente noti al momento della creazione di questo linguaggio, così che il passaggio dalle lingue OO di allora (C++ e Smalltalk per dirne due) a Java risultasse meno esotico. Una sorta di meretricio. E' solo un mio sospetto.

Ma LOL. Addirittura meretricio. Ma c'è qualcosa che si salva in Java, dal tuo punto di vista?

E' un caso simile a quello delle eccezioni dichiarate: qui l'ereditarietà multipla di Java non funziona perchè int e String sono reciprocamente invarianti. Funzionerebbe se i due tipi restituiti fossero in rapporto di covarianza e la classe dichiarasse come tipo restituito il covariante (es. Object e String, con la classe che dichiara la restituzione di String). A scanso di equivoci sì, questo è un punto in cui Java non è particolarmente facile da apprendere. Non è l'unico.

Quindi immagino che non sia nemmeno compilabile.

Comunque hai visto che anche l'estensibilità multipla tramite interfacce ha le sue belle rogne e ambiguità? Non è soltanto l'ereditarietà multipla a soffrirne.

Non è malvagia come idea.

ROTFL Mi farai morire con le tue battute!!!

Ma non vorrei essere nei panni di chi dovesse sviluppare con un siffatto linguaggio...

Hai ragione nel senso che il confronto su quante regole abbia una lingua non sarebbe utile a determinare quale delle due sia più agevole da apprendere. Lo dico perchè avrei dovuto ricordarmi della difficolta intrinseca nell'apprendimento di regole che risultino eccezionali rispetto ad altre regole.

Di cui hai parlato già altre volte, lo so, ma anche in questo caso non andremmo molto lontano: Java avrebbe meno eccezioni, ma Python non è costituito da sole eccezioni.

Le eccezioni servono per rendere la vita più semplice allo sviluppatore. Il tutto IMHO, ovviamente.

x Lyane: ma qui nessuno vuol dimostrare niente. Stiamo parlando di misurazioni sperimentali, perché la rigorosa teoria non ci potrà mai dare la risposta definitiva col classico teorema.

A me bastano le prime, perché il software è reale e ci sbatto la testa tutti i giorni: coi bug sono costretto a conviverci.

[Lyane]

Originariamente inviato da cdimauro

x Lyane: ma qui nessuno vuol dimostrare niente.

Forse ti sei distratto o eri poco attento. Fek sta sostenendo: [Cit.] - "Esiste una correlazione statistica dimostrata fra complessita' di una soluzione, numero di righe di codice e defect rate. Espressa in maniera imprecisa, piu' il codice e' complesso maggiore e' la probabilita' di introdurre difetti. Questo e' dimostrato empiricamente, universalmente accettato, ed ogni tentativo di confutarlo ti rimanda allo studio dell'ampia letteratura in merito."

Secondo la teoria di Fek, [Cit.] - "piu' il codice e' complesso maggiore e' la probabilita' di introdurre difetti", e' [Cit] - "universalmente accettato, ed ogni tentativo di confutarlo ti rimanda allo studio dell'ampia letteratura in merito." (anche la locuzione "...universalmente accettato..." poteva risparmiarsela).

In sostanza sta dicendo che una persona qualunque, non avrebbe il diritto di confutare una teoria la cui dimostrazione e' avallata da una serie di dati sperimentali?! Cioe' se PGI-Bis sostiene il contrario commette una sorta di blasfemia?

Invece, secondo me PGI-Bis ha tutto il diritto di confutare cio' che vuole tanto piu' teorie suffragate soltanto da prove sperimentali. (Potrei con gli stessi dati sperimentali, inventarmi la teoria alla Lyane: "Piu' un codice contiene caratteri diversi da "ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789" maggiore e' la probabilita' di introdurre difetti". Tale teoria, basata su rilevazioni statistiche, ha ne piu' ne meno la stessa validita' della teoria esposta da Fek).

Ruguardo il concetto [Cit.] - "dell'ampia letteratura in merito.", non ne comprendo la motivazione. Una teoria sarebbe "vera" solo in base ai Kg di letteratura scritta su di essa? W l'abiogenesi allora.

Stiamo parlando di misurazioni sperimentali, perché la rigorosa teoria non ci potrà mai dare la risposta definitiva col classico teorema.

Ti stai addentrando in un ambito che non ti appartiene, prima di dire qualche "stupidaggine", ti consiglio di fare un passo indietro. Non si puo' sapere tutto di tutto.

[cionci]

Fek, cerchiamo di non arrivare a dire "tu non sai un cazzo"...se vuoi portare avanti una teoria dai le tue motivazioni. Dire che l'altra persona non ci capisce niente, per quanto ti assicuro che per PGI non è così, non può comunque dimostrare le tue affermazioni.

Riguardo alle metriche...sono semplicemente dei parametri di riferimento di massima. Una metrica presa da sola porta molto spesso poche informazioni
Vediamo ad esempio la LOC. In teoria per la LOC un metodo di 1000 righe è migliore dello stesso metodo spezzettato in 100 metodi e 10 classi
Diamo ad ogni metrica il suo giusto significato, inutile usare la LOC per dimostrare che le metriche non servono a niente, in quanto ogni metrica si porta dietro aspetti che riesce a rilevare ed aspetti che non riesce a rilevare

[cdimauro]

Originariamente inviato da Lyane

Forse ti sei distratto o eri poco attento. Fek sta sostenendo: [Cit.] - "Esiste una correlazione statistica dimostrata fra complessita' di una soluzione, numero di righe di codice e defect rate. Espressa in maniera imprecisa, piu' il codice e' complesso maggiore e' la probabilita' di introdurre difetti. Questo e' dimostrato empiricamente, universalmente accettato, ed ogni tentativo di confutarlo ti rimanda allo studio dell'ampia letteratura in merito."

Secondo la teoria di Fek, [Cit.] - "piu' il codice e' complesso maggiore e' la probabilita' di introdurre difetti", e' [Cit] - "universalmente accettato, ed ogni tentativo di confutarlo ti rimanda allo studio dell'ampia letteratura in merito." (anche la locuzione "...universalmente accettato..." poteva risparmiarsela).

In sostanza sta dicendo che una persona qualunque, non avrebbe il diritto di confutare una teoria la cui dimostrazione e' avallata da una serie di dati sperimentali?! Cioe' se PGI-Bis sostiene il contrario commette una sorta di blasfemia?

Invece, secondo me PGI-Bis ha tutto il diritto di confutare cio' che vuole tanto piu' teorie suffragate soltanto da prove sperimentali. (Potrei con gli stessi dati sperimentali, inventarmi la teoria alla Lyane: "Piu' un codice contiene caratteri diversi da "ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789" maggiore e' la probabilita' di introdurre difetti". Tale teoria, basata su rilevazioni statistiche, ha ne piu' ne meno la stessa validita' della teoria esposta da Fek).

Ruguardo il concetto [Cit.] - "dell'ampia letteratura in merito.", non ne comprendo la motivazione. Una teoria sarebbe "vera" solo in base ai Kg di letteratura scritta su di essa? W l'abiogenesi allora.

Non sono affatto distratto, e infatti non mi sembra che tu abbia riportato qualche quote in cui Fran parla di "dimostrazione": si è sempre basato su studi che sono stati fatti su dati sperimentali, che sono, appunto, accettati nell'ambito dell'ingegneria del software.

Faccio notare ancora una volta che stiamo parlando di "applicazioni reali", quelle con cui ci si confronta tutti i giorni, e non alcuni esempi tirati fuori ad arte che, ovviamente, non vogliono dire nulla.

Ti stai addentrando in un ambito che non ti appartiene, prima di dire qualche "stupidaggine", ti consiglio di fare un passo indietro. Non si puo' sapere tutto di tutto.

Non mi pare proprio: http://www.math.unipd.it/~tullio/IS-...e_2003/P19.pdf

Accuratezza delle metriche

- Precisione
  * In termini di esattezza e ripetibilità
  * SLOC e McCabe sì, FP no

- Aderenza alla realtà
  * La misura corrisponde all’evidenza sperimentale
  * Quando le metriche sono usate come indicatori

"Casualmente" si parla di evidenza "sperimentale" e di "aderenza alla realtà": gli stessi termini che uso da un pezzo.

[Lyane]

Originariamente inviato da cdimauro

Non sono affatto distratto, e infatti non mi sembra che tu abbia riportato qualche quote in cui Fran parla di "dimostrazione": si è sempre basato su studi che sono stati fatti su dati sperimentali, che sono, appunto, accettati nell'ambito dell'ingegneria del software.

Se non te ne fossi accorto il punto e': PGI-Bis "HA O NON HA" il diritto di confutare quelli che tu chiami "studi che sono stati fatti su dati sperimentali", senza che fek lo tratti in malo modo. [Cit. da fek]: "Non si apre il cielo. Vieni semplicemente rimandato a studiare l'amplissima letteratura in merito e invitato ad informarti meglio sull'argomento in questione. La correlazione e' ampiamente dimostrata e universalmente accettata. La tua opinione in merito e' del tutto ininfluente.".

Secondo me ha tutto il diritto di confutare cio' che vuole, perche' tali studi non dimostrano nulla, in quanto ottenuti da dati sperimentali (ma poi' che cos'e' dal punto di vista della ricerca scientifica uno "studio fatto su dati sperimentali", se non un'ipotesi).

Non mi pare proprio: http://www.math.unipd.it/~tullio/IS-...e_2003/P19.pdf

Ma mi stai prendendo in giro? Tu hai detto: "Stiamo parlando di misurazioni sperimentali, perché la rigorosa teoria non ci potrà mai dare la risposta definitiva col classico teorema." e io ti ho risposto: "Ti stai addentrando in un ambito che non ti appartiene, prima di dire qualche "stupidaggine", ti consiglio di fare un passo indietro. Non si puo' sapere tutto di tutto."

Chi sta mettendo in dubbio le tue capacita' sulla conoscenza delle metriche? Quello che volevo mettere in dubbio sono le tue conoscenze epistemologiche, ma come al solito si viene sempre fraintesi ad "arte".

[cdimauro]

Quando si arriva in mettere in dubbio la buona fede e l'onestà intellettuale dei propri interlocutori, allora è segno che è molto meglio smettere di discutere...

Tanto i concetti che volevo esprimere li ho ripetuti fino alla nausea, e sul resto credo che Fran non abbia bisogno di nessun "avvocato".

Ciao

[^TiGeRShArK^]

Originariamente inviato da k0nt3

uno di questi fattori è il programmatore infatti ed è anche abbastanza importante

dipende.
Un programmatore migliore abbassa la probabilità d'errore, ma per progetti non banali il suo contributo è cmq minimo dato che la probabilità di errore è inesorabilmente destinata a crescere CHIUNQUE sia il programmatore.

[^TiGeRShArK^]

Originariamente inviato da PGI-Bis

Concordi o no sul fatto che la mera lunghezza, la semplice quantità di istruzioni, a prescindere dalla loro qualità, NON sia causa di errori?

In un progetto REALE di solito non tendi ad aggiungere ridondanza scrivendo 10 milioni di volte la stessa cosa se con una riga di codice puoi ottenere lo stesso risultato scrivendo un ciclo.
Se poi tu ti "unrolli" tutti i loop a mano... bhè..
sei masochista
Per me, per quanto molto approssimata, il concetto di LoC, eliminando tutte le ridondanze che NON aggiungono contenuto informativo al codice, resta comunque una approssimazione di massima piuttosto corretta.