continuazione da "imparare a programmare"

[variabilepippo]

la definizione del problema era ambigua perchè non è stato specificato il dominio di riferimento, quindi anche trovare solo le soluzioni reali (quando ci sono) era corretto.
non ho bisogno di cercare su wikipedia, sono cose che so già
lui ha aggiunto anche le soluzioni complesse solo per scrivere meno righe di codice.. nient'altro

Ti sei posto in un caso particolare, la scelta di determinare esclusivamente le soluzioni nel campo dei reali è una (auto)limitazione arbitraria, se vengono chieste le soluzioni di un'equazione polinomiale è bene trovarle tutte (visto che esistono sempre, come ci ricorda il teorema fondamentale dell'algebra!).

[k0nt3]

Originariamente inviato da variabilepippo

Ti sei posto in un caso particolare, la scelta di determinare esclusivamente le soluzioni nel campo dei reali è una (auto)limitazione arbitraria, se vengono chieste le soluzioni di un'equazione polinomiale è bene trovarle tutte (visto che esistono sempre, come ci ricorda il teorema fondamentale dell'algebra!).

devo dissentire.. le soluzioni di un'equazione polinomiale di grado n non sono sempre n, ma lo sono solamente se il polinomio è definito come una funzione che va da C a C. altrimenti può anche non avere soluzioni
il teorema fondamentale dell'algebra non vale sempre, ma solo quando si verificano queste condizioni.

Originariamente inviato da fek

La definizione non era ambigua perche' in mancanza di menzione esplicita del codomonio ci si riferisce all'"oggetto matematico" che ha sempre due soluzioni complesse.

non so cosa intendi per oggetto matematico
comunque ti anticipo che se in matematica definisci una funzione senza specificarne il dominio e il codominio in realtà non definisci una funzione.

Originariamente inviato da fek

In caso di definizione ambigua del cliente, comunque, il buon programmatore implementa sempre la soluzione piu' semplice al problema, non la piu' complessa.

per me è più semplice usare i numeri reali.. per cdimauro usare i numeri complessi.. ognuno ha il suo concetto di complessità (e il mio va ben oltre il numero di righe di codice)

[variabilepippo]

devo dissentire.. le soluzioni di un'equazione polinomiale di grado n non sono sempre n, ma lo sono solamente se il polinomio è definito come una funzione che va da C a C. altrimenti può anche non avere soluzioni
il teorema fondamentale dell'algebra non vale sempre, ma solo quando si verificano queste condizioni.

Grazie per la precisazione, ne avevo proprio bisogno...

Come avresti risolto il seguente esercizio di un ipotetico scritto di Analisi I: "Si determinino le soluzioni dell'equazione di secondo grado 3x^2+x+1=0"?

[k0nt3]

Originariamente inviato da variabilepippo

Grazie per la precisazione, ne avevo proprio bisogno...

Come avresti risolto il seguente esercizio di un ipotetico scritto di Analisi I: "Si determinino le soluzioni dell'equazione di secondo grado 3x^2+x+1=0"?

l'unica cosa che potresti fare è dire: "in R non ha soluzioni, mentre in C ne ha due che sono ecc.."
e questo è ben diverso da dire: "ha due soluzioni che sono ecc.."

ps. sinceramente non mi è mai capitato di vedere matematici troppo sbadati da questo punto di vista

[variabilepippo]

l'unica cosa che potresti fare è dire: "in R non ha soluzioni, mentre in C ne ha due che sono ecc.."
e questo è ben diverso da dire: "ha due soluzioni che sono ecc.."

Non vedo perché dovresti limitarti a risolvere l'equazione nei soli campi R e C, perché non hai considerato le (infinite) altre strutture algebriche nelle quali potresti risolvere l'equazione?

Se l'obiettivo è "determinare per via algoritmica le soluzioni di un'equazione di secondo grado" (senza ulteriori indicazioni) e per raggiungerlo si scrive un codice che permetta di ricavare SOLO le eventuali soluzioni reali allora l'obiettivo non è stato raggiunto, mi pare lapalissiano.

[k0nt3]

Originariamente inviato da variabilepippo

Non vedo perché dovresti limitarti a risolvere l'equazione nei soli campi R e C, perché non hai considerato le (infinite) altre strutture algebriche nelle quali potresti risolvere l'equazione?

