[PGI-Bis]

Originariamente inviato da cdimauro

Va bene.

Il concetto che è stato espresso è sempre lo stesso: si tratta della definizione di una mappa/dizionario.

La "comunicazione" di quel che si sta facendo, invece, avviene in forme diverse.

Qui avrei voluto rispondere ma... mi sono dimenticato cosa io dovessi dire Mi sono anche dimenticato perchè ho risposto come ho risposto la prima volta. . Bella la giovinezza, eh?

Il numero di bug per righe di codice è una metrica molto usata nella valutazione del defect ratio di un'applicazione.

Portare un esempio in cui tale misura è pari a zero nulla toglie alla realtà speriementale, con applicazioni reali, che dipingono un quadro ben diverso (che ho riportato io).

Portare quell'esempio, invece, è sufficiente a falsificare la teoria secondo cui la mera lunghezza del codice causerebbe un aumento del defect rate. E, in effetti, noi dovremmo tener conto che le analisi statistiche sui bug dei programmi si misurano non semplicemente con codice "molto lungo" ma con codice "lungo e complicato".

Ti faccio anche presente che applicando lo stesso principio che hai esposto...

Non ho inteso esporre questo principio. Ho affermato che la lunghezza è di per sè irrilevante. Ciò che causa la scrittura di codice buggato deve essere cercato da qualche altra parte. Non so dove ma, se è induttivamente vero l'esempio che ho proposto, sicuramente non nella semplice quantità di codice.

Per me un concetto è la rappresentazione di qualcosa che ha determinate proprietà. Linguaggi diversi (ma anche programmi diversi) permettono di rappresentarlo utilizzando una diversa quantità di informazione.

Sempre per quanto mi riguarda, rappresentare qualcosa con meno informazioni aiuta nella comprensione del quadro generale in cui sono collocati questi concetti: faccio meno fatica a tenere traccia di ciò che sto facendo. Il tutto senza rinunciare alla chiarezza e alla leggibilità (in soldoni: roba come whitespace o brainfuck sono da scartare).

Più aumenta la lunghezza del codice, più la rappresentazione e la comprensione di un concetto tendono a disperdersi.
Nuovamente cito il caso dell'assembly: per rappresentare la stessa cosa ho bisogno di molte più istruzioni, e la comprensione di ciò che sto facendo diventa più problematica.
Viceversa, con Perl posso esprimere le stesse cose in maniera molto più compatta, ma a scapito di chiarezza e leggibilità.

Ricapitolando, per quanto mi riguarda il codice dovrebbe essere quanto più compatto, ma senza rinunciare a chiarezza e leggibilità.

Questo è il mio punto di vista. C'è qualcosa che non va in quello che ho scritto?

Un punto di vista non è mai criticabile in sè. E' come la vedi tu, se io dicessi è sbagliato tu saresti più che autorizzato a rispondermi "e tu vedila come cacchio ti pare". Si tratta semplicemente di cercare di capirlo e discuterne.

A me appaiono perfettamente leciti: anche in Java esistono delle istruzioni che NON rappresentano scambi di messaggi fra oggetti.

In SmallTalk non esistono istruzioni?

Nel senso di qualcosa che non sia un messaggio inviato ad un oggetto? No, non esistono.

Io lo trovo molto comodo, invece: mi basterebbe sostituire la funzione "built-in" print() con una mia per poter "reindirizzare" tutte le parti di codice che ne fanno uso.

A parte questo, non vedo perché sarebbe un punto a sfavore (se non per una maggiore immediatezza e semplicità della forma attuale): print diventerebbe un oggetto come un altro in Python, quindi rendendo il linguaggio più coerente da questo punto di vista.

Le interfacce non possono contenere attributi però, mentre le classi astratte sì: la differenza, quindi, c'è.

Non conosco Scala, per cui non so di cosa parli in quel contesto.