quindi detto così potrebbe avere 2, 20, infinite o nessuna soluzione.
ma soprattutto perchè limitare i coefficienti a numeri reali? non sarebbe stato più coerente permettere numeri complessi in input?
forse sì, ma visto che la richiesta non specificava nessuna di queste cose va sempre bene

Originariamente inviato da variabilepippo

Se l'obiettivo è "determinare per via algoritmica le soluzioni di un'equazione di secondo grado" (senza ulteriori indicazioni) e per raggiungerlo si scrive un codice che permetta di ricavare SOLO le eventuali soluzioni reali allora l'obiettivo non è stato raggiunto, mi pare lapalissiano.

senza aggiungere niente la richiesta di per se è senza senso. di solito ci si basa su convenzioni comunemente accettate e la convenzione è quella di usare i numeri reali perchè sono quelli che hanno applicazioni nella maggiorparte dei problemi (geometrici, fisici, economici, demografici ecc..).

[fek]

Originariamente inviato da k0nt3

non so cosa intendi per oggetto matematico

Non faccio fatica a crederti.

per me è più semplice usare i numeri reali.. per cdimauro usare i numeri complessi.. ognuno ha il suo concetto di complessità (e il mio va ben oltre il numero di righe di codice)

Non parlo di semplicita' in termini personali, ma di semplicita' dell'implementazione, e la soluzione di Cesare e' piu' semplice in base a quasi qualunque metrica che puoi scegliere (LoC, punti funzionali, CC). Quindi la sua e' preferibile alla tua e risolve pienamente il problema posto.

[PGI-Bis]

Originariamente inviato da cdimauro

Dove la definizione di "complicato" però latita.

Latita volutamente. Non sono io ad essere appassionato del termine "semplice". Ho anche chiesto cosa si intendesse per semplice (e, quindi, per complicato) ma non ho avuto risposta e dubito che ne avrò.

I bug originano dall'introduzione del concetto di salto condizionato, del tutto assente nell'esempio che hai esposto.

Non rivoltiamo la frittata in faccia all'avventore: qui è il cuoco che si deve scottare. E' stato detto che la lunghezza del codice è causa di errori. E' banalmente falso. E a meno che non si abbia la dimostrazione logica che i salti condizionati producano errori, e anticipo che non c'è tale dimostrazione, neppure possiamo dire "originano dall'introduzione del concetto di salto condizionato". Possiamo semmai supporre che originino.

OK. Cosa ne pensi del mio punto di vista?

A naso non mi torna l'uso del termine informazione che è piuttosto importante nel contesto in cui ci troviamo. Dico a naso perchè dovrei approfondire il tuo discorso per darti una risposta ma al momento non ne ho le energie.

L'istruzione di assegnazione come si configura? Anch'essa come "messaggio spedito"?

Sì, "<-" (operatore di assegnamento) in Smalltalk è un messaggio. Scrivere semplicemente "pippo" senza null'altro è già far riferimento ad un oggetto (UndefinedObject) da cui la possibilità che "<-" su un letterale nuovo di zecca sia "invocazione di metodo".

Mumble. Io lo vedo come una classe che definisce un metodo di classe: faccio male o c'è qualcosa che mi sfugge?

Una classe è la definizione di una categoria di oggetti. E' sottinteso ma classe sta per "classe di oggetti" dove classe significa esattamente categoria. Non sempre esiste la necessità di definire intere categorie di oggetti. Anzi, io ritengo che sia più diffusa la necessità di definire singoli oggetti. D'altronde è programmazione orientata "agli oggetti" non "alle categorie di oggetti". E' vero che in Java esiste un equivalente della dichiarazione scala "object" nella dichiarazione di una classe con metodi statici ma è pur sempre dichiarazione di una classe. Con ciò non voglio dire che dovrebbero introdurre in Java la possibilità di dichiarare un oggetto tout court: per l'amor del cielo. Prima bisognerebbe eliminare le classi altrimenti tra classi, interfacce e oggetti finiamo tutti quanti al manicomio.

Quanto all'approccio delle interfacce, cosa succede se ne esistono due che dichiarano due metodi getValue e una classe prova ad estenderle entrambe? Non c'è anche qui la necessità di capire a quale ci si riferisce se nel codice è presente soltanto l'invocazione di getValue?

No, non c'è conflitto (a meno che uno dei due metodi non dichiari il rilascio di un'eccezione che l'altro non prevede, in questo caso sono guai). Non c'è conflitto perchè i metodi sono equivalenti: l'oggetto è obbligato ad avere il metodo getValue, che l'obbligo scaturisca da una o dieci interfacce diverse è ininfluente. Non c'è una scelta tra diverse implementazioni ma un unico contratto da abbracciare o non abbracciare.

Facciamo che mi riferivo alle librerie anziché alla VM: va bene lo stesso riguardo alla discorso sulla portabilità di Java?

No. Puoi considerare solo le librerie dichiarate nelle specifiche del linguaggio. Se usassimo le estensioni per decidere della portabilità di Java allora essa sarebbe negata ogniqualvolta chiunque decidesse di creare un'estensione fornendone l'implementazione solo per uno o alcuni sistemi operativi.

Tornando a ciò che dicevi, dove starebbe il trasferimento di parte delle informazioni dal discorso esplicito a uno implicito? Insomma, dove trovi che, nella definizione in Python che ho fornito, siano celate implicitamente delle informazioni?

Non ho fatto riferimento alla definizione in Python che hai fornito. Sinceramente non ho neanche presente di quale definizione si parli. Tu hai detto che Python è sintetico. Se è sintetico necessariamente deve dare per scontate alcune cose. Non è detto che questo sia un male. Dipende da cosa da per scontato. Ad esempio nell'uso della funzione "print" Python da per scontato una parte delle sue regole (quelle che fanno di "print" istanza di una classe).

La sintesi serve principalmente a rimuovere delle informazioni ridondanti o inutili.

Un'informazione inutile è inutile anche nella versione non sintetica e, perciò, non dovrebbe essere presente. Lo stesso vale per le informazioni puramente rindondanti. Ricordo che alcune forme apparentemente rindondanti come i pronomi appartengono ad una categoria, quella delle anafore, che svolgono un'importante funzione nella comprensione del significato di una frase. Eliminare i pronomi, cosa piuttosto comune negli appunti, esercizio di sintesi per antonomasia, significa eliminare informazioni nel presupposto che esse siano siano successivamente ricostruibili dal lettore.

[cdimauro]

Originariamente inviato da PGI-Bis

Latita volutamente. Non sono io ad essere appassionato del termine "semplice". Ho anche chiesto cosa si intendesse per semplice (e, quindi, per complicato) ma non ho avuto risposta e dubito che ne avrò.

Questo lo sapevi fin dall'inizio, ma ciò non t'ha impedito di utilizzare il concetto di "complesso".

Non rivoltiamo la frittata in faccia all'avventore: qui è il cuoco che si deve scottare. E' stato detto che la lunghezza del codice è causa di errori. E' banalmente falso.

Ho sempre parlato di misure sperimentali (quindi su progetti concreti / non banali), mi pare: non di casi teorici studiati a tavolino.

E a meno che non si abbia la dimostrazione logica che i salti condizionati producano errori, e anticipo che non c'è tale dimostrazione,

Mi sembra di aver detto che i bug nascano dall'introduzione del CONCETTO di salto incondizionato: non mi sono mai sognato di affermare che i salti condizionati di per sé producano errori.

neppure possiamo dire "originano dall'introduzione del concetto di salto condizionato". Possiamo semmai supporre che originino.

Nessuna supposizione: nella teoria della computabilità è dimostrato che finché un algoritmo è composto da una sequenza definita (e finita) di istruzioni (SENZA salti condizionali), il suo comportamento è perfettamente prevedibile.

E' l'introduzione dei salti condizionali che PUO' PORTARE a comportamenti non prevedibili. Da cui segue il famoso problema dello stop.

Questo per essere precisi, semmai ci dovesse essere stata una qualche ambiguità.

A naso non mi torna l'uso del termine informazione che è piuttosto importante nel contesto in cui ci troviamo. Dico a naso perchè dovrei approfondire il tuo discorso per darti una risposta ma al momento non ne ho le energie.

Non c'è problema: ne riparleremo se e quando ne avrai voglia e tempo.

Sì, "<-" (operatore di assegnamento) in Smalltalk è un messaggio. Scrivere semplicemente "pippo" senza null'altro è già far riferimento ad un oggetto (UndefinedObject) da cui la possibilità che "<-" su un letterale nuovo di zecca sia "invocazione di metodo".

Capito. Quindi a tutti gli effetti non ha il concetto di istruzione.