Non ho messo "totalmente" di fronte ad "astratta" per licenza poetica. Scala è un poco invidiabile mischione di caratteristiche, tutte molto belle ma che unite in una sola lingua richiedono il patentino da esorcista per poter essere gestite. E' un po' come Python ma polimorfo anzichè amorfo. Una cosa che permette di fare e che vorrei avesse avuto Java è la possibilità di creare la definizione di un oggetto anzichè la definizione di una categoria di oggetti da cui poi ricavare un'istanza. Come dire:

object Pippo {
    public String getName() { return "Pippo"; }
}
...
Pippo.getName();

Una specie di singleton (ogni oggetto è un singleton per il principio di identità).

Comunque non hai risposto sull'ereditarietà ed estensione multipla: ti piace? Non ti piace? Ed eventualmente perché.

L'estesione multipla non mi piace perchè richiede che sia introdotta una norma per stabilire cosa succeda quando due o più supertipi definiscano un medesimo comportamento. Es.:

class SuperOne {
    String getValue() { return "Hello" }
}

class SuperTwo {
    String getValue() { return "World" }
}

class Sub extends SuperOne, SuperTwo {
   //getValue() restituisce Hello o World ?
}

L'ereditarietà della sola dichiarazione non presenta lo stesso problema perchè è, appunto, mera dichiarazione di una capacità posseduta e non anche implementazione di quella capacità.

Dell'estensione (singola o multipla che sia) non apprezzo inoltre il fatto che essa costringa ad eccepire la comune regola secondo cui l'implementazione è sempre irrilevante: l'estensione è differisce dall'ereditarietà esattamente in ciò che la prima trasferisce dichiarazione e implementazione mentre la seconda trasferisce la sola dichiarazione. Se l'implementazione è sempre irrilevante perchè trasferirla? La risposta è per comodità ed è effettivamente comodo ma io non apprezzo le comodità che incrinano l'omogeneità dei principi.

Certamente, ma Python si avvicina di più al tuo ideale di prospettiva orientata agli oggetti: ti dà una maggior libertà di definire cos'è un oggetto e in che modo "risponde" a certe requisiti / caratteristiche, potendo anche cambiare "comportamento" dinamicamente.

Se ci fai caso sul linguaggio di per sé non ho avuto nulla di dire: Java lo trovo portatile ovunque, tanto quanto Python o altri.

Ma hai parlato anche di VM, e qui non ero d'accordo sulla portabilità e ti ho fatto un paio di esempi che mi sono venuti in mente. Tutto qui.

La VM è una cosa, le librerie sono un'altra. Tu hai fatto un esempio che non riguarda nè il linguaggio di programmazione Java nè la macchina virtuale: che facciamo?

Te ne sparo una sinteticamente: con Python è possibile modellare velocemente e in maniera semplice un problema, mantenendo il codice compatto, chiaro e manutenibile. Ci si focalizza sul problema. ;)

Così tanti spunti e così poco tempo per discuterli. Qui la chiave di volta "sinteticamente". Io credo che la sintesi sia una riduzione della quantità di parole necessaria per esprimere un concetto prodotta dal trasferimento di una parte delle informazioni dal discorso esplicito (dico tutto ciò che devi sapere) ad un campo implicito (presuppongo che tu sappia alcune delle cose necessarie a comprendere il concetto). E il punto è: esiste una misura di questo trasferimento? Quanto posso trasferire, quanto posso presupporre senza che ciò renda il discorso oscuro? Io credo che il codice Python presupponga troppo.

ROTFL. Mi fai morire.

Tanto le checked exception sono peggio del cancro dello scrivano, anche se non lo ammetterai mai.

Esiste un'articolata teoria dell'errore che richiede l'esistenza di due categorie di eccezioni, checked e unchecked, allo scopo di rappresentare due diverse categorie di condizioni eccezionali (per causa esterna e per causa interna). Che ti risparmio perchè son buono come il pane .