Però un comportamento del genere può dar luogo a riferimenti a oggetti inesistenti. Esempio:

Pippo := Pluto

non genera alcun messaggio d'errore anche se Pluto non è mai stata definita come variabile, visto che viene creata "al volo".

Una classe è la definizione di una categoria di oggetti. E' sottinteso ma classe sta per "classe di oggetti" dove classe significa esattamente categoria. Non sempre esiste la necessità di definire intere categorie di oggetti. Anzi, io ritengo che sia più diffusa la necessità di definire singoli oggetti. D'altronde è programmazione orientata "agli oggetti" non "alle categorie di oggetti". E' vero che in Java esiste un equivalente della dichiarazione scala "object" nella dichiarazione di una classe con metodi statici ma è pur sempre dichiarazione di una classe. Con ciò non voglio dire che dovrebbero introdurre in Java la possibilità di dichiarare un oggetto tout court: per l'amor del cielo. Prima bisognerebbe eliminare le classi altrimenti tra classi, interfacce e oggetti finiamo tutti quanti al manicomio.

Chiaro. Però se poi ti dovessero servire anche le classi quali "categorie di oggetti", che faresti?

No, non c'è conflitto (a meno che uno dei due metodi non dichiari il rilascio di un'eccezione che l'altro non prevede, in questo caso sono guai). Non c'è conflitto perchè i metodi sono equivalenti: l'oggetto è obbligato ad avere il metodo getValue, che l'obbligo scaturisca da una o dieci interfacce diverse è ininfluente. Non c'è una scelta tra diverse implementazioni ma un unico contratto da abbracciare o non abbracciare.

Sì, ma quest'approccio genera dei problemi e quello delle eccezioni che hai riportato è uno.

Poi c'è anche quello di cui ho parlato con "Tiger", e riguarda l'eventuale presenza dello stesso metodo getValue definito in diverse interfacce, ma con di signature diverse.

Anche questo modello, quindi, non mi sembra del tutto esente da "matasse da sbrogliare".

No. Puoi considerare solo le librerie dichiarate nelle specifiche del linguaggio. Se usassimo le estensioni per decidere della portabilità di Java allora essa sarebbe negata ogniqualvolta chiunque decidesse di creare un'estensione fornendone l'implementazione solo per uno o alcuni sistemi operativi.

Ma l'API di cui parlavo è disponibile in diverse implementazioni (probabilmente in tutte, ma non ho mai verificato): è che con alcune non funziona.

Sulle estensioni specifiche per una particolare estensione nulla da dire (ci sono anche in Python).

Non ho fatto riferimento alla definizione in Python che hai fornito. Sinceramente non ho neanche presente di quale definizione si parli. Tu hai detto che Python è sintetico. Se è sintetico necessariamente deve dare per scontate alcune cose. Non è detto che questo sia un male. Dipende da cosa da per scontato. Ad esempio nell'uso della funzione "print" Python da per scontato una parte delle sue regole (quelle che fanno di "print" istanza di una classe).

print lascialo perdere, che rappresenta un'eccezione (è un'istruzione, al momento, e non è l'unico linguaggio ad averne: anche in Java ce ne sono).

Nell'esempio che ho fornito ho definito un dizionario/mappa/hash e l'ho assegnato a una variabile.
Che sia più sintetico è evidente, ma non dà per scontato niente:
- che sia un dizionario è esplicitato dalle parentesi graffe;
- che 'Qui', 'Quo' e 'Qua' siano delle stringhe è esplicitato dagli apici;
- che 1, 2, 3 siano dei numeri interi è esplicitato dal fatto che siano costituiti da sole cifre numeriche e dall'assenza del punto;
- che a 'Qui' corrisponda 1, 'Quo' a 2, 'Qua' a 3 è esplicitato dalla presenza dei due punti, che all'interno di un dizionario assumono il significato di separare la definizione della chiave dal valore;
- che 'Qui' : 1 sia una entry del dizionario, 'Quo' : 2 un'altra e 'Qua' : 3 un'altra ancora è esplicitato dalla presenza della virgola, che all'interno di un dizionario ne separa i valori;
- che alla variabile a venga assegnato il suddetto dizionario è esplicitato dalla presenza del carattere di uguale.

Ripeto: io non vedo niente di "scontato".

Un'informazione inutile è inutile anche nella versione non sintetica e, perciò, non dovrebbe essere presente. Lo stesso vale per le informazioni puramente rindondanti. Ricordo che alcune forme apparentemente rindondanti come i pronomi appartengono ad una categoria, quella delle anafore, che svolgono un'importante funzione nella comprensione del significato di una frase. Eliminare i pronomi, cosa piuttosto comune negli appunti, esercizio di sintesi per antonomasia, significa eliminare informazioni nel presupposto che esse siano siano successivamente ricostruibili dal lettore.

Non credo che sia il caso di Python: vedi l'esempio di cui sopra. Tutte le informazioni NECESSARIE sono presenti ed esplicitate. Potremmo definirlo come "codice ridotto all'osso", al più.

[PGI-Bis]

Originariamente inviato da cdimauro

Questo lo sapevi fin dall'inizio, ma ciò non t'ha impedito di utilizzare il concetto di "complesso".

Ho sempre parlato di misure sperimentali (quindi su progetti concreti / non banali), mi pare: non di casi teorici studiati a tavolino.

Messaggio n# 43:

Originariamente inviato da cdimauro

Se hai più linee di codice mi sembra a dir poco ovvio che hai più possibilità di avere dei bug.

Hai sintetizzato troppo.

Nessuna supposizione: nella teoria della computabilità è dimostrato che finché un algoritmo è composto da una sequenza definita (e finita) di istruzioni (SENZA salti condizionali), il suo comportamento è perfettamente prevedibile.

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. 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. Inoltre:

E' l'introduzione dei salti condizionali che PUO' PORTARE a comportamenti non prevedibili. Da cui segue il famoso problema dello stop.

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.

Capito. Quindi a tutti gli effetti non ha il concetto di istruzione.

Però un comportamento del genere può dar luogo a riferimenti a oggetti inesistenti. Esempio:

Pippo := Pluto

non genera alcun messaggio d'errore anche se Pluto non è mai stata definita come variabile, visto che viene creata "al volo".

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

Chiaro. Però se poi ti dovessero servire anche le classi quali "categorie di oggetti", che faresti?

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

Sì, ma quest'approccio genera dei problemi e quello delle eccezioni che hai riportato è uno.

Poi c'è anche quello di cui ho parlato con "Tiger", e riguarda l'eventuale presenza dello stesso metodo getValue definito in diverse interfacce, ma con di signature diverse.

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.

Ma l'API di cui parlavo è disponibile in diverse implementazioni (probabilmente in tutte, ma non ho mai verificato): è che con alcune non funziona.

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.

Che sia più sintetico è evidente, ma non dà per scontato niente:
- che sia un dizionario è esplicitato dalle parentesi graffe;

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?

[^TiGeRShArK^]

Originariamente inviato da PGI-Bis

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.

Perchè no?
Se in una riga di codice hai una probabilità media x di fare 1 errore, in n righe di codice tale probabilità salirà ad n*x.
Quindi con l'aumentare delle righe di codice (1) la probabilità media di introdurre un bug è inevitabilmente destinata a crescere.
Ovviamente in teoria potrebbe essere sempre possibile scrivere un programma privo di bug.
Ma in teoria anche ripartendo dai cocci di porcellana potrebbe essere sempre possibile riottenere la tazza intera... solo che nella realtà non l'ho mai visto accadere

(1) Ovviamente per righe di codice non vanno considerate quelle contenenti caratteri di controllo (quali le parentesi graffe) e/o linee UGUALI di codice perchè in quel caso stai semplicemente aggiungendo delle ridondanze che sono assolutamente inutili ai fini del programma e possono essere eliminate in diversi modi mantenendo il contenuto informativo del codice.
Inoltre, tanto per essere + pignoli, così ad occhio direi che la probabilità di commettere errori è anche condizionata dal particolare costrutto utilizzato, ma questa è solo un'impressione dato che ora come ora non mi viene in mente una dimostrazione

[PGI-Bis]

Originariamente inviato da ^TiGeRShArK^

Inoltre, tanto per essere + pignoli, così ad occhio direi che la probabilità di commettere errori è anche condizionata dal particolare costrutto utilizzato, ma questa è solo un'impressione dato che ora come ora non mi viene in mente una dimostrazione

E' questo il punto. Cioè non è la lunghezza di cui dobbiamo tener conto. Perchè, ripeto, se provassimo a scrivere per diecimila linee:

print(10);

Io dubito fortemente che avremmo anche un solo errore. Sarebbe un caso di codice lunghissimo ma senza errori che confuterebbe l'idea che la semplice quantità sia un ostacolo alla correttezza. Non mi sembra così strano come ragionamento (pur non essendo logicamente esatto).

[^TiGeRShArK^]

Originariamente inviato da PGI-Bis

E' questo il punto. Cioè non è la lunghezza di cui dobbiamo tener conto. Perchè, ripeto, se provassimo a scrivere per diecimila linee:

print(10);

Io dubito fortemente che avremmo anche un solo errore. Sarebbe un caso di codice lunghissimo ma senza errori che confuterebbe l'idea che la semplice quantità sia un ostacolo alla correttezza. Non mi sembra così strano come ragionamento (pur non essendo logicamente esatto).

è sbagliato perchè stai introducendo dele ridondanze senza aggiungere alcun contenuto informativo nel codice come avevo specificato precedentemente nella nota
In pratica hai fatto un semplice unrolling del loop:

10000.times{puts 10}

Le tue 10000 righe di codice come vedi equivalgono a una sola.
E inoltre puoi anche sbagliare a contare e quindi magari ne avrai 9999 o 10001 e quindi avrai introdotto dei bug.
Inoltre avevo anche parlato di probabilità media di errori per riga di codice poichè vi possono essere righe di codice indubbiamente + soggette ad errori a causa della loro scarsa leggibilità e a causa di altri fattori.

[k0nt3]

Originariamente inviato da ^TiGeRShArK^

Inoltre avevo anche parlato di probabilità media di errori per riga di codice poichè vi possono essere righe di codice indubbiamente + soggette ad errori a causa della loro scarsa leggibilità e a causa di altri fattori.

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

[PGI-Bis]

Originariamente inviato da ^TiGeRShArK^

è sbagliato perchè stai introducendo dele ridondanze senza aggiungere alcun contenuto informativo nel codice come avevo specificato precedentemente nella nota
In pratica hai fatto un semplice unrolling del loop:

10000.times{puts 10}

Le tue 10000 righe di codice come vedi equivalgono a una sola.
E inoltre puoi anche sbagliare a contare e quindi magari ne avrai 9999 o 10001 e quindi avrai introdotto dei bug.
Inoltre avevo anche parlato di probabilità media di errori per riga di codice poichè vi possono essere righe di codice indubbiamente + soggette ad errori a causa della loro scarsa leggibilità e a causa di altri fattori.

Ma cosa c'entra il ciclo? Codice lungo uguale più bug. Questo è o non è codice:

print(10);
print(10);
print(10);
print(10);
print(10);
print(10);
print(10);
print(10);
print(10);
print(10);
print(10);
print(10);
print(10);
print(10);
print(10);
print(10);
print(10);
print(10);
print(10);
print(10);
print(10);
print(10);
print(10);
print(10);
print(10);
print(10);
print(10);
print(10);
print(10);
print(10);
print(10);
print(10);
print(10);
print(10);
...e via così per altre chissenefrega quante linee.

E' codice o no? E' lungo o no? Se dico che posso scrivere venti milioni di righe così senza commettere un solo errore ti sembra strano? Se da questo induco che la lunghezza non è di per sè causa di errori dico qualcosa di alieno? Probabilmente sì perchè qui si discute di apprendimento è poi non si sa la differenza tra induzione e deduzione, tra argomentazione e giustificazione... insomma, è logica elementare. E San Giuseppe aiutaci!

[fek]

Originariamente inviato da PGI-Bis

E' codice o no? E' lungo o no? Se dico che posso scrivere venti milioni di righe così senza commettere un solo errore ti sembra strano? Se da questo induco che la lunghezza non è di per sè causa di errori dico qualcosa di alieno? Probabilmente sì perchè qui si discute di apprendimento è poi non si sa la differenza tra induzione e deduzione, tra argomentazione e giustificazione... insomma, è logica elementare. E San Giuseppe aiutaci!

Stai facendo un discorso capzioso e volutamente offuscando il concetto di lunghezza del codice.
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.

Ora, la complessita' del codice puo' essere espressa attraverso svariate metriche come ben sappiamo: LoC e' una delle metriche e forse la meno precisa. Ma e' una metrica. Nel tuo esempio LoC non descrive correttamente la complessita' di quel codice, dove CC e' piu' preciso: quel codice ha complessita ciclometica 2 (Uno per il loop e uno per il corpo del metodo), quindi e' intuitivamente poco piu' complesso del semplice print. La probabilita' di errore e' leggermente maggiore perche' c'e' la possibilita' di sbagliare il conto. Anche considerando i punti funzionali come metrica, il tuo esempio risulta poco piu' complesso di un semplice print nonostante il numero di righe di codice.

In generale usare LoC come metrica durante la scrittura del codice da' una minima idea della complessita' e ridurre il numero di righe di codice della propria soluzione a parita' di chiarezza e di concetti espressi e' una buona pratica che alla lunga porta a codice con meno difetti.

[PGI-Bis]

Originariamente inviato da fek

Stai facendo un discorso capzioso e volutamente offuscando il concetto di lunghezza del codice.

E' stato detto che la lunghezza del codice, LA SOLA LUNGHEZZA, L-U-N-G-H-E-Z-Z-A, sola, lungo, no altro, è causa di bug. Io ho detto che non concordo per un motivo che mi pare condivisibile a meno di non vivere sul pianeta signornò, e io farei discorsi capzioni, travisando volutamente concetti mai citati, immagino tra una fucilata a Kennedy ed un caffè servito a Papa Luciani.

Tu parli di complessità del codice ma non è di complessità che stavo discutendo io. Io parlo di lunghezza in sè e per sè.

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

[fek]

Originariamente inviato da PGI-Bis

Tu parli di complessità del codice ma non è di complessità che stavo discutendo io. Io parlo di lunghezza in sè e per sè.

Io parlo dell'unico concetto definito di complessita' del quale ha senso parlare in questo contesto.

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

Non concordo. Esiste una correlazione dimostrata fra lunghezza del codice e probabilita' di errore. Probabilita'. Non certezza di errore.
Meno righe di codice tendono a generare meno errori, ma e' statisticamente possibile, per quanto improbabile, scrivere milioni righe di codice senza errori.
Ma come ti e' stato dimostrato LoC non e' la metrica piu' affidabile della complessita' del codice, infatti ripetere 1000 volte la stessa riga di codice non ne aumenta di 1000 volte la complessita'.
LoC e' una buona metrica per dare indicazioni di massima mentre si scrive codice.

[marco.r]

Originariamente inviato da PGI-Bis

E' codice o no? E' lungo o no? Se dico che posso scrivere venti milioni di righe così senza commettere un solo errore ti sembra strano? Se da questo induco che la lunghezza non è di per sè causa di errori dico qualcosa di alieno?

Devi considerare l'arco di vita del codice. Quando devi cambiare il numero di linee, capire quante sono o sapere il perche' ce n' e' una certa cifra l' errore e' dietro l'angolo.
Ovviamente se invece parli di codice generato e' un altro paio di maniche, in quel caso al suo posto va secondo me considerato il codice generatore.

[PGI-Bis]

Originariamente inviato da fek

Non concordo.

Guarda, ci avrei scommesso. Lo sapevo ancora prima di cliccare il link nel messaggio di notifica via e-mail.

Che poi è normale: se io parlo della buccia delle mele e tu mi viene a dire che non è liscia perchè le arance sono rugose siamo a posto. Che giorno è? Le 14 e mezza.

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 marco.r

...omissis...

Se dovessi considerare cose che non c'entrano con le premesse del discorso è chiaro che la faccenda cambierebbe. Se anzichè essere la mera ripetizione di una singola istruzione il codice facesse uso di una quantità e varietà di istruzioni tali da non poter più essere interamente conservate nella memoria a breve termine o nella memoria automatica (del programmatore, giusto per precisare di chi parliamo) o anche nel caso in cui il codice fosse banale quanto quello proposto ma il soggetto dovesse produrlo in condizioni di attenzione alterata, allora la "lunghezza" potrebbe essere significativa. Ma in questi e altri casi la lunghezza non sarebbe che la manifestazione di una condizione non ottimale di produzione del codice. Vale a dire il problema non è la lunghezza ma la lunghezza è il sintomo di un problema. Questioni di cui si potrebbe anche discutere se parlassimo di complessità e a patto di dare una definizione di complessità (al singolare, la complessità, cosa diversa dalle complessità affrontate dallE metrichE del software).