continuazione da "imparare a programmare" [Archivio]

mad_hhatter

03-10-2007, 16:10

Anche il mio era un errore di digitazione: al posto di digitare tmp ho scritto abc. Errori così capitano, e non poche volte, specialmente quando si fa copia & incolla del codice.

secondo te scrivere abbc al posto di abc è lo stesso tipo di errore che scrivere abc al posto di tmp? la causa del primo tipo è la semplice velocità di digitazione sulla tastiera, la seconda è una distrazione a livello logico... se per te sono la stessa cosa :rolleyes:

Ti sei perso un bel po' di messaggi: avevamo già detto che parlare di librerie è prematuro per chi non conosce nemmeno il concetto di variabile.

ma insomma, ho tirato fuori io il discorso del dizionario? questo sarebbe di interesse per uno che non sa cosa è una variabile? questo è un altro esempio di uso di 2 pesi e 2 misure: quando è utile a supportare la tua tesi che python è superiore possiamo nominare aspetti "avanzati", quando ti si risponde allora si stanno affrontando discorsi "troppo avanzati"... va beh.

Perché non si potrebbe fare, scusa? Si prende un algoritmo e lo si implementa nei diversi linguaggi. Da persone che abbiano un po' di esperienza, ovviamente. E poi si confrontano i risultati.

ma se hai appena detto che la leggibilità e il buono o cattivo codice dipendono da chi scrive... che grado di attendibilità e oggettività avrebbe il test che proponi?

Vaglielo a fare capire... Ma no, è chiaro che qui stiamo usando due pesi e due misure, perché non trattiamo quest'aspetto.

invece la programmazione multi paradigma è di primaria importanza per un novizio :rolleyes:

hai nuovamente aggirato le mie domande
niente affatto! ti ho mostrato che dal tuo discorso, nell'ambito dello sfruttamento di funzionalità avanzate del linguaggio in un momento futuro, la programmazione multiparadigma di python è un punto da tener in considerazione, mentre la programmazione concorrente nativa di java no... se non ti sembrano 2 pesi e 2 misure...

fabianoda

03-10-2007, 16:11

Ah cavolo, proprio dall'inizio del thread :P l'avevo già visto in parte, è lunghissimo però!!!

Se stasera ho tempo guardo e provo a dare un'impressione, cercando di essere il più obiettivo possibile. Comunque cercate di fare una tabella pro-contro e valutateli, è il modo migliore... :)

mad_hhatter

03-10-2007, 16:17

fabianoda

03-10-2007, 16:22

Beh, provate a fare una lista di caratteristiche... una volta fatta questa, la sottoponete come sondaggio alla comunità di hwupgrade, no?

cdimauro

03-10-2007, 16:36

secondo te scrivere abbc al posto di abc è lo stesso tipo di errore che scrivere abc al posto di tmp? la causa del primo tipo è la semplice velocità di digitazione sulla tastiera, la seconda è una distrazione a livello logico... se per te sono la stessa cosa :rolleyes:
Sono entrambi frutto della distrazione.
ma insomma, ho tirato fuori io il discorso del dizionario?
Fa parte del linguaggio.
questo sarebbe di interesse per uno che non sa cosa è una variabile?
Non adesso, ma il concetto di lista e dizionario si affrontano dopo aver trattato i tipi numerici, in virgola mobile e le stringhe.
questo è un altro esempio di uso di 2 pesi e 2 misure: quando è utile a supportare la tua tesi che python è superiore possiamo nominare aspetti "avanzati", quando ti si risponde allora si stanno affrontando discorsi "troppo avanzati"... va beh.
Anche Python ha il concetto di libreria, ma ci si arriva dopo aver esaminato gli altri aspetti basilari del linguaggi.

I due pesi e le due misure li vedi soltanto tu che non riesci ad accettare che un linguaggio di base sia più ricco di costrutti rispetto a un altro, e mette a disposizioni dei tipi che permettono di semplificare la vita all'utente senza introdurre altri concetti più avanzati.
ma se hai appena detto che la leggibilità e il buono o cattivo codice dipendono da chi scrive...
Certamente.
che grado di attendibilità e oggettività avrebbe il test che proponi?
Stiamo confrontando due linguaggi, per cui gli esempi verrebbero da gente esperta nei vari linguaggi di programmazione, quindi con una certa "qualità" del codice prodotto.

Con una qualità del codice paragonabile la differenza fra gli esempi prodotti la faranno soltanto le sintassi dei linguaggi.

Mi sembra piuttosto semplice.
invece la programmazione multi paradigma è di primaria importanza per un novizio :rolleyes:
Continui a mischiare le cose: un conto è offrire diversi paradigmi di programmazione e tutt'altra cosa usarli tutti fin dall'inizio.

Nessuno ha mai detto questo, sei soltanto tu che stai tirando delle conclusioni tue personali che nulla hanno a che vedere con quello che ho scritto io. :mc:
niente affatto! ti ho mostrato che dal tuo discorso, nell'ambito dello sfruttamento di funzionalità avanzate del linguaggio in un momento futuro, la programmazione multiparadigma di python è un punto da tener in considerazione, mentre la programmazione concorrente nativa di java no... se non ti sembrano 2 pesi e 2 misure...
Non lo sono perché ti ho già detto che anche Python offre il supporto alla programmazione concorrente, per cui Java non offre NESSUN VALORE AGGIUNTO.

Detto in parole povere, mettere o no la programmazione concorrente nel calderone delle varie funzionalità NON CAMBIA ASSOLUTAMENTE NULLA: la aggiungi sia a Java che a Python, oppure la togli sia a Java che a Python.

E' chiaro finalmente, sì o no? :rolleyes:

cdimauro

03-10-2007, 16:38

Beh, provate a fare una lista di caratteristiche... una volta fatta questa, la sottoponete come sondaggio alla comunità di hwupgrade, no?
Per me va benissimo, ma ci sono già delle paginette di wikipedia allo scopo.

Al limite qui potremmo portare degli esempi di quelle funzionalità.

k0nt3

03-10-2007, 16:39

mad_hhatter

03-10-2007, 16:39

Beh, provate a fare una lista di caratteristiche... una volta fatta questa, la sottoponete come sondaggio alla comunità di hwupgrade, no?

il forum è talmente stracolmo di discussioni sul confronto tra linguaggi che credo proprio che gli amministratori ci abbiano dedicato uno storage apposito :D :D

io francamente sono sfinito da queste discussioni: finiamo sempre per tirar dentro di tutto :D credo che anche cdimauro sia d'accordo

mad_hhatter

03-10-2007, 16:49

continuo a pensare che quello che state facendo sia inutile.. non esistono criteri oggettivi e questo vale per python come per java come per C
uno può consigliare in base alle proprie esperienze personali, ma non in base a considerazioni oggettive.
anche se fate una tabella con il confronto delle caratteristiche a quel punto dovreste stabilire se una data caratteristica è bene o male. in pratica non ci si salva più

visto anche il penultimo post di cdimauro io lascio... qui si continua a voler far passare per considerazioni oggettive opinioni ed esperienze personali...

esempio : "Non adesso, ma il concetto di lista e dizionario si affrontano dopo aver trattato i tipi numerici, in virgola mobile e le stringhe."

uno ha seguito questo percorso, quindi questo è l'unico percorso seguibile :rolleyes:

non c'è spazio per una discussione oggettiva, è inutile

cdimauro

03-10-2007, 16:52

iio francamente sono sfinito da queste discussioni: finiamo sempre per tirar dentro di tutto :D credo che anche cdimauro sia d'accordo
Io sono disponibile a continuare.

cdimauro

03-10-2007, 16:54

visto anche il penultimo post di cdimauro io lascio... qui si continua a voler far passare per considerazioni oggettive opinioni ed esperienze personali...

esempio : "Non adesso, ma il concetto di lista e dizionario si affrontano dopo aver trattato i tipi numerici, in virgola mobile e le stringhe."

uno ha seguito questo percorso, quindi questo è l'unico percorso seguibile :rolleyes:

non c'è spazio per una discussione oggettiva, è inutile
Cosa ci vedi di poco oggettivo? Hai mai avuto l'esigenza di memorizzare una sequenza di dati, anziché soltanto uno? Secondo te un concetto del genere viene prima o dopo quello di libreria.

In Java si chiamano array, mentre in Python liste.

Eppure per te non è oggettivo il fatto che io affermi che dovrebbero essere trattati prima delle librerie. :mc:

mad_hhatter

03-10-2007, 17:08

gli array si, le liste no... in java sono due cose leggermente diverse.

stando a quello di cui parlavi tu il dizionario è una struttura non necessariamente primaria... l'array si, sono d'accordo

ma già parlando di array si introduce il concetto di reference e di oggetto, e da qui il passo alla libreria è brevissimo

cdimauro

03-10-2007, 17:13

gli array si, le liste no... in java sono due cose leggermente diverse.
In Python sono la stessa cosa, per cui quando avrai l'esigenza di memorizzare più dati nello stesso contenitore, le dovrai studiare.
stando a quello di cui parlavi tu il dizionario è una struttura non necessariamente primaria...
A giudicare dall'intenso uso che se ne fa da tempo nei vari linguaggi di programmazione, direi proprio di sì.

Sono tanti i linguaggi che lo mettono a disposizione nativamente, infatti.
l'array si, sono d'accordo
Per la mia esperienza anche i dizionari sono ugualmente importanti.
ma già parlando di array si introduce il concetto di reference e di oggetto, e da qui il passo alla libreria è brevissimo
Non vedo cosa c'entrino le reference con le librerie.

Per gli oggetti, beh, in Python sono tutti oggetti...

mad_hhatter

03-10-2007, 17:49

Per la mia esperienza anche i dizionari sono ugualmente importanti.

Non vedo cosa c'entrino le reference con le librerie.

i dizionari hanno la stessa importanze di molte altre strutture di dati. la tua esperienza non è un parametro di valutazione: io i dizionari mi trovo a usarli di rado per esempio, ma questo non significa niente.

reference e libreria non c'entrano niente... quello che ho scritto è che una volta che si è appreso cos'è un oggetto si inizia a spulciare la libreria alla ricerca delle strutture dati che ci servono invece che reimplementarle da zero...

mad_hhatter

03-10-2007, 17:59

Hai mai avuto l'esigenza di memorizzare una sequenza di dati, anziché soltanto uno? Secondo te un concetto del genere viene prima o dopo quello di libreria.

io quando ho iniziato con java prima ancora di sapere cos'era un tipo primitivo ho scritto l'hello word... per stampare ho scritto system.out.println

così i primi concetti appresi sono stati:
classe e oggetto
package
import
membro statico
metodo

solo dopo sono venuti i numeri e gli array...
per un linguaggio OO non mi pare un percorso assurdo

PGI-Bis

03-10-2007, 19:15

Mi tolgo solo la curiosità di chiedere a chi ha definito baggianata il fatto che Java supporti una ed una sola prospettiva (quella orientata agli oggetti) di scrivere un programma strutturato in Java.

E faccio in anticipo la domanda che segue all'esempio che sarà scritto: a quale elemento della programmazione strutturata corrisponderebbe la classe?

Volendo si può anche scegliere di scriverne uno funzionale o imperativo. Resta comunque la domanda: a quale elemento della prospettiva funzionale corrisponderebbe mai la classe? A quale elemento della prospettiva procedurale corrisponderebbe mai la classe?

cdimauro

03-10-2007, 20:55

i dizionari hanno la stessa importanze di molte altre strutture di dati.
Sono oggetti molto conosciuti e usati nel campo dell'informatica. Nella letteratura li trovi chiamati "array sparsi", ma il concetto è molto più generale (ne parlo meglio dopo).
la tua esperienza non è un parametro di valutazione: io i dizionari mi trovo a usarli di rado per esempio, ma questo non significa niente.
Ho realizzato tante applicazioni in Python e nella stragrande maggioranza almeno un dizionario l'ho usato.

E io non amo usare cose delle cose soltanto perché ci sono: le uso in base al problema che devo risolvere.

A parte questo, immagino che avrai usato spesso degli switch, catene di if-else, tabelle di costanti, tavole hash, ecc., che rappresentano l'universale concetto di SELEZIONE.
Concetto che in Python si traduce molto spesso nell'uso di dizionari, appunto.

Quindi come vedi non puoi dire che li hai usati poche volte: semplicemente hai reso l'operazione di selezione in modo diverso.
reference e libreria non c'entrano niente... quello che ho scritto è che una volta che si è appreso cos'è un oggetto si inizia a spulciare la libreria alla ricerca delle strutture dati che ci servono invece che reimplementarle da zero...
Questo lo farai dopo che avrai imparato i mattoncini di base.
io quando ho iniziato con java prima ancora di sapere cos'era un tipo primitivo ho scritto l'hello word... per stampare ho scritto system.out.println

così i primi concetti appresi sono stati:
classe e oggetto
package
import
membro statico
metodo

solo dopo sono venuti i numeri e gli array...
per un linguaggio OO non mi pare un percorso assurdo
A me è bastato questo:
print 'Hello, world!'
e ho raggiunto immediatamente l'obiettivo col minimo sforzo e, ma tu guarda un po', col massimo della leggibilità.

Quanto a ciò di cui stavamo parlando, resta ancora in piedi il concetto che ho espresso: avere a che fare con sequenze di dati e strumenti di selezione è cosa comunissima nella programmazione, e Python e te li offre in maniera estremamente flessibile. Il tutto senza andare, appunto, a scomodare alcuna libreria (a proposito, sempre per il discorso dell'omogeneità di cui si parlava prima, in Python anche queste sono... oggetti :p).

cdimauro

03-10-2007, 21:36

sarebbe stato interessante discutere sulla leggibilità dei blocchi..
Basta prendere un algoritmo scritto in pseudocodice e guardare com'è fatto.
o sulla disomogeneità della sintassi python..
Questa me la dovresti spiegare.
comunque io ho usato python e quindi so di cosa parlo. lo "sporcarsi le mani" era più riferito al fatto che sembra che più è alto il livello del linguaggio e più è meglio per iniziare. nessuno sa qual'è la strada corretta, per cui escludere delle strade a priori è senz'altro sbagliato.
Basta confrontare il sorgente di un'applicazione Python e la fila di opcode di un eseguibile in linguaggio macchina per rispondere alla tua domanda.
senti è inutile continuare a parlare di aria.. io ti ho fornito un esempio, sei in grado di fare altrettanto te?
al massimo si potrebbe teorizzare che un programma scritto in un certo linguaggio lungo 6 righe di codice ha meno probabilità di contenere bug di un altro programma scritto nello stesso linguaggio con più righe di codice. ma confrontare due programmi scritti in due linguaggi diversi ci dice molto poco... se non nulla.
Non devi convincere noi: vaglielo a dire a chi ha tirato fuori la metrica dei bug per numero di codice. La letteratura informatica è piena di riferimenti a questa metrica, che è fra le più usate.
forse perchè non era una risposta all'osservazione di cesare :fagiano:
lasciamo perdere sta faccenda delle eccezioni, per me a uno che inizia non danno nessun aiuto. nel senso che imparare a usare un debugger è buona cosa comunque.
E partiamo anche col linguaggio macchina allora.

Comunque su questo ti ha risposto in maniera impeccabile marco.r, con cui mi ritrovo pienamente.
se poi parliamo di SEMPLICITA' mi dispiace ma con python non ci siamo.. troppi modi per fare la stessa cosa..
Ma che stai a dire?!? Guarda che ti stai confondendo con PERL e Ruby.

Se c'è una cosa che a cui si tiene particolarmente in Python è proprio quella di offrire (possibilmente) un solo modo per fare la stessa cosa: è proprio nel DNA del linguaggio e il pensiero di fisso di chi l'ha creato e di chi lo sostiene.

Guarda qui cosa succede se scrivi "import this" (senza virgolette) e premi invio nell'interprete Python:
>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
E ancora, qui http://www.python.org/dev/peps/pep-3100/ si parla del futuro Python 3.0 che sarà un consistente rimaneggiamento del linguaggio. Da notare l'obiettivo fondamentale:
General goals

A general goal is to reduce feature duplication by removing old ways of doing things. A general principle of the design will be that one obvious way of doing something is enough.
Che poi è l'esatto opposto di PERL e di Ruby.

Quindi fammi il favore: se di Python sai poco e niente, evita di lanciarti in affermazioni suicide che cozzano violentamente con la FILOSOFIA di base di questo linguaggio.

I pythonisti sono talmente fissati che non si fanno nemmeno problemi a rinunciare alla compatibilità col passato pur di avere un linguaggio "omogeneo" e con una solida filosofia, ed è quello che avverrà appunto con Python 3.0.
In particolare, http://www.python.org/dev/peps/pep-3000/#compatibility-and-transition :

"Python 3.0 will break backwards compatibility with Python 2.x."

Una cosa che non vedrai con gli altri linguaggi, che pur di mantenere la compatibilità col passato diventano dai pachidermi che inglobano tutto.
troppi paradigmi insieme.
E' un bene: c'è maggior espressività. E tra l'altro pure Java ha imboccato un processo di "inglobamento" di funzionalità prese in prestito da altri linguaggi che offrono paradigmi diversi da quelli offerti da Java (ad esempio le closure che tanto piacciano a PGI-Bis sono prese da LISP).
banalmente se vuoi iniziare dalla programmazione strutturata non inizi da java. pessima scelta quella far finta che un linguaggio a oggetti sia un linguaggio procedurale.
Mica è soltanto a oggetti...
ma quali titoli nobiliari.. non mi interessa dirti quale esame era o cosa faccio nella mia vita. sta di fatto che in un esame ho affrontato l'argomento python e visto che è andato bene posso dire che lo conosco.
Certo, lo conosci così da bene da confonderlo con linguaggi completamente diversi. :rolleyes:
parlando del framework penso che ci sia poco da dire.. quello di java non teme rivali. come anche la documentazione, la javadoc è un punto di riferimento
Dai un'occhiata PyDoc, che non ha nulla da invidiargli.

DioBrando

03-10-2007, 21:40

Faccio una premessa.
trovo che il titolo sia stato poco azzeccato. Sarebbe stato meglio scrivere "confronto tra Java e Python", oppure "imparare a programmare: scelgo Python o Java?" et similia.
Così non si capisce come il cuore della discussione sia il confronto tra i due linguaggi (ed anche di là, alla fine 9 pagine su 11 si parlava proprio di questo).

Cmq vabbè ormai è stato scelto così, pazienza.

io quando ho iniziato con java prima ancora di sapere cos'era un tipo primitivo ho scritto l'hello word... per stampare ho scritto system.out.println

così i primi concetti appresi sono stati:
classe e oggetto
package
import
membro statico
metodo

solo dopo sono venuti i numeri e gli array...
per un linguaggio OO non mi pare un percorso assurdo

perchè non ci infiliamo anche l'ereditarietà singola, il multithreading e altre nozioni già che ci siamo?

No perchè se dobbiamo fare un minestrone di "cose da sapere" al primo Hello world che l'utente (che vuole imparare a programmare) si trova a fare, tanto vale farlo bene no? (Anzi studiamoci direttamente tutta la teoria e poi applichiamola...e con un linguaggio X perchè tanto in fin dei conti non conta molto questa scelta :))

d'altra parte è logico che per te sia un approccio corretto, visto che è normale, sempre secondo te, studiare Fondamenti I come primo corso universitario...

Con Java scrivi:

class HelloWorld {
public static void main (String[] args) {
System.out.println("Hello World");
}
}

Legenda:
S = studente
P = professore

S: prof che cos'è class?
P: "è un argomento che tratteremo + avanti non ti preoccupare, intanto ricordati per un motivo di leggibilità e di non confusione che il nome della classe che sceglierai dovrà avere la prima lettera della parola in maiuscolo"
S: E public?
P: anche quello lo vedremo + avanti, intanto ricordati di copiare, dopo la linea in cui definisci la classe, tutta quella riga
S: quindi le parole "public static void main (String[] args)" ci verranno spiegati + avanti nel programma?
P: sì nella prossime lezioni vedremo i tipi di dato, poi le strutture di controllo...

Questo è quello che succede in un corso "normale" di programmazione 1 in cui si scelga Java come linguaggio.
Alla faccia della didattica: uso una decina di parole riservate e per ovvii motivi mi trovo a spiegarne una sola.

Con Python invece scrivi:
print "Hello World"

Basta. Fine. Non ci si perde nelle definizioni e nel "beh per ora scrivi così, poi dopo imparerai cosa significa e perchè si usa"
Si impara cosa sia print (che è +ttosto intuitivo da solo no?).
Poi dopo ci sarà il tempo per complicarsi la vita e per imparare le altre strutture del linguaggio.

Se invece lo scopo è quello di imparare a programmare direttamente con un approccio OO allora prendiamo Smalltalk o Eiffel che sono OO puri.

cdimauro

03-10-2007, 21:44

Anche Python è OO "puro", eh! :p

Tutti gli elementi con cui interagiamo sono oggetti che si "scambiano dei messaggi". ;)

k0nt3

03-10-2007, 22:00

Non devi convincere noi: vaglielo a dire a chi ha tirato fuori la metrica dei bug per numero di codice. La letteratura informatica è piena di riferimenti a questa metrica, che è fra le più usate.
si vede che non leggi nemmeno cosa scrivo :rolleyes: la metrica ha senso solo a parità di linguaggio

Comunque su questo ti ha risposto in maniera impeccabile marco.r, con cui mi ritrovo pienamente.
non ho mai sentito dolore per un bug nel codice. se non si nota a occhio si fa un pò di debug e via.

Ma che stai a dire?!? Guarda che ti stai confondendo con PERL e Ruby.

Se c'è una cosa che a cui si tiene particolarmente in Python è proprio quella di offrire (possibilmente) un solo modo per fare la stessa cosa: è proprio nel DNA del linguaggio e il pensiero di fisso di chi l'ha creato e di chi lo sostiene.

allora dovrebbe supportare un solo paradigma.. mi sa che si contraddicono da soli :fagiano:

poi non ho mai capito perchè print "hello" e non print("hello")

DioBrando

03-10-2007, 22:01

sì io per "puro" intendevo per quanto riguarda sia il paradigma di programmazione usato sia per quanto riguarda le strutture usate :)

k0nt3

03-10-2007, 22:03

Anche Python è OO "puro", eh! :p

Tutti gli elementi con cui interagiamo sono oggetti che si "scambiano dei messaggi". ;)

quando scrivo:
print "hello"
non vedo nessuna interazione tra oggetti

cdimauro

03-10-2007, 22:09

si vede che non leggi nemmeno cosa scrivo :rolleyes: la metrica ha senso solo a parità di linguaggio
L'ho letto e non sono affatto d'accordo.
non ho mai sentito dolore per un bug nel codice. se non si nota a occhio si fa un pò di debug e via.
Si vede che non hai mai realizzato programmi di una certa consistenza in C, dove per tracciare un segmentation fault dovevi fare i salti mortali.
allora dovrebbe supportare un solo paradigma.. mi sa che si contraddicono da soli :fagiano:
Non confondere un paradigma di programmazione con gli strumenti che vengono messi a disposizione dei programmatori.
poi non ho mai capito perchè print "hello" e non print("hello")
Perché è un'istruzione, come if, while, for, ecc., o anche questi dovrebbero essere degli oggetti secondo te?

Comunque, a dimostrazione che di Python non t'interessi e che ne sai poco e niente, direttamente dal primo link che ho riportato sopra (e che non hai nemmeno letto a questo punto):

"Replace print by a function[done]"

Contento? Come vedi chi sviluppa il linguaggio è talmente ossessionato dal fatto che debba essere "omogeneo" che non gliene frega nulla di compere la compatibilità col passato andando a cambiare addirittura un'istruzione usatissima come print. E scusa se è poco.
quando scrivo:
print "hello"
non vedo nessuna interazione tra oggetti
Nemmeno qui:
if True:
pass
C'è interazione fra oggetti. Si chiamano istruzioni.

cdimauro

03-10-2007, 22:10

sì io per "puro" intendevo per quanto riguarda sia il paradigma di programmazione usato sia per quanto riguarda le strutture usate :)
OK :)

DioBrando

03-10-2007, 22:12

si vede che non leggi nemmeno cosa scrivo :rolleyes: la metrica ha senso solo a parità di linguaggio

no ha senso a prescindere dal linguaggio, sono teorie agnostiche rispetto agli strumenti utilizzati e che valgono sempre e cmq.

Altrimenti questo tipo di analisi come lo svolgi quando si tratta di software che utilizza + linguaggi di programmazione? (tanto per citare un caso)

Hai dato l'esame di Ingegneria del Software 1 e 2? :D

non ho mai sentito dolore per un bug nel codice. se non si nota a occhio si fa un pò di debug e via.

e che ci vuole...pensa se fai questo ragionamento in un caso in cui dai per scontato che il garbage collector assolva il proprio ruolo mentre sei in una di quelle eccezione che devi controllare manualmente tu.

Guarda uno sviluppatore che non si preoccupa della lunghezza del codice, nè per il numero di bug che (inevitabilmente) si verificano, non l'ho mai sentito.

allora dovrebbe supportare un solo paradigma.. mi sa che si contraddicono da soli :fagiano:

perchè nei linguaggi che utilizzano un solo paradigma è possibile risolvere o implementare un algoritmo in un unico modo?

Mi sfugge la logica del tuo ragionamento per cui dovrebbero essere in contraddizione.

k0nt3

03-10-2007, 22:19

L'ho letto e non sono affatto d'accordo.
prima ho portato un esempio in cui scrivere più codice serviva a evitare gli errori.. guardacaso calzava a pennello confrontando python con java. potresti portare un controesempio?

Si vede che non hai mai realizzato programmi di una certa consistenza in C, dove per tracciare un segmentation fault dovevi fare i salti mortali.

in realtà l'ho realizzato eccome.. per questo ora uso java :p
ma stavamo parlando di imparare a programmare no? cosa c'entrano i programmi di una certa consistenza?

Non confondere un paradigma di programmazione con gli strumenti che vengono messi a disposizione dei programmatori.

due paradigmi sono 2 modi di vedere le cose, quindi due modi di fare la stessa cosa

Perché è un'istruzione, come if, while, for, ecc., o qualche questi dovrebbero essere degli oggetti secondo te?

pensavo che if while for ecc.. fossero parole chiave e non funzioni :fagiano:

Comunque, a dimostrazione che di Python non t'interessi e che ne sai poco e niente, direttamente dal primo link che ho riportato sopra (e che non hai nemmeno letto a questo punto):

"Replace print by a function[done]"

Contento? Come vedi chi sviluppa il linguaggio è talmente ossessionato che sia "omogeneo" che non gliene frega nulla di compere la compatibilità col passato andando a cambiare addirittura un'istruzione usatissima come print. E scusa se è poco.

Nemmeno qui:
if True:
pass
C'è interazione fra oggetti. Si chiamano istruzioni.
se l'hanno corretto tanto meglio, sta di fatto che print "hello" era rotto :O
non capisco il tuo secondo esempio :|
se prendi java ad esempio le interazioni tra gli oggetti si vedono sempre

cdimauro

03-10-2007, 22:34

prima ho portato un esempio in cui scrivere più codice serviva a evitare gli errori.. guardacaso calzava a pennello confrontando python con java. potresti portare un controesempio?
Prima quando? Riportalo, cortesemente, anche se sarà la classica eccezione che conferma la regola.

Comunque mi ritrovo con quello che ha scritto DioBrando poco fa.
in realtà l'ho realizzato eccome.. per questo ora uso java :p
ma stavamo parlando di imparare a programmare no? cosa c'entrano i programmi di una certa consistenza?
Perché hai scritto questo:

"non ho mai sentito dolore per un bug nel codice. se non si nota a occhio si fa un pò di debug e via."

e i dolori dovuti a bug per codice non banale si fanno sentire, eccome.
due paradigmi sono 2 modi di vedere le cose, quindi due modi di fare la stessa cosa
Questo succede a livello macroscopico. A livello di linguaggio Python mette a disposizione oggetti che interagiscono. Infatti persino le funzioni, in Python, sono oggetti con le loro proprietà.

Poi come programmatore puoi sfruttare le loro caratteristiche per implementare un algoritmo come vuoi, anche sfruttando una mistura di ciò che a più alto livello sono due paradigmi diversi.
pensavo che if while for ecc.. fossero parole chiave e non funzioni :fagiano:
Infatti sono istruzioni per cui Python come linguaggio riserva delle parole chiave.

Da notare che esistono altri linguaggi, come il PL/1, che non riservano parole chiave per nessuna istruzione.
se l'hanno corretto tanto meglio, sta di fatto che print "hello" era rotto :O
Non direi, visto che si trattava di un'istruzione come altre.

Guido comunque ha fornito delle valide motivazioni per farla diventare una funzione built-in, esattamente come tante altre che Python mette a disposizione.

non capisco il tuo secondo esempio :|
Era un altro esempio che dimostrare che print è un'istruzione, al pari di if, ecc., per le quali NON c'è interazione fra oggetti.
se prendi java ad esempio le interazioni tra gli oggetti si vedono sempre
Certo, è evidentissimo:
int i = 1;
la variabile i "interagisce" con l'oggetto numero uno...

k0nt3

03-10-2007, 22:39

no ha senso a prescindere dal linguaggio, sono teorie agnostiche rispetto agli strumenti utilizzati e che valgono sempre e cmq.

Altrimenti questo tipo di analisi come lo svolgi quando si tratta di software che utilizza + linguaggi di programmazione? (tanto per citare un caso)

allora dimostralo deve essere facile. prendi l'esempio di java.. scrivi una marea di codice, ma allo stesso tempo il compilatore ti da una grossa mano. secondo te è da trattare allo stesso modo di python dove per il compilatore puoi scrivere anche cose senza senso tipo dividere un intero per una stringa?
se usi linguaggi diversi in un progetto puoi fare queste analisi solo nelle parti che usano lo stesso linguaggio

Hai dato l'esame di Ingegneria del Software 1 e 2? :D

ma risparmiatele certe domande, non sei certo te che mi insegni cos'è l'ingegneria del software

e che ci vuole...pensa se fai questo ragionamento in un caso in cui dai per scontato che il garbage collector assolva il proprio ruolo mentre sei in una di quelle eccezione che devi controllare manualmente tu.

perchè il GC non dovrebbe assolvere il suo compito? e poi che problema c'è con il debug?

Guarda uno sviluppatore che non si preoccupa della lunghezza del codice, nè per il numero di bug che (inevitabilmente) si verificano, non l'ho mai sentito.

mai detto questo. in java è inevitabile scrivere più righe di codice che in python, ma non è affatto vero che si commettono più errori

perchè nei linguaggi che utilizzano un solo paradigma è possibile risolvere o implementare un algoritmo in un unico modo?

Mi sfugge la logica del tuo ragionamento per cui dovrebbero essere in contraddizione.
no uno può implementare gli algoritmi come gli pare, solo che nel caso di più paradigmi insieme il linguaggio perde inevitabilmente di omogeneità, e quindi aumenta la confusione. l'esempio più lampante che mi viene in mente è C++

k0nt3

03-10-2007, 22:48

Prima quando? Riportalo, cortesemente, anche se sarà la classica eccezione che conferma la regola.
non ne ho voglia :fagiano: comunque in breve il fatto di poter evitare la dichiarazione delle variabili ti porta a scrivere meno codice, ma anche a commettere dei potenziali errori che altrimenti non potresti commettere. in ogni modo è difficile trovare un esempio in cui java è più "error prone" di python nonostante sia altamente banale trovare esempi in cui java richiede più codice di python

Era un altro esempio che dimostrare che print è un'istruzione, al pari di if, ecc., per le quali NON c'è interazione fra oggetti.

Certo, è evidentissimo:
int i = 1;
la variabile i "interagisce" con l'oggetto numero uno...
quello che avevo postato prima in python era un programma completo in cui non vi era alcuna interazione tra oggetti, mentre l'istruzione che hai postato te non è un programma completo.
la differenza è che un linguaggio che permette la creazione di programmi in cui non vi è nessuna interazione tra oggetti non si può definire puramente a oggetti

cdimauro

04-10-2007, 08:16

allora dimostralo deve essere facile. prendi l'esempio di java.. scrivi una marea di codice, ma allo stesso tempo il compilatore ti da una grossa mano. secondo te è da trattare allo stesso modo di python dove per il compilatore puoi scrivere anche cose senza senso tipo dividere un intero per una stringa?
E dove starebbe scritto che è una cosa senso? Quello che ancora non hai capito è che non devi trattare Python come gli altri linguaggi "tradizionali" con cui hai avuto a che fare adesso.

Python è un linguaggio puramente a oggetti, per i quali è previsto uno "scambio di messaggio" nelle loro interazioni. Questo significa che se un oggetto "risponde" al messaggio "dividi per", l'operazione è perfettamente legittima, altrimenti viene sollevata un'eccezione.

Infatti ci sono oggetti che "rispondono" correttamente: i numeri è il classico esempio, ma potrei anche prendere un insieme e definire l'operatore di divisione per generarmi una partizione, ad esempio.

Ovviamente, essendo un linguaggio dinamico, il tutto avviene a runtime e non in fase di compilazione.
se usi linguaggi diversi in un progetto puoi fare queste analisi solo nelle parti che usano lo stesso linguaggio
Nessuno t'impedisce di calcolare il numero di bug per linee di codice di un intero progetto. Anzi, è una cosa perfettamente legittima.
ma risparmiatele certe domande, non sei certo te che mi insegni cos'è l'ingegneria del software
Puoi sempre rispondere e dimostrare che ne hai conoscenza, no?
perchè il GC non dovrebbe assolvere il suo compito?
Perché può anche capitare che finalizzi un oggetto in un certo momento dell'esecuzione e a causa di ciò sollevi un'eccezione (nel codice del distruttore dell'oggetto.)
e poi che problema c'è con il debug?
Che, come ti ho già detto, per progetti non banali tante volte non è semplice farlo, nemmeno con l'aiuto di un debugger.
mai detto questo. in java è inevitabile scrivere più righe di codice che in python, ma non è affatto vero che si commettono più errori
Se hai più linee di codice mi sembra a dir poco ovvio che hai più possibilità di avere dei bug. Ovviamente sto parlando in generale, non dei casi particolari, che esistono sempre e non dimostrano nulla.

E' il motivo per cui si è passati da linguaggi di basso/bassissimo livello, come linguaggio macchina & assembly ad altri di altissimo livello, come Python: c'è MOOOOOOLTA meno probabilità di commettere errori perché per implementare gli algoritmi nel primo caso devi scrivere tantissime linee di codice, mentre nel secondo caso ne scriverai molte meno perché hai tanti strumenti di alto livello (che ti semplificano la vita).
no uno può implementare gli algoritmi come gli pare, solo che nel caso di più paradigmi insieme il linguaggio perde inevitabilmente di omogeneità, e quindi aumenta la confusione. l'esempio più lampante che mi viene in mente è C++
Ed è un esempio che non calza assolutamente con Python, di cui è ormai evidente non hai ancora capito niente.

Lo ripeto per l'n-esima volta: Python è un linguaggio puramente a oggetti che mette nativamente a disposizione diverse CLASSI E OGGETTI che hanno delle BEN PRECISE PROPRIETA'.

Tu come programmatore puoi usarli per risolvere i tuoi problemi: li "combinerai", li farai interagire, sfrutterai le loro caratteristiche peculiari per arrivare al tuo scopo. E' da tutto ciò che possiamo dire che lavorare con Python permette di sfruttare, o per meglio dire simulare, diversi paradigmi di programmazione.

Un esempio lampante di ciò è l'uso delle funzioni, che ci permette di parlare di programmazione funzionale (possiamo scrivere un programma come combinazioni di chiamate a funzioni).
Ebbene, le funzioni (anche quelle anonime / lambda / closure che dir si voglia) sono semplicementi degli oggetti che hanno la particolare proprietà di essere "invocati"; questo vuol dire che scrivendo Pippo e usando l'operatore di "esecuzione" (rappresentato dalle parentesi tonde, con eventuali parametri annessi) io sto spedendo un particolare messaggio al mio oggetto, che poi risponderà tornando un risultato.

Lo stesso "giochetto" lo possiamo fare con l'istanza di una classe: mi è sufficiente definire l'operatore __call__ nella classe da cui discende per renderlo "eseguibile". Questo vuol dire che se Pluto è un'istanza della classe di cui sopra, scrivendo Pluto('Ciao!') io farò uso dell'operatore () per spedire un messaggio a Pluto, con l'eventuale parametro passato.
Da ciò si vede che Pluto, che è un oggetto, si comporta come se fosse una funzione, ma qual è la differenza con la funzione Pippo prima definita? Nessuna: sono tutte e due degli oggetti, che offrono al programmatore la caratteristica di poter essere "eseguiti".

Tra l'altro questo comportamento sarebbe (parzialmente) fattibile anche in Java se permettesse di ridefinire gli operatori (che a te non piace, lo so).

E' chiaro adesso o devo aspettarmi di tornare un'altra volta sull'argomento?

Ripeto: se non conosci Python evita di lasciarti andare a dichiarazioni prive di senso. Non basta aver studiato la sintassi di un linguaggio, aver fatto qualche esercizietto e passato un esame per poter dichiarare di saperci programmare.

cdimauro

04-10-2007, 08:39

non ne ho voglia :fagiano: comunque in breve il fatto di poter evitare la dichiarazione delle variabili ti porta a scrivere meno codice, ma anche a commettere dei potenziali errori che altrimenti non potresti commettere.
Tutto qui? E' un caso particolare.
in ogni modo è difficile trovare un esempio in cui java è più "error prone" di python nonostante sia altamente banale trovare esempi in cui java richiede più codice di python
Infatti, riallacciandomi anche al discorso di cui sopra, le considerazioni andrebbero fatte sempre sul solito numero di bug per righe di codice, che permette di astrarsi dai casi particolari che hai citato (che esisteranno sempre).

Faccio un esempio che confuta la tua citazione precedente. Il C è un linguaggio che obbliga a dichiarare le variabili da usare, e per cui quindi il caso di cui sopra non sarebbe applicabile perché il compilatore segnalebbe immediatamente il tentativo d'uso di variabili inesistenti.
Domanda: per te è più facile che i programmi Python abbiano più bug rispetto a quelli scritti in C? Io, avendo lavorato non poco con entrambi, una risposta me la so dare facilmente.

Questo a dimostrazione che bisogna analizzare globalmente il problema dei bug, e non fossilizzarsi ai singoli casi "da manuale", che di per sé non dicono proprio nulla.
quello che avevo postato prima in python era un programma completo in cui non vi era alcuna interazione tra oggetti, mentre l'istruzione che hai postato te non è un programma completo.
Tutto qui? Ecco:
public class SonoUnProgrammaCompletoMaSenzaOggetti {
public static void main(String[] args) {
int a = 1; // Non si direbbe, ma sono un oggetto. Non si direbbe, ma interagisco.
}
}
Adesso ci siamo, no? :D
la differenza è che un linguaggio che permette la creazione di programmi in cui non vi è nessuna interazione tra oggetti non si può definire puramente a oggetti
Questa è una tua definizione suppongo, ampiamente NON condivisibile. :p

mad_hhatter

04-10-2007, 09:02

A parte questo, immagino che avrai usato spesso degli switch, catene di if-else, tabelle di costanti, tavole hash, ecc., che rappresentano l'universale concetto di SELEZIONE.
Concetto che in Python si traduce molto spesso nell'uso di dizionari, appunto.

il fatto che in python si usi una certa espressione non la rende automaticamente universale :) comunque switch e catene di if-else cerco di evitarli il più possibile visti i problemi di manutenibilità che comportano... se li uso, sono cortissimi, se diventano lunghi preferisco incapsulare la variazione e sfruttare il polimorfismo.

so che java presenta le enumeration, ma non mi sono mai trovato a doverle usare...

k0nt3

04-10-2007, 09:03

SonoUnProgrammaCompletoMaSenzaOggetti è una classe no?

Faccio un esempio che confuta la tua citazione precedente. Il C è un linguaggio che obbliga a dichiarare le variabili da usare, e per cui quindi il caso di cui sopra non sarebbe applicabile perché il compilatore segnalebbe immediatamente il tentativo d'uso di variabili inesistenti.
Domanda: per te è più facile che i programmi Python abbiano più bug rispetto a quelli scritti in C? Io, avendo lavorato non poco con entrambi, una risposta me la so dare facilmente.

più che confutare dimostra che ho ragione. perchè hai preso C e non java? java in media richiede un numero di righe di codice ancora maggiore del C.. dovrei concludere che è più facile trovare un bug in un programma in java piuttosto che in un programma C?
ripeto che questo confronto non ha senso tra linguaggi diversi

non è condivisibile che python non è un linguaggio a oggetti puro? ti sembra programmazione OO questa?
print "hello"

mad_hhatter

04-10-2007, 09:13

perchè non ci infiliamo anche l'ereditarietà singola, il multithreading e altre nozioni già che ci siamo?

No perchè se dobbiamo fare un minestrone di "cose da sapere" al primo Hello world che l'utente (che vuole imparare a programmare) si trova a fare, tanto vale farlo bene no? (Anzi studiamoci direttamente tutta la teoria e poi applichiamola...e con un linguaggio X perchè tanto in fin dei conti non conta molto questa scelta :))

d'altra parte è logico che per te sia un approccio corretto, visto che è normale, sempre secondo te, studiare Fondamenti I come primo corso universitario...

Con Java scrivi:

class HelloWorld {
public static void main (String[] args) {
System.out.println("Hello World");
}
}

Legenda:
S = studente
P = professore

S: prof che cos'è class?
P: "è un argomento che tratteremo + avanti non ti preoccupare, intanto ricordati per un motivo di leggibilità e di non confusione che il nome della classe che sceglierai dovrà avere la prima lettera della parola in maiuscolo"
S: E public?
P: anche quello lo vedremo + avanti, intanto ricordati di copiare, dopo la linea in cui definisci la classe, tutta quella riga
S: quindi le parole "public static void main (String[] args)" ci verranno spiegati + avanti nel programma?
P: sì nella prossime lezioni vedremo i tipi di dato, poi le strutture di controllo...

Questo è quello che succede in un corso "normale" di programmazione 1 in cui si scelga Java come linguaggio.
Alla faccia della didattica: uso una decina di parole riservate e per ovvii motivi mi trovo a spiegarne una sola.

un corso che si chiama FONDAMENTI dove lo inseriresti?
comunque un corso di informatica per studenti di ingegneria informatica cosa dovrebbe insegnare? quante ore di lezione secondo te dovrebbero passare prima di iniziare a introdurre i concetti di un linguaggio OO? guarda che tra il non spiegare nulla e lo spiegare tutto dall'inizio alla fine esistono molti livelli intermedi di approfondimento che possono dare una visione d'insieme lasciando gli approfondimenti ad un momento successivo... non mi pare che accennare al concetto di classe, oggetto, package, metodo sia traumatico... non capisco questo tuo stupore.

io trovo che un approccio serio alla didattica sia: ti do' la definizione degli strumenti che usi e da qui andiamo avanti...

quando hai mostrato il

print "Hello"

che comprensione ne traggono gli studenti al di là del "ah... bello". quanto dura questa fase in cui vengono mostrate istruzioni specifiche invece di dare una visione generale e di alto livello che di sicuro è molto più utile ai fini dell'apprendimento (almeno quello serio)?

cdimauro

04-10-2007, 09:14

il fatto che in python si usi una certa espressione non la rende automaticamente universale :)
No, ma si presta a risolvere parecchi problemi (anche per questo tanti linguaggi moderni lo integrano nativamente, o almeno nella libreria standard), inoltre anziché aggiungere complessità al linguaggio introducendo nuove istruzioni (ad esempio lo switch, che manca del tutto in Python e di cui non si sente il bisogno perché esistono delle validissime alternative, appunto), s'è preferito introdurre un nuovo e molto utile tipo di dato.
comunque switch e catene di if-else cerco di evitarli il più possibile visti i problemi di manutenibilità che comportano... se li uso, sono cortissimi, se diventano lunghi preferisco incapsulare la variazione e sfruttare il polimorfismo.
Anche in Java esistono le "mappe": servono proprio per questi problemi, e sono l'equivalente dei dizionari di Python.

Scomodare incapsulamento e polimorfismo ci può anche stare, ma dipende strettamente dal problema.
so che java presenta le enumeration, ma non mi sono mai trovato a doverle usare...
Servono ad altro, però.

mad_hhatter

04-10-2007, 09:36

No, ma si presta a risolvere parecchi problemi (anche per questo tanti linguaggi moderni lo integrano nativamente, o almeno nella libreria standard), inoltre anziché aggiungere complessità al linguaggio introducendo nuove istruzioni (ad esempio lo switch, che manca del tutto in Python e di cui non si sente il bisogno perché esistono delle validissime alternative, appunto), s'è preferito introdurre un nuovo e molto utile tipo di dato.

Anche in Java esistono le "mappe": servono proprio per questi problemi, e sono l'equivalente dei dizionari di Python.

non ho detto che sono inutili, ho detto che in java sono nella libreria standard e che ci sono strutture per tutti i gusti... e che il fatto che il linguaggio offra strutture dati nativamente o tramite libreria standard mi pare del tutto indifferente... giuro, non vedo la differenza

Scomodare incapsulamento e polimorfismo ci può anche stare, ma dipende strettamente dal problema.

appunto, dipende da cosa ti serve... è quello che ho detto nel mio post precedente.

cdimauro

04-10-2007, 09:41

SonoUnProgrammaCompletoMaSenzaOggetti è una classe no?
Mi sfugge la presenza degli oggetti, che addirittura dovrebbero interagire, per RISOLVERE IL PROBLEMA (non basta, infatti, usare una classe, che in questo caso fa la parte del mero contenitore di istruzioni).
più che confutare dimostra che ho ragione. perchè hai preso C e non java? java in media richiede un numero di righe di codice ancora maggiore del C.. dovrei concludere che è più facile trovare un bug in un programma in java piuttosto che in un programma C?
L'ho preso perché il C è un linguaggio che corrisponde al quadro che hai delineato, ma i cui programmi sono altamente soggetti a bug. Questo per dimostrare che prendere una precisa caratteristica di un linguaggio per valutare la predisposizione a commettere errori non ha senso.

Quanto alla quantità di righe di codice, per progetti non banali in Java se ne scrivono meno.
ripeto che questo confronto non ha senso tra linguaggi diversi
Ha senso per un intero progetto, infatti, come avevo già scritto.
non è condivisibile che python non è un linguaggio a oggetti puro? ti sembra programmazione OO questa?
print "hello"
Ne avevamo già parlato: stai facendo uso di un'ISTRUZIONE. Per caso esistono dei linguaggi che non ne hanno?

cdimauro

04-10-2007, 09:49

non ho detto che sono inutili, ho detto che in java sono nella libreria standard e che ci sono strutture per tutti i gusti... e che il fatto che il linguaggio offra strutture dati nativamente o tramite libreria standard mi pare del tutto indifferente... giuro, non vedo la differenza
La differenza è che in Python basta scrivere roba così:

a = {'Qui' : 1, 'Quo' : 2, 'Qua' : 3}

e hai già tutto. Con una libreria è UN TANTINO più complicato e meno immediato, no (e devi conoscere anche il concetto di libreria)?

Se i dizionari/mappa/hash sono ormai presenti in tanti linguaggi "nativamente", è proprio perché si tratta di strutture molto utili e comunemente usate, che permettono di risolvere in maniera semplice ed elegante tanti problemi.

Tu non ci vedi differenza, ma anche didatticamente le due cose sono ben diverse (e con ciò mi riallaccio anche a quello che aveva scritto in precedenza DioBrando sull'argomento).

mad_hhatter

04-10-2007, 10:36

La differenza è che in Python basta scrivere roba così:

a = {'Qui' : 1, 'Quo' : 2, 'Qua' : 3}

e hai già tutto. Con una libreria è UN TANTINO più complicato e meno immediato, no (e devi conoscere anche il concetto di libreria)?

Se i dizionari/mappa/hash sono ormai presenti in tanti linguaggi "nativamente", è proprio perché si tratta di strutture molto utili e comunemente usate, che permettono di risolvere in maniera semplice ed elegante tanti problemi.

Tu non ci vedi differenza, ma anche didatticamente le due cose sono ben diverse (e con ciò mi riallaccio anche a quello che aveva scritto in precedenza DioBrando sull'argomento).

guarda, sarà comodo, niente da dire, ma non mi sono mai trovato a rimpiangerlo in java...

D3stroyer

04-10-2007, 13:58

scusate, vorrei fare una semplice domanda che mi sta turbando..e creare un topic per una risposta alla "si o no" non mi pare utile.

La domdanda è:

"tutto ciò che creo con c++, posso crearlo identico anche con java? E viceversa?"

cdimauro

04-10-2007, 14:08

Non sempre, ma per la stragrande maggioranza delle cose sì (e vale anche per Python e altri linguaggi dotati di virtual machine).

In sostanza viene esclusa la programmazione di sistema.

In realtà sono stati scritti anche dei sistemi operativi in Java, ma hanno bisogno di una virtual machine per girare.

A onor del vero anche i s.o. per eseguire lo startup hanno bisogno di un loader, anche minimale, ma scritto in assembly, che viene richiamato dal BIOS.
Quindi nemmeno linguaggi come C, C++, Pascal, Modula-2, ecc. (i più comunemente usati per scrivere s.o.) sono del tutto "indipendenti".

Accettando di allargare il concetto di loader, in teoria si potrebbe usare qualunque linguaggio di programmazione per scrivere un s.o., ma mi fermo qui perché rischiamo di impantanarci in discorsi troppo complicati.

variabilepippo

04-10-2007, 14:17

tutto ciò che creo con c++, posso crearlo identico anche con java? E viceversa?

Intendi in Java "puro"? In tal caso la risposta è negativa, tutta la programmazione "low-level" o non comunque non portabile Java deve delegarla a metodi scritti in codice nativo (vedi JNI).

D3stroyer

04-10-2007, 14:17

oke mi basta, ti ringrazio.

DioBrando

04-10-2007, 14:52

A me sembra che in queste discussioni stia un po' sfuggendo il quadro di insieme.
Ed il quadro di insieme ci dice che Java è diventato obsoleto e superato in diversi campi applicativi.

Negli anni 90, soprattutto la prima metà, è stato direi rivoluzionario con i suoi concetti, nella capacità di Sun di scorgere le potenzialità del World Wide Web prima degli altri e di approfittare del suo boom per veicolare la piattaforma Java nella quasi totalità dei computer (desktop) in giro per il mondo.
E forse è stato talmente tutto facile, senza reali competitor che potessero dare fastidio (la Microsoft ci ha provato con la celebre contesa della JVM non pienamente compatibile con gli standard Sun...ironia della sorte, la cessazione dello sviluppo della versione interna è stata la goccia che ha fatto traboccare il vaso e dato inizio al progetto .NET), che alla Sun si sono adagiati sugli allori, non vedendo come il Web del nuovo millennio ma soprattutto negli ultimi 3-4 anni stesse cambiando volto, con la definizione e proliferazione di nuovi standard o pseudo tali, con il cambiamento delle abitudini dei fruitori del Web (che sono diventati agenti attivi e non + solo passivi) e dei servizi che vi si appoggiano.

Si sono talmente seduti, che mentre nuovi linguaggi e metodologie di sviluppo prendevano piede (.NET, PHP, Python, Ruby...), il modello di Java e la sua architettura sono rimaste fondamentalmente sempre quelle, da quando Gosling e soci pubblicarono le prime specifiche.

E ora il ritardo tecnologico accumulato è evidente. Talmente evidente che negli ultimi mesi, dopo anni di silenzio, abbiamo assistito alla presentazione di
- la convergenza verso l'Open Source
- JAX-WS 2.0, JAXB 2.0, JAXP e STAX (tutte specifiche volte a colmare le "lacune" in ambito AJAX)
- JavaFX: linguaggio di scripting server-side
- Quaere, l'alter-ego di LinQ (progetto NET che ha ormai quasi 3 anni), che quindi dovrebbe permettere la modellazione OO di accesso ad una base di dati

Si è parlato anche di coerenza a proposito di Java.

Beh proviamo a vedere nel dettaglio alcuni casi in cui la coerenza è davvero lampante.

Cominciamo per esempio dalla (annosa) questione dell'ereditarietà multipla. All'inizio, sotto la spinta delle pompose dichiarazioni degli ingegneri Sun per cui la morale era "vi abbiamo dato un C++ privo dei suoi storici difetti", la scelta era stata +ttosto chiara: eliminarla alla radice, in modo tale da eliminare le situazioni in cui i benefici sono minori rispetto alle possibili situazioni di ambiguità (esempio tipico, il "diamond problem").
Chiaro, lineare, coerente con i principi di progettazione seguiti per edificare Java.
(non sto qui a discutere sul fatto che molti teorici affermano come un modello OO si possa definire compiuto solo se si utilizzi anche il concetto di ereditarietà multipla...le correnti sono diverse e spesso è difficile arrivare ad un'unica posizione di sintesi)
Poi però, si decide di farla rientra dal seminterrato, con l'uso delle interfacce; e questa scelta comporta due ordini di problemi, il primo, che l'ereditarietà multipla in questo modo, viene supportata solo parzialmente, il secondo, che vi è una frattura tra il modello concettuale fino a quel momento proposto e quello che in realtà è possibile realizzare con gli strumenti forniti dal linguaggio.

A questo punto la comunità si divide e chiede maggior chiarezza a proposito. La Sun continua a perseguire la stessa strada, se mi consentite il termine "ambigua". Questo fino all'avvento di Mustang (Java 6) in cui una delle novità sembrava potesse essere proprio questa: niente da fare.
Ora si parla di una prossima release e io sono curioso di vedere nono solo il quando ma soprattutto il COME verrà implementata, dato che stravolgerebbe il modello di gerarchie utilizzato fino ad adesso.
E quindi vi sarebbe la forzata necessità di ripensare dal profondo l'architettura del linguaggio, oltre a parte di una delle strutture semantiche utilizzate.

Un altro esempio di coerenza.
Quando ancora Sun era un ago della bilancia nel settore informatico sia HW che SW ed i suoi settori di R&D lavoravano a pieno regime, l'ipotesi che Sun potesse rilasciare con licenza Open Source, Java era impensabile.
Non solo era impensabile, ma Sun stessa era stata molto esplicita sulla necessità di mantenere le redini dello sviluppo del core e all'inizio anche dei progetti satellite correlati.
In meno di un anno, cambia tutto, Java diventa Open Source, con l'ambiguità di rilasciare le versioni Business attraverso le tradizionali licenze commerciale e di permettere però al tempo stesso fork di varia natura.

Il motivo di questo cambio repentino di vedute?
Opportunità.
L'hype spropositato che si è generato in questi anni e che ha dato vita a falsi miti ( del calibro de "Java è portabile", "Java è multipiattaforma", "Java ha rimosso i difetti di C++ e quindi è virtualmente immune da difetti", oppure "la decadenza prestazionale, seppur sia un linguaggio interpretato, è ininfluente, rispetto ai benefici"), è scemato e gli sviluppatori, sia freelance che in seno alle aziende, hanno fatto scelte oculate che tenessero conto del rapporto costi/benefici, nel caso di un utilizzo della piattaforma Java.
La Sun quindi ha visto nella transizione verso la GPL la possibilità di usufruire della comunità Open Source affinchè venisse dato nuovo lustro e una nuova spinta di interesse, in grado di contrastare le carenze tecnologiche di cui ho parlato poc'anzi.

Il problema, come sempre in questi casi, è che quando una transizione viene effettuata in fretta e furia, c'è il rischio che i cambiamenti radicali che questa comporta, non vengano assimilati e che il linguaggio non sia sviluppato + secondo una logica unitaria, ma a seconda di "come tira il vento". (come appunto l'estensione di funzionalità tramite la semplice aggiunta di nuove librerie, per esempio nel caso dei dizionari)

Ed è il motivo per cui grandi progetti Open Source, per quanto pubblicizzati, si dimostrino inferiori ad altri, magari di + basso profilo, ma con dinamiche di progettazione e evoluzione ormai consolidate nel tempo (chissà perchè mi viene sempre in mente l'esempio di MySQL VS PostGRES).

mindwings

04-10-2007, 18:05

... cut
A quale elemento della prospettiva procedurale corrisponderebbe mai la classe?
... cut

Al record :) ( Pascal )
Classe == Astrazione Dati (oltre che all' astrazione funzionale)
che nel C è assente bisogna arrivare alla programmazione OOP per avere la benedetta astrazione dati .
Edit: Aggiungo che Wirth qualcosa l'aveva già intuita ma in tempi non maturi[congettura mia] (riguardante l'OOP).
il titolo di una suo opera famosa è "Algorithms + Data Structures = Programs" . L'astrazione funzionale permette di ampliare l'insieme dei modi di operare sui dati cioè gli operatori sui tipi di dati già disponibili ; mentre l'astrazione dei dati permette di ampliare i tipi di dati disponibili attraverso l'introduzione sia di nuovi tipi di dato che di nuovi operatori (metodi).[completa l'opera insomma :D]

Imho per imparare a programmare è necessario partire dalla OOP :D dato che è un evoluzione naturale della procedural-way.
Io sono sempre per iniziare con Java e un buon manuale :)

PGI-Bis

04-10-2007, 19:08

Il record non è un elemento della prospettiva procedurale. Almeno non secondo la definizione di Nygaard.

DioBrando

06-10-2007, 14:38

un corso che si chiama FONDAMENTI dove lo inseriresti?

Partiamo dal presupposto che , per quanto tu lo scriva un maiuscolo, il nome del corso non è sempre un'indicazione precisa di quel che poi studierai nel dettaglio.
Se io dico per esempio Interazione Uomo-Macchina, si intuisce vagamente quale sarà il ramo trattato ma nello specifico non puoi sapere cosa ti spiegherà un professore...questo perchè la branca è talmente ampia e tocca così tanti ambiti scientifici per cui le ore di lezione non potranno mai esaurire l'argomento.
Le problematiche verranno affrontate secondo quale approccio? Psico-cognitivo, socio-culturale, tecnologico? Oppure tutti e 3? Se sì a quale dei 3 verrà dato + spazio?

Fatta questa precisazione, io non sono un docente e quindi non sono in grado di pianificare un intero corso di laurea (che poi dipende anche dalla scansione decisa a tavolino dall'Università: trimestrale, quadrimestrale o semestrale?).
Ma se c'è una cosa di cui sono sicuro è che non lo inserirei mai come primo esame di laurea; questo perchè in Fondamenti 1 vengono trattati argomenti come i modelli deterministici e non deterministici, le classi di complessità, il formalismo dei linguaggi.
Argomenti che non è possibile affrontare se prima non si dispone di una base solida di tipo logico-matematico.

E dato che l'Università si prefigge di insegnare e di formare persone indipendentemente dagli studi che queste hanno compiuto in precedenza, è giusto che si svolgano prima i corsi (e gli esami) che costruiscono la base di cui sopra.
Quindi, secondo me, prima di Fondamenti devono venire le matematiche fondamentali (analisi e matematica discreta), logica (se il corso di laurea la prevede), programmazione 1, architettura 1.
Prima o al massimo in contemporanea Algoritmi e Strutture Dati.

comunque un corso di informatica per studenti di ingegneria informatica cosa dovrebbe insegnare?

quello che si insegna in qualsiasi corso di ingegneria informatica?

quante ore di lezione secondo te dovrebbero passare prima di iniziare a introdurre i concetti di un linguaggio OO?

l'introduzione può avvenire fin da subito.
Ma un conto è la definizione e la presentazione, un altro conto è spiegare come questi concetti vengono utilizzati.

E a questo stadio non ci si arriva se prima non si studiano i mattoni fondamentali che ogni linguaggio utilizza e che sono le basi della programmazione, indipendentemente dal paradigma utilizzato.

guarda che tra il non spiegare nulla e lo spiegare tutto dall'inizio alla fine esistono molti livelli intermedi di approfondimento che possono dare una visione d'insieme lasciando gli approfondimenti ad un momento successivo... non mi pare che accennare al concetto di classe, oggetto, package, metodo sia traumatico... non capisco questo tuo stupore.
io trovo che un approccio serio alla didattica sia: ti do' la definizione degli strumenti che usi e da qui andiamo avanti...

Francamente, da quando hai tirato fuori per primo l'argomento (annotazione che personalmente ho trovato superflua perchè nessuno si è mai sognato di dire o di pensare che la pratica possa sostituire la teoria, quando si tratta di imparare a programmare...ma vabbè), ovvero dall'inizio dell'altro thread, ancora non si è capito quale sia secondo te l'approccio corretto.

Hai cominciato col dire che prima và insegnata la teoria e poi l'applicazione, che insieme alla scelta del linguaggio, è una fase secondaria.
Quando ti è stato fatto notare che questo metodo non funziona perchè uno studente dopo che si trova imbottito di nozioni senza applicarle, poi semplicemente perde interesse nella programmazione, e che il metodo + sensato è quello di procedere passo passo con piccoli esempi e la spiegazione teorica, hai detto che "era quello che intendevi".
Al che, ti ho risposto che se era questo il tuo pensiero, era una contraddizione: non potevi infatti affermare che la scelta del linguaggio fosse secondaria, perchè non sarebbe possibile poi far vedere come le strutture sintattiche interagiscano tra loro, senza scrivere del codice (in un X linguaggio).

Da lì silenzio.

Onde evitare ulteriori voli pindarici e formule general generiche e passando invece al concreto, che intendi con "definizione degli strumenti?"
Quali sono le nozioni che prima solo accenneresti e poi approfondiresti? E che significa per te accennare?
In parole povere, come costruiresti un corso di programmazione 1?

quando hai mostrato il

print "Hello"

che comprensione ne traggono gli studenti al di là del "ah... bello". quanto dura questa fase in cui vengono mostrate istruzioni specifiche invece di dare una visione generale e di alto livello che di sicuro è molto più utile ai fini dell'apprendimento (almeno quello serio)?

Non serve costruire un teorema e un percorso didattico (per altro io ho già espresso ampiamente quale sia la mia idea in proposito e come dovrebbe avvenire almeno all'inizio) su un semplicissimo stralcio di codice, il primo che di solito ogni studente di programmazione si trova a scrivere in vita sua.

Il confronto tra i due "Hello World" era mirato a far vedere come, mentre in Python, ci si può concentrare maggiormente sulla parte algoritmica perchè il linguaggio è sintetico ma ricco dal punto di vista espressivo, con Java invece, un principiante si trova a dover utilizzare PER FORZA costrutti di cui all'inizio non potrà capire lo scopo nè il come interagiscano tra loro.

Avrà un quadro generale di cosa sia la POO, conoscerà la definizione di classe, ma non sarà in grado di capire come si utilizza, come si istanzia, di cosa si compone, perchè gli mancano appunto le basi.

Quindi qual'è il senso di imbottire di concetti uno studente, se poi l'applicazione pratica seguirà una progressione differente?
Per me nessuno.

P.S.: non sapevo ci fosse anche un tipo di apprendimento poco serio a questo livello.
Dato che la spiegazione di cos'è un if non rientra necessariamente in un quadro di visione + ampio, ma può essere vista come la spiegazione di una semplice istruzione, anche questo secondo te è "apprendimento non serio"?

DioBrando

06-10-2007, 15:25

Mi ricollego al post fatto in precedenza focalizzandomi su quel che significa "ritardo tecnologico" e ciò che comporta per i programmatori che l'utilizzano al posto delle alternative che sn ormai giunte compiutamente alla ribalta del mondo informatico: il problema principale è nella produttività.

A questo proposito, ho trovato un interessante documento, che mette in luce proprio Python e Java e si focalizza esattamente sulla produttività.

Link (http://www.ferg.org/projects/python_java_side-by-side.html)

La comparazione viene fatta mettendo in luce sia le caratteristiche che contraddistinguono i 2 linguaggi e gli esempi di codice: praticamente lo stile che abbiamo adottato fino ad ora.

Sostanzialmente buona parte delle cose che troviamo scritte, sono già state trattate nelle pagine prima dei due thread:

concise (aka terse)
"expressing much in a few words. Implies clean-cut brevity, attained by excision of the superfluous"

compact

In The New Hacker's Dictionary, Eric S. Raymond gives the following definition for "compact":
Compact adj. Of a design, describes the valuable property that it can all be apprehended at once in one's head. This generally means the thing created from the design can be used with greater facility and fewer errors than an equivalent tool that is not compact.

Verbosity is not just a matter of increasing the number of characters that must be typed — it is also a matter of increasing the number of places where mistakes can be made. The Java code on the left has 5 control characters: ( ) { } ; where the corresponding Python code has only one control character, the colon. (Or two, if you count indentation. See below.)

questo a proposito del fatto che la quantità di codice scritto non è vero che è ininfluente ai fini del computo totale degli errori.

Technically, Python has another control character that Java does not — indentation. But the requirement for correct indentation is the same in Java as it is in Python, because in both languages correct indentation is a practical requirement for human-readable code. The Python interpreter automatically enforces correct indentation, whereas the Java compiler does not. With Java, you need an add-on product such as the Jalopy code formatter to provide automated enforcement of indentation standards.

L'indentazione forzata è un requisito necessario in Python che costringe chi scrive codice ad essere per forza chiaro (pena la non esecuzione corretta del programma). Negli altri linguaggi, Java compreso, è un requisito richiesto ma non necessario.
Per cui potremmo trovare, come spesso succede quando leggiamo codice scritto da altre persone, uno stile di indentazione diverso dal nostro, che non ci aiuta nella comprensione del codice.

Parallelamente c'è un'intervista in 3 parti con Bruce Eckel (che tutti immagino abbiate almeno sentito nominare) dove parla di Python e del perchè abbia deciso di switchare da Java, dopo averci lavorato praticamente da quando uscì sul mercato:

Parte I (http://www.artima.com/intv/aboutme.html)
Parte II (http://www.artima.com/intv/prodperf.html)
Parte III (http://www.artima.com/intv/typing.html)

I 10 punti enunciati si riferiscono al keynote realizzato qlc tempo prima e di cui potete trovare le slide qui (http://www.mindview.net/FAQ/FAQ-012). :)

Io non credo di essere nessuno ma quando personaggi con un minimo di autorevolezza parlano di "maggior compattezza" e di maggior "sintesi" dal punto di vista espressivo, può venire in mente che forse, dico forse, le idee che abbiamo scritto in precedenza e del perchè sia utile scegliere Python, non siano così campate in aria, anche perchè non ce le siamo inventate noi così di sana pianta, sono caratteristiche proprie del linguaggio, universalmente riconosciute.

Sempre sui ritardi tecnologici che ho menzionato all'inizio, sono convinto che questo si ripercuota non solo nella produttività ma anche nella didattica.
Perchè il requisito di scrivere del buon codice, di abituarsi al rigore e di poter assimilare in fretta i concetti teorici per poi poterli applicare, senza perdersi in dettagli non sempre così importanti, sono comuni a tutti e due gli ambiti.

Oltre alle due fonti citate in precedenza ecco quello che scrive Bertrand Meyer (http://www.eptacom.net/pubblicazioni/pub_it/meyer.html):

il C++ e Java mantengono la sintassi contorta del C. David Clark, dell'Università di Canberra, che ha insegnato usando sia Eiffel che Java, ha recentemente scritto a proposito della sua esperienza come segue:
"La mia esperienza ha provato che gli studenti non trovano Java facile da apprendere. Troppe volte il linguaggio è di intralcio a quello che voglio insegnare. [...] La prima cosa che gli studenti vedono è:
public static void main (String [ ] args) throws IOException
Ci sono circa sei differenti concetti in quella singola linea che gli studenti non sono ancora pronti ad imparare. [...] Il solo modo per leggere un numero dalla tastiera è di leggere una stringa e farne il parsing. Nuovamente, questo è qualcosa che disturba già dalla prima lezione. Java tratta i tipi di dato primitivi (int, char, boolean, float, long,...) in modo diverso dagli altri oggetti. [...] La mancanza dei generic1 significa essere costretti ad un casting continuo se si vogliono usare collezioni di elementi come Stack o Hashtable. Questi sono tutti ostacoli per gli studenti alle prime armi, e li distraggono dagli scopi principali del corso".
Questo è vero anche per i professionisti. Una delle ragioni del successo di Eiffel in grandi progetti industriali è che persone con ogni tipo di background - programmatori, ma anche funzionari di banca, commerciali, matematici, ingegneri, eccetera - possono apprenderlo bene e rapidamente, senza dover padroneggiare costrutti complicati e soggetti ad errori ereditati dal C.

In C++ e Java, come fatto notare da David Clark, i tipi base (interi e simili) sono al di fuori del type system degli oggetti. Questo impedisce di implementare un intero filone di pattern object oriented.

L'assenza dei generic in Java rende la programmazione più complessa e porta a serie inefficienze (come la necessità di riconoscere i tipi a run-time) e, peggio ancora, a mancanza di sicurezza, dal momento che è impossibile fare un completo type-checking statico. In altre parole: possibilità di crash a run-time. Questo è tutt'altro che un problema astratto che interessa i soli puristi.

I cast del C++ rendono la garbage collection impossibile. Il risultato: una gestione della memoria "manuale", il che significa tempi di sviluppo molto più lunghi (e spiega in parte perché il software è sviluppato più rapidamente in Eiffel), un lavoro tedioso e noioso per i programmatori, e peggio ancora numerosi bug nel software a causa di aree di memoria non reclamate e puntatori impazziti.

L'assenza dell'ereditarietà multipla in Java rende impossibile il corretto progetto di sistemi object oriented.

La lista delle concrete, spiacevoli conseguenze prosegue ancora. Non è una questione di purezza in sé, è una questione di costruire software più rapidamente e meglio - in altre parole, di guadagnare se lo si fa nel modo giusto, di perdere denaro altrimenti.

La prima parte sottolineata si riferisce a quel che continuo a sostenere proprio nell'ambito della didattica, quando si sceglie Java come strumento invece per esempio di Python e del fatto che si sia costretti a passare sopra certi argomenti, perchè gli studenti non sono in grado di comprenderli; non prima di aver posto le basi di un qualsiasi corso di programmazione.

La seconda sottolineatura si riferisce invece a quel che Cesare ha + volte sottolineato quando si parla di paradigma OO e della differenza che corre tra il modello proposto da Python e quello Java.

Infine vi è un'annotazione proprio sull'ereditarietà multipla a cui avevo accennato nel penultimo post, ovvero che è difficile pensare ad modello OO compiuto in un progetto Java quando l'ereditarietà multipla non viene consentita (se non attraverso il workaround delle interfacce), perchè aggiungo io, modellare l'universo con una gerarchia basata sull'eredità di un'unica classe, è complesso e spesso fin troppo riduttivo.

cdimauro

06-10-2007, 15:38

Un altro post da incorniciare però, dico io, ma proprio Eckel dovevi tirare in ballo?!? :muro: Adesso scatenerai la terza guerra mondiale!!! :D :D :D

PGI-Bis

06-10-2007, 16:50

Il verbo del programmatore: io dico, tu dici, egli motiva. Esempio:

concise (aka terse)
"expressing much in a few words. Implies clean-cut brevity, attained by excision of the superfluous"

Perchè è bene essere concisi? Non si sa.

Il pezzo citato del tizio di canberra lo salto a piè pari perchè non vale neppure la pena di commentarlo: qualcuno l'ha detta lunga sapendola corta. E non perchè alcuni dei problemi citati trovino una risposta nelle versioni più recenti di Java: perchè non sono problemi in sè.

Dico infine una cosa che è certamente nota a tutti ma sembra passare inosservata. Secondo la scuola scandinava, il "workaround delle interfacce" si chiama ereditarietà in senso proprio mentre il rapporto che sussiste tra due classi direttamente o indirettamente legate dalla clausola extends si chiama estensione o ereditarietà americana.

Quanto ai dieci punti di Eckel, be', via, cerchiamo di essere seri. I confusi libri di Eckel li abbiamo letti tutti.

cdimauro

06-10-2007, 17:53

Non ne ho mai letto uno, ma i 10 punti li trovo AMPIAMENTE condivisibili. :)
In particolare sulle checked exceptions: formalmente utili, ma che complicano enormemente la vita agli sviluppatori.

Sul fatto di essere coincisi, sono d'accordo con te, ma soltanto perché a mio avviso non basta: bisogna che il codice sia ANCHE chiaro.
Il perché, poi, sia utile è una questione legata puramente all'informazione, a mio avviso: più è lungo il codice più è facile che siano introdotti degli errori, e più è facile perdere di vista il problema che si cerca di risolvere.
Ci piazzo un bel IMHO, giusto per chiarire che si tratta di un mio pensiero. :D

Sul "tizio di Camberra" non so a cosa ti riferisci.

Mentre sull'ereditarietà, che l'approccio alla programmazione orientata agli oggetti "tradizionale" (ereditarierà singola, eventualmente condita con le interfacce) per cercare di modellare la realtà sia stata un fallimento, mi sembra che l'abbia detto anche tu. ;)

DioBrando

06-10-2007, 18:08

Il verbo del programmatore: io dico, tu dici, egli motiva. Esempio:

concise (aka terse)
"expressing much in a few words. Implies clean-cut brevity, attained by excision of the superfluous"

Perchè è bene essere concisi? Non si sa.

penso sia un bene come lo è in tutti gli altri campi di espressione linguistica (a parte la politica, dove + si fanno giri di parole senza dire niente e + si appare dotati di personalità e dialettica).
Se si è concisi, a patto come diceva Cesare di essere anche chiari, ci si focalizza sulle idee da esporre senza tanti fronzoli.

"Il dono della sintesi", così lo chiamano no? :)

Il pezzo citato del tizio di canberra lo salto a piè pari perchè non vale neppure la pena di commentarlo: qualcuno l'ha detta lunga sapendola corta. E non perchè alcuni dei problemi citati trovino una risposta nelle versioni più recenti di Java: perchè non sono problemi in sè.

Nelle versioni successive il problema di presentare, in un pezzo di codice banale qual'è un HelloWorld, strutture che vengono accantonate temporaneamente, mi pare rimanga.
E sarà sempre così a meno che Java non diventi un'altra cosa, che non sia Java.

E questo nella didattica, come ho avuto modo di scrivere + volte, non credo sia il massimo per chi ha voglia di addentrarsi nella programmazione.

Dico infine una cosa che è certamente nota a tutti ma sembra passare inosservata. Secondo la scuola scandinava, il "workaround delle interfacce" si chiama ereditarietà in senso proprio mentre il rapporto che sussiste tra due classi direttamente o indirettamente legate dalla clausola extends si chiama estensione o ereditarietà americana.

Stroustrup lo includiamo nella scuola scandinava?
Perchè non mi risulta sia concorde con questa classificazione.

Quanto ai dieci punti di Eckel, be', via, cerchiamo di essere seri. I confusi libri di Eckel li abbiamo letti tutti.

Al di là del fatto che trovo i punti + che condivisibili, non mi pare i suoi libri siano così confusi.
Thinkin' in Java l'ho trovato un buon libro e non meno "confuso" dei tanti che trattano il medesimo argomento.

Cmq sarei ben felice di trovarne di meglio, chessò magari scritti di tuo pugno, così da poter constatare le differenze.

Il migliore che trattasse Java e l'OO, con un taglio indirizzato al principiante o quasi, è Programmare con Java (http://bol.it/libri/scheda/ea978888233566.html); anche perchè è l'unico che ho incontrato il quale, seppur redatto da evangelist, non maschera i falsi miti che hanno circondato questo linguaggio e questa piattaforma fin dalla sua nascita.

Un livello di criticità che è merce rara di questi tempi. IMHO naturalmente.

cdimauro

06-10-2007, 18:22

DioBrando

06-10-2007, 18:48

sì è quel che ripetiamo + o - dall'inizio.
Se si possono trascurare maggiormente i dettagli implementativi e concentrarsi sulla risoluzione del problema, si guadagna in produttività. (e dato che alcuni requisiti poi vengono mutuati anche in ambito accademico, e viceversa, Python risulta una buona scelta anche come strumento in un corso di programmazione)

L'articolista del primo link parla di un aumento di 5 volte tanto.
Ora, io non saprei quantificare, anche perchè occorrerebbe una statistica non basata sull'esperienza di una sola persona, però il fatto IMO resta.

E sintesi non vuol dire povertà dal punto di vista della semantica: questo è un punto importante.

"pseudocodice eseguibile" è carina, non l'avevo mai sentita.
Opera tua o presa in prestito? :D

cdimauro

06-10-2007, 18:57

DioBrando

06-10-2007, 19:10

Presa in prestito, ma non ricordo chi e dove l'ho letta. Comunque il malefico Eckel ne parla qui http://www.artima.com/intv/tipping3.html pure lui. :p

Sulla produttività aumentata di 5 volte (e più), per la MIA esperienza posso confermare. ;)

Non sò se l'hai letta lì per la prima volta, ma Alex Martelli, lo sviluppatore che avevo citato in precedenza ( e di cui hai letto anche tu il "modesto" curriculum") ne parla proprio in questi termini:

Link (http://sra.itc.it/people/olivetti/python/alex_martelli-5.html)

Python � praticamente pseudo-codice eseguibile ;)

Tra () il libro citato da Eckel, Programming in Python è un buon libro a riguardo. Forse non proprio adatto per i principianti, ma decisamente un buon libro.

cdimauro

06-10-2007, 19:17

No, non l'ho letta lì (peccato per i caratteri accentati che sono sballati, perché quella guida di Martelli mi sembra piuttosto semplice e concisa), ma in qualche articolo (in inglese) che m'è capitato tempo fa.

Programming in Python non lo conosco.

mad_hhatter

06-10-2007, 22:14

[...]

l'arroganza che poni in alcune delle tue frasi comincia un po' a infastidirmi, francamente.
cio' premesso, e' abbastanza evidente che usiamo gli stessi termini riferendoci a cose sufficientemente diverse... per te fondamenti1 indica qualcosa che non corrisponde al corso di cui io sto parlando e che contiene, invece, un'introduzione alla programmazione, alle strutture di dati, alla teoria della complessita' algoritmica. In questo percorso lo studente inizia a familiarizzare con i concetti di variabile, istruzione, ecc applicati al linguaggio assembly in modo da vedere le interazioni con l'hardware sottostante e avere una idea semplificata di quale sia lo scopo di un compilatore. Acquisiti questi rudimenti, allo studente viene presentata la programamzione OO con una definizione semplice e intuitiva dei concetti fondamentali di oggetto, classe, interfaccia, ecc...
a me non pare che, per fare un paragone, al corso di analisi1 il professore prima di introdurre le funzioni faccia giocare gli studenti con le 4 operazioni... al contrario fornisce la definizione rigorosa del concetto di numero, di operatore, ecc... e questo non mi pare sconvolgente, ma anzi molto importante per gettare le fondamenta che reggono l'intera impalcatura del corso.

tu dici: "l'introduzione può avvenire fin da subito.
Ma un conto è la definizione e la presentazione, un altro conto è spiegare come questi concetti vengono utilizzati."

ti rispondo, molto semplicemente, che anche la spiegazione del loro uso puo' passare per vari gradi di approfondimento, non vedo dove stia il problema, ad esempio, nell'accennare un paio di esempi d'uso di un modificatore di accesso senza per forza presentare l'intero impianto normativo che ne sta alla base.

poi continui dicendo: "annotazione che personalmente ho trovato superflua perchè nessuno si è mai sognato di dire o di pensare che la pratica possa sostituire la teoria, quando si tratta di imparare a programmare..."

ti rispondo, tralasciando il tono da te usato, che non e' per niente superflua come annotazione perche' non esiste un modo univoco di suddivedere e dosare teoria e pratica... e' infatto possibile che persone diverse diano un connotato diverso alla parola "teoria".

continuando, dici:
"Hai cominciato col dire che prima và insegnata la teoria e poi l'applicazione, che insieme alla scelta del linguaggio, è una fase secondaria.
Quando ti è stato fatto notare che questo metodo non funziona perchè uno studente dopo che si trova imbottito di nozioni senza applicarle, poi semplicemente perde interesse nella programmazione, e che il metodo + sensato è quello di procedere passo passo con piccoli esempi e la spiegazione teorica, hai detto che "era quello che intendevi".
Al che, ti ho risposto che se era questo il tuo pensiero, era una contraddizione: non potevi infatti affermare che la scelta del linguaggio fosse secondaria, perchè non sarebbe possibile poi far vedere come le strutture sintattiche interagiscano tra loro, senza scrivere del codice (in un X linguaggio)."

ti faccio notare che per mettere in pratica i concetti esposti in un corso di introduzione alla programmazione un qualunque linguaggio va bene perche' non e' il linguaggio in se' l'oggetto della didattica. quindi non esiste contraddizione nel dire che la teoria risulta piu' efficacie se accompagnata da qualche esercizio e contemporaneamente che il linguaggio adottato per costruire gli esempi e' una questione secondaria (posto che il linguaggio sia adatto allo scopo).

infine, scrivi:
"Il confronto tra i due "Hello World" era mirato a far vedere come, mentre in Python, ci si può concentrare maggiormente sulla parte algoritmica perchè il linguaggio è sintetico ma ricco dal punto di vista espressivo, con Java invece, un principiante si trova a dover utilizzare PER FORZA costrutti di cui all'inizio non potrà capire lo scopo nè il come interagiscano tra loro.

Avrà un quadro generale di cosa sia la POO, conoscerà la definizione di classe, ma non sarà in grado di capire come si utilizza, come si istanzia, di cosa si compone, perchè gli mancano appunto le basi.

Quindi qual'è il senso di imbottire di concetti uno studente, se poi l'applicazione pratica seguirà una progressione differente?
Per me nessuno."

io ripeto che nella definizione di oggetto, classe, ecc non vedo nulla di trascendentale per uno studente universitario di una facolta' di informatica... tant'e' che dopo l'Hello World ci e' stato presentato un piccolo esempio, molto semplice, ma molto formativo, di oggetto, di interazione tra oggetti, ecc... e ripeto che la cosa non ha suscitato il minimo scandandalo negli studenti...

e' evidente che chi VUOLE conoscere a fondo come funzionano le cose non si spaventa per certe cose anzi, ne e' avido e non vuole dolcificanti sintattici perche' non gli interessa la produttivita', gli interessa la conoscenza scientifica degli oggetti che gli vengono presentati

D3stroyer

06-10-2007, 22:25

beh, io da studente a c++ capito, ora sto facendo fatica a capire come far dire "hello world" a java :cry:

cdimauro

06-10-2007, 22:31

l'arroganza che poni in alcune delle tue frasi comincia un po' a infastidirmi, francamente.
cio' premesso, e' abbastanza evidente che usiamo gli stessi termini riferendoci a cose sufficientemente diverse... per te fondamenti1 indica qualcosa che non corrisponde al corso di cui io sto parlando e che contiene, invece, un'introduzione alla programmazione, alle strutture di dati, alla teoria della complessita' algoritmica. In questo percorso lo studente inizia a familiarizzare con i concetti di variabile, istruzione, ecc applicati al linguaggio assembly in modo da vedere le interazioni con l'hardware sottostante e avere una idea semplificata di quale sia lo scopo di un compilatore. Acquisiti questi rudimenti, allo studente viene presentata la programamzione OO con una definizione semplice e intuitiva dei concetti fondamentali di oggetto, classe, interfaccia, ecc...
a me non pare che, per fare un paragone, al corso di analisi1 il professore prima di introdurre le funzioni faccia giocare gli studenti con le 4 operazioni... al contrario fornisce la definizione rigorosa del concetto di numero, di operatore, ecc... e questo non mi pare sconvolgente, ma anzi molto importante per gettare le fondamenta che reggono l'intera impalcatura del corso.

tu dici: "l'introduzione può avvenire fin da subito.
Ma un conto è la definizione e la presentazione, un altro conto è spiegare come questi concetti vengono utilizzati."

ti rispondo, molto semplicemente, che anche la spiegazione del loro uso puo' passare per vari gradi di approfondimento, non vedo dove stia il problema, ad esempio, nell'accennare un paio di esempi d'uso di un modificatore di accesso senza per forza presentare l'intero impianto normativo che ne sta alla base.

poi continui dicendo: "annotazione che personalmente ho trovato superflua perchè nessuno si è mai sognato di dire o di pensare che la pratica possa sostituire la teoria, quando si tratta di imparare a programmare..."

ti rispondo, tralasciando il tono da te usato, che non e' per niente superflua come annotazione perche' non esiste un modo univoco di suddivedere e dosare teoria e pratica... e' infatto possibile che persone diverse diano un connotato diverso alla parola "teoria".

continuando, dici:
"Hai cominciato col dire che prima và insegnata la teoria e poi l'applicazione, che insieme alla scelta del linguaggio, è una fase secondaria.
Quando ti è stato fatto notare che questo metodo non funziona perchè uno studente dopo che si trova imbottito di nozioni senza applicarle, poi semplicemente perde interesse nella programmazione, e che il metodo + sensato è quello di procedere passo passo con piccoli esempi e la spiegazione teorica, hai detto che "era quello che intendevi".
Al che, ti ho risposto che se era questo il tuo pensiero, era una contraddizione: non potevi infatti affermare che la scelta del linguaggio fosse secondaria, perchè non sarebbe possibile poi far vedere come le strutture sintattiche interagiscano tra loro, senza scrivere del codice (in un X linguaggio)."

ti faccio notare che per mettere in pratica i concetti esposti in un corso di introduzione alla programmazione un qualunque linguaggio va bene perche' non e' il linguaggio in se' l'oggetto della didattica. quindi non esiste contraddizione nel dire che la teoria risulta piu' efficacie se accompagnata da qualche esercizio e contemporaneamente che il linguaggio adottato per costruire gli esempi e' una questione secondaria (posto che il linguaggio sia adatto allo scopo).

infine, scrivi:
"Il confronto tra i due "Hello World" era mirato a far vedere come, mentre in Python, ci si può concentrare maggiormente sulla parte algoritmica perchè il linguaggio è sintetico ma ricco dal punto di vista espressivo, con Java invece, un principiante si trova a dover utilizzare PER FORZA costrutti di cui all'inizio non potrà capire lo scopo nè il come interagiscano tra loro.

Avrà un quadro generale di cosa sia la POO, conoscerà la definizione di classe, ma non sarà in grado di capire come si utilizza, come si istanzia, di cosa si compone, perchè gli mancano appunto le basi.

Quindi qual'è il senso di imbottire di concetti uno studente, se poi l'applicazione pratica seguirà una progressione differente?
Per me nessuno."

io ripeto che nella definizione di oggetto, classe, ecc non vedo nulla di trascendentale per uno studente universitario di una facolta' di informatica... tant'e' che dopo l'Hello World ci e' stato presentato un piccolo esempio, molto semplice, ma molto formativo, di oggetto, di interazione tra oggetti, ecc... e ripeto che la cosa non ha suscitato il minimo scandandalo negli studenti...

e' evidente che chi VUOLE conoscere a fondo come funzionano le cose non si spaventa per certe cose anzi, ne e' avido e non vuole dolcificanti sintattici perche' non gli interessa la produttivita', gli interessa la conoscenza scientifica degli oggetti che gli vengono presentati
Se qualunque linguaggio va bene per la didattica, allora si può benissimo partire dal linguaggio macchina e quindi dalle tabelle degli opcode.

Nel momento in cui lo scopo è la didattica, il linguaggio NON può essere di secondaria importanza, perché è chiaro che condiziona, anche pesantemente, i concetti da apprendere e modifica la curva di apprendimento.

EDIT: quotato messaggio di mad_hhatter.

cdimauro

06-10-2007, 22:33

beh, io da studente a c++ capito, ora sto facendo fatica a capire come far dire "hello world" a java :cry:
E' evidente che, pur essendo partito da un linguaggio di più basso livello qual è il C++, è colpa tua che non vuoi conoscere a fondo come funzionano le cose (in Java) e ne hai paura... :D

E mi scandalizzo pure per la tua incapacità a comprendere una cosa banale come un "hello, world" in Java. :D :D :D

mad_hhatter

06-10-2007, 22:37

Se qualunque linguaggio va bene per la didattica, allora si può benissimo partire dal linguaggio macchina e quindi dalle tabelle degli opcode.

Nel momento in cui lo scopo è la didattica, il linguaggio NON può essere di secondaria importanza, perché è chiaro che condiziona, anche pesantemente, i concetti da apprendere e modifica la curva di apprendimento.

questi commenti sono privi di senso, in quanto ho espressamente detto che il linguaggio deve comunque assere adatto allo scopo che ci si prefigge... cosi', per esempio, mentre per il concetto di istruzione e di variabile va bene anche soltanto l'assemply, per una didattica che si occupi di OOp non si puo' non adottare un linguaggio OO...

mad_hhatter

06-10-2007, 22:38

E' evidente che, pur essendo partito da un linguaggio di più basso livello qual è il C++, è colpa tua che non vuoi conoscere a fondo come funzionano le cose (in Java) e ne hai paura... :D

E mi scandalizzo pure per la tua incapacità a comprendere una cosa banale come un "hello, world" in Java. :D :D :D

il tuo sarcasmo e' completamente fuori luogo.

in nessun post ho mai affermato che il fatto che la scelta del linguaggio a supporto della didattica sia secondaria significhi che, imparato un qualunque linguaggio, si sia in grado di passare a qualsiasi altro linguaggio in quattro e quattr'otto

mad_hhatter

06-10-2007, 22:39

beh, io da studente a c++ capito, ora sto facendo fatica a capire come far dire "hello world" a java :cry:

il fatto di conoscere un linguaggio non implica che l'utilizzo di un qualsiasi altro linguaggio sia semplice e immediato

cdimauro

06-10-2007, 22:44

questi commenti sono privi di senso, in quanto ho espressamente detto che il linguaggio deve comunque assere adatto allo scopo che ci si prefigge... cosi', per esempio, mentre per il concetto di istruzione e di variabile va bene anche soltanto l'assemply, per una didattica che si occupi di OOp non si puo' non adottare un linguaggio OO...
Quindi posso assumere che per imparare la programmazione strutturata vada benissimo il linguaggio macchina, per quella funzionale il LISP, e per quella OOP PERL?

cdimauro

06-10-2007, 22:46

il tuo sarcasmo e' completamente fuori luogo.
Non è affatto fuori luogo: ho semplicemente applicato i concetti che hai espresso al messaggio di D3stroyer.
in nessun post ho mai affermato che il fatto che la scelta del linguaggio a supporto della didattica sia secondaria significhi che, imparato un qualunque linguaggio, si sia in grado di passare a qualsiasi altro linguaggio in quattro e quattr'otto
Hai posto dei vincoli precisi:

"e' evidente che chi VUOLE conoscere a fondo come funzionano le cose non si spaventa per certe cose" ecc. ecc.

per cui è evidente che D3stroyer NON vi rientri. Sarcasmo o non sarcasmo, questa è banale logica.

mad_hhatter

06-10-2007, 22:50

Quindi posso assumere che per imparare la programmazione strutturata vada benissimo il linguaggio macchina, per quella funzionale il LISP, e per quella OOP PERL?

non lo so, dipende dal tuo scopo

cdimauro

06-10-2007, 22:51

non lo so, dipende dal tuo scopo
L'avevamo già detto: lo scopo è la didattica.

mad_hhatter

06-10-2007, 22:52

Non è affatto fuori luogo: ho semplicemente applicato i concetti che hai espresso al messaggio di D3stroyer.

Hai posto dei vincoli precisi:

"e' evidente che chi VUOLE conoscere a fondo come funzionano le cose non si spaventa per certe cose" ecc. ecc.

per cui è evidente che D3stroyer NON vi rientri. Sarcasmo o non sarcasmo, questa è banale logica.

ti invito a leggere la mia risposa a D3stroyer.

la tua non e' banale logica, e' logica banale e semplicistica atta travisare volutamente il mio pensiero

cdimauro

06-10-2007, 22:56

ti invito a leggere la mia risposa a D3stroyer.
Non m'interessa. M'interessa invece mettere in relazione il tuo precedente messaggio e il seguente messaggio di D3stroyer.
la tua non e' banale logica, e' logica banale e semplicistica atta travisare volutamente il mio pensiero
Nessuna travisazione: è nero su bianco quello che hai scritto tu e quello che ha scritto D3stroyer, e io mi sono semplicemente limitato ad applicare i concetti che hai espresso alla situazione di quest'ultimo.

Comunque puoi sempre editare il tuo precedente messaggio e scriverlo in forma diversa, se pensi che sia "travisabile". In tal caso lo riesaminerò ed eventualmente correggerò quello che ho scritto, se fosse necessario.

Per adesso mi limito a inglobare il tuo messaggio nella mia precedente risposta, cosicché non se ne perda traccia.

mad_hhatter

06-10-2007, 22:57

L'avevamo già detto: lo scopo è la didattica.

non fare il sofista, la didattica assume molte forme a seconda di cosa si vuol comunicare...

continuo a pensare che questi tuoi post fatti solo per punzecchiare sia insensati e fuori luogo

mad_hhatter

06-10-2007, 22:59

Non m'interessa. M'interessa invece mettere in relazione il tuo precedente messaggio e il seguente messaggio di D3stroyer.

Nessuna travisazione: è nero su bianco quello che hai scritto tu e quello che ha scritto D3stroyer, e io mi sono semplicemente limitato ad applicare i concetti che hai espresso alla situazione di quest'ultimo.

Comunque puoi sempre editare il tuo precedente messaggio e scriverlo in forma diversa, se pensi che sia "travisabile". In tal caso lo riesaminerò ed eventualmente correggerò quello che ho scritto, se fosse necessario.

Per adesso mi limito a inglobare il tuo messaggio nella mia precedente risposta, cosicché non se ne perda traccia.

non t'interessa? starno visto che metteva in relazione i discorsi di cui stai parlando tu... ne deduco quindi non ti interessa la discussione, vuoi solo punzecchiare, bene complimenti...

non ho niente da riscrivere, scendi dalla cattedra

cdimauro

06-10-2007, 23:02

non fare il sofista, la didattica assume molte forme a seconda di cosa si vuol comunicare...
L'argomento da cui è partito il tutto è IMPARARE a programmare.
continuo a pensare che questi tuoi post fatti solo per punzecchiare sia insensati e fuori luogo
Io continuo a pensare che o fai finta di dimenticare quello di cui abbiamo parlato finora, oppure cerchi malamente di cambiare discorso e di fare la vittima.

In entrambi i casi sappi che con me non attacca.

Se ti sei stancato o ti sei cacciato in una discussione da cui ti risulta difficile uscirtene fuori, è sufficiente non continuare a scrivere per lasciar perdere dignitosamente.

cdimauro

06-10-2007, 23:07

non t'interessa? starno visto che metteva in relazione i discorsi di cui stai parlando tu...
Diciamo che volevi metterci una pezza invece, dopo aver notato l'uso che avevo fatto delle tue parole.
ne deduco quindi non ti interessa la discussione, vuoi solo punzecchiare, bene complimenti...
No, voglio solo evidenziare come quello che dici mal si concilia con ciò che accade nel mondo reale.
non ho niente da riscrivere, scendi dalla cattedra
Quindi confermi parola per parola quello che hai scritto? In tal caso, idem: non cambio di una virgola l'uso che ho fatto di quel che hai scritto.

Giudicheranno gli altri la consistenza o meno delle mie parole.

Eh, no, non scendo affatto dalla cattedra: per quanto mi riguarda ci sto benissimo.

mad_hhatter

06-10-2007, 23:08

L'argomento da cui è partito il tutto è IMPARARE a programmare.

Io continuo a pensare che o fai finta di dimenticare quello di cui abbiamo parlato finora, oppure cerchi malamente di cambiare discorso e di fare la vittima.

In entrambi i casi sappi che con me non attacca.

Se ti sei stancato o ti sei cacciato in una discussione da cui ti risulta difficile uscirtene fuori, è sufficiente non continuare a scrivere per lasciar perdere dignitosamente.

stai oltrepassando i limiti dell'educazione.

spiegami di cosa mi starei dimenticando o da cosa starei cercand di sgattaiolare...

tra l'altro, ho notato che hai editato uno degli ultimi post quotando il post che mi invitavi a riscrivere... cos'e', volevi tenere una copia nel caso avessi cercato di ritrattare? per chi mi hai preso? ho gia' detto che non ho nulla da riscrivere, quello che c'e' scritto rimarra' cosi' com'e'.

mad_hhatter

06-10-2007, 23:12

Giudicheranno gli altri la consistenza o meno delle mie parole.

Eh, no, non scendo affatto dalla cattedra: per quanto mi riguarda ci sto benissimo.

ho notato, soprattutto vista la tua arroganza... se devi appigliarti a questi modi di fare per sopperire alla mancanza di argomentazioni migliori forse sei tu che dovresti -cito- "lasciar perdere dignitosamente"

cdimauro

06-10-2007, 23:14

stai oltrepassando i limiti dell'educazione.
E tu della logica.
spiegami di cosa mi starei dimenticando o da cosa starei cercand di sgattaiolare...
Te l'ho già spiegato: è sufficiente leggere.
tra l'altro, ho notato che hai editato uno degli ultimi post quotando il post che mi invitavi a riscrivere...
Hai notato? Ma se te l'avevo pure scritto: http://www.hwupgrade.it/forum/showpost.php?p=19034511&postcount=83

"Per adesso mi limito a inglobare il tuo messaggio nella mia precedente risposta, cosicché non se ne perda traccia."

Questo a testimonianza che dovresti leggere meglio i messaggi dei tuoi interlocutori.
cos'e', volevi tenere una copia nel caso avessi cercato di ritrattare?
Esattamente.
per chi mi hai preso?
C'è tante gente che circola in rete, per cui è sempre meglio tutelarsi.
ho gia' detto che non ho nulla da riscrivere, quello che c'e' scritto rimarra' cosi' com'e'.
Non c'è problema allora: giudicheranno gli altri se ho fatto bene o no ad applicare ciò che avevi scritto al messaggio di D3stroyer.

D3stroyer

06-10-2007, 23:15

ma voi che lavoro fate? hhatter mi pare un professore e cdimauro un suo collega :asd:

plz ditemelo è troppo divertente.

mad_hhatter

06-10-2007, 23:17

Diciamo che volevi metterci una pezza invece, dopo aver notato l'uso che avevo fatto delle tue parole.

nessuna pezza, anzi, anche perche' l'uso che ne hai fatto era palesemente tendenzioso! ripeto, leggi la mia risposta, sempreche' tu sia interessato alla discussione e non soltanto agli insulti.

per quanto mi riguarda rispondero' solo a post che non abbiano il solo scopo di fare polemica fine a se stessa: penso siamo gia' andati al limite del regolamento

cdimauro

06-10-2007, 23:20

ho notato, soprattutto vista la tua arroganza...
Adesso non fare la povera vittima. Prima stuzzichi la gente: http://www.hwupgrade.it/forum/showpost.php?p=19034391&postcount=75

"questi commenti sono privi di senso"

quando dal mio messaggio non traspariva proprio nulla di offensivo, e poi mi vieni a parlare di arroganza, educazione, ecc. :rolleyes:
se devi appigliarti a questi modi di fare per sopperire alla mancanza di argomentazioni migliori forse sei tu che dovresti -cito- "lasciar perdere dignitosamente"
Se c'è una cosa che non manca nei miei messaggi è la quantità e qualità delle argomentazioni, e a differenza di te non mi sono mai tirato indietro per sostenere le mie tesi: basti vedere tutti i messaggi che ci siamo scambiati per rendersi conto chi è fra noi due che preferisce lasciar cadere discorsi e far mancare la propria opinione.:mc:

D3stroyer

06-10-2007, 23:23

non me lo dite eh :read:

mad_hhatter

06-10-2007, 23:23

C'è tante gente che circola in rete, per cui è sempre meglio tutelarsi.

ti ringrazio per il rispetto e l'alta considerazione che hai di me :rolleyes:

a differenza di te io non assumo di avere ragione e di possedere la verita' assoluta... io esprimo il mio pensiero e resto aperto alla possibilita' che qualcuno la pensi diversamente da me... se poi mi si convince che sbaglio non ho problemi a cambiare idea e ad ammetterlo... non vedo nessun problema in questo.

non accetto pero' che mi si manchi di rispetto.

cdimauro

06-10-2007, 23:25

nessuna pezza, anzi, anche perche' l'uso che ne hai fatto era palesemente tendenzioso!
Ho soltanto applicato quello che hai scritto. Né più né meno.
ripeto, leggi la mia risposta,
L'ho letta e mal si concilia con quello che hai scritto prima.
sempreche' tu sia interessato alla discussione e non soltanto agli insulti.
Se non fossi interessato non sarei qui a scrivere a mezzanotte anziché stare a letto a ronfare.

Quanto agli insulti, li stai tirando fuori tu e dovresti dimostrarmelo, cortesemente.
per quanto mi riguarda rispondero' solo a post che non abbiano il solo scopo di fare polemica fine a se stessa: penso siamo gia' andati al limite del regolamento
Allora fai una cosa: la prossima volta diglielo a un altro che scrive cose prive di senso, ok? Sta sicuro che se ti comporti educatamente, come vorresti anche tu, gli altri faranno altrettanto con te.

mad_hhatter

06-10-2007, 23:26

Ahttp://www.hwupgrade.it/forum/showpost.php?p=19034391&postcount=75

quando dal mio messaggio non traspariva proprio nulla di offensivo

a me il tuo messaggio era parso invece polemicamente sarcastico

cdimauro

06-10-2007, 23:30

ti ringrazio per il rispetto e l'alta considerazione che hai di me :rolleyes:
Non ci conosciamo, per cui preferisco tutelarmi, visti anche i precedenti in questo forum (non ho scritto 13 mila messaggi per niente: è da un pezzo che lo frequento e ne ho viste di tutti i colori).
a differenza di te io non assumo di avere ragione e di possedere la verita' assoluta... io esprimo il mio pensiero e resto aperto alla possibilita' che qualcuno la pensi diversamente da me... se poi mi si convince che sbaglio non ho problemi a cambiare idea e ad ammetterlo... non vedo nessun problema in questo.
Non mi pare proprio:

"e' evidente che chi VUOLE conoscere a fondo come funzionano le cose non si spaventa per certe cose anzi, ne e' avido e non vuole dolcificanti sintattici perche' non gli interessa la produttivita', gli interessa la conoscenza scientifica degli oggetti che gli vengono presentati"

"beh, io da studente a c++ capito, ora sto facendo fatica a capire come far dire "hello world" a java "

"il fatto di conoscere un linguaggio non implica che l'utilizzo di un qualsiasi altro linguaggio sia semplice e immediato"
non accetto pero' che mi si manchi di rispetto.
Impara prima tu a rispettare gli altri, e vedrai che faranno altrettanto.

mad_hhatter

06-10-2007, 23:32

come ha fatto notare D3stroyer stiamo scadendo nel ridicolo... direi di rientrare in topic... sei d'accordo? io poi chiedo una sospensione per sopraggiunti limiti d'orario :D

D3stroyer

06-10-2007, 23:33

la mia domanda era seria però..mi avete snobbato..e io a refreshare pure :(

cdimauro

06-10-2007, 23:33

a me il tuo messaggio era parso invece polemicamente sarcastico
T'è parso male: http://www.hwupgrade.it/forum/showpost.php?p=19034349&postcount=73

"Se qualunque linguaggio va bene per la didattica, allora si può benissimo partire dal linguaggio macchina e quindi dalle tabelle degli opcode.

Nel momento in cui lo scopo è la didattica, il linguaggio NON può essere di secondaria importanza, perché è chiaro che condiziona, anche pesantemente, i concetti da apprendere e modifica la curva di apprendimento."

Ho riportato un dato di fatto: se il linguaggio è indifferente per la didattica, si può benissimo usare il linguaggio macchina. Sic et simpliciter.

Se avessi voluto essere sarcastico, avrei piazzato delle apposite faccine, come ho fatto col messaggio che ho scritto a D3stroyer: http://www.hwupgrade.it/forum/showpost.php?p=19034370&postcount=74

cdimauro

06-10-2007, 23:34

come ha fatto notare D3stroyer stiamo scadendo nel ridicolo... direi di rientrare in topic... sei d'accordo? io poi chiedo una sospensione per sopraggiunti limiti d'orario :D
Non c'è problema. ;)

mad_hhatter

06-10-2007, 23:36

la mia domanda era seria però..mi avete snobbato..e io a refreshare pure :(

ovviamente non sono un prof, ma stavamo discutendo di didattica... sono uno sviluppatore e un ex-studente di ing. informatica (essendomi laureato da pochi mesi)

mad_hhatter

06-10-2007, 23:37

T'è parso male: http://www.hwupgrade.it/forum/showpost.php?p=19034349&postcount=73

"Se qualunque linguaggio va bene per la didattica, allora si può benissimo partire dal linguaggio macchina e quindi dalle tabelle degli opcode.

Nel momento in cui lo scopo è la didattica, il linguaggio NON può essere di secondaria importanza, perché è chiaro che condiziona, anche pesantemente, i concetti da apprendere e modifica la curva di apprendimento."

Ho riportato un dato di fatto: se il linguaggio è indifferente per la didattica, si può benissimo usare il linguaggio macchina. Sic et simpliciter.

Se avessi voluto essere sarcastico, avrei piazzato delle apposite faccine, come ho fatto col messaggio che ho scritto a D3stroyer: http://www.hwupgrade.it/forum/showpost.php?p=19034370&postcount=74

in tal caso credo proprio di doverti delle scuse :)

cdimauro

06-10-2007, 23:38

ma voi che lavoro fate? hhatter mi pare un professore e cdimauro un suo collega :asd:

plz ditemelo è troppo divertente.

non me lo dite eh :read:

la mia domanda era seria però..mi avete snobbato..e io a refreshare pure :(
La tua domanda non era affatto seria, comunque non sono un professore (ho, però, insegnato in corsi di aggiornamento professionale, e dato ripetizioni di informatica a studenti delle superiori e universitari) e attualmente mi occupo di sviluppo di applicazioni "interne" all'azienda per cui lavoro.

D3stroyer

06-10-2007, 23:39

grazie a entrambi :)

cdimauro

06-10-2007, 23:41

in tal caso credo proprio di doverti delle scuse :)
Fa niente. Mettiamoci una pietra sopra e facciamo come se non fosse successo nulla (soprattutto perché voglio proprio andare a dormire :D).

Comunque mi fa piacere che ci siamo chiariti: non mi piace aver problemi con nessuno, specialmente per questioni di forum. ;)

x D3stroyer: di niente. :)

mad_hhatter

06-10-2007, 23:45

notte a tutti allora :D

cdimauro

07-10-2007, 06:20

Buondì. :)

Allora, direi che è il caso di rientrare sul piano puramente tecnico su una questione che avevo sollevato, ma che non era sta chiusa, e di cui riporto i punti necessari a contestualizzarla in maniera precisa:
Quindi posso assumere che per imparare la programmazione strutturata vada benissimo il linguaggio macchina, per quella funzionale il LISP, e per quella OOP PERL?
L'avevamo già detto: lo scopo è la didattica.
L'argomento da cui è partito il tutto è IMPARARE a programmare.
Quindi poste le due condizioni (didattica & imparare a programmare), la domanda che ho posto prima sui linguaggi che è possibile adottare per le tre prospettive trova risposta affermativa o negativa (e in questo caso sarebbe interessante conoscerne le motivazioni)?

k0nt3

07-10-2007, 10:17

io quando ho preso in mano java conoscevo solamente pascal, C e C++ eppure è come se l'avessi sempre conosciuto e in poco tempo sono diventato produttivo (due esperienze diverse = due risultati diversi).

per quanto riguarda il discorso: basta imparare un linguaggio per imparare il corrispettivo paradigma? la risposta è "dipende" come al solito.
se c'è una base teorica sul paradigma in questione prima di procedere all'apprendimento del linguaggio direi che è sufficiente. questo perchè imparare un linguaggio è banale rispetto a imparare un paradigma.
la maggiore difficoltà per chi inizia a programmare secondo me non è il linguaggio in sè, ma proprio entrare nell'ottica della programmazione.
per questo mi è sembrato assurdo insegnare la programmazione strutturata in java. lasciare dei concetti da parte non è mai bene, ma nessuno ti obbliga a lasciarli da parte, quindi non è colpa di java. le possibilità sono le seguenti:
- inizi con la programmazione strutturata e porti un linguaggio strutturato come esempio (C, pascal ecc..)
- inizi con la programmazione OO e porti un linguaggio OO come esempio (java, C# ecc..)
- proprio al limite si puoi insegnare C++ che supporta tutti e due i paradigmi, ma ultimamente è stato abbastanza svalutato a livello didattico

detto questo mi viene da sorridere quando leggo python ha maggior bla e maggior blabla :D ma vogliamo parlare anche del minor blablabla?

DioBrando

07-10-2007, 10:21

detto questo mi viene da sorridere quando leggo python ha maggior bla e maggior blabla :D ma vogliamo parlare anche del minor blablabla?

parliamone.

A proposito delle cose che sono state dette su Java e i suoi sviluppi recenti non hai scritto una virgola.
ne devo dedurre quindi che sei d'accordo?

DioBrando

07-10-2007, 10:22

il tuo sarcasmo e' completamente fuori luogo.

in nessun post ho mai affermato che il fatto che la scelta del linguaggio a supporto della didattica sia secondaria significhi che, imparato un qualunque linguaggio, si sia in grado di passare a qualsiasi altro linguaggio in quattro e quattr'otto

Sicuro di non averlo mai affermato?

faccio notare che fin'ora non ho consigliato neanche un linguaggio: il motivo è che per imparare a programmare, il linguaggio in sè è l'aspetto meno importante

k0nt3

07-10-2007, 10:44

parliamone.
ho perso interesse per l'aria

A proposito delle cose che sono state dette su Java e i suoi sviluppi recenti non hai scritto una virgola.
ne devo dedurre quindi che sei d'accordo?
non mi sembra ragionevole presupporre l'assunzione di mondo chiuso sulle mie affermazioni

ps. vedo che hai quotato solo una piccola parte del mio post

DioBrando

07-10-2007, 10:48

Nessuna arroganza, metto solo in evidenza le contraddizioni che sono venute fuori nei post strada facendo.

Ti chiedo una cortesia, se puoi: per un fatto di chiarezza, sarebbe meglio tu quotassi pezzo per pezzo e non riportare tra " quel che l'interlocutore dice, atlrimenti si fa' fatica a capire quali sono le tue parole e quali quelle dell'"altro".
Thx

l'arroganza che poni in alcune delle tue frasi comincia un po' a infastidirmi, francamente.
cio' premesso, e' abbastanza evidente che usiamo gli stessi termini riferendoci a cose sufficientemente diverse... per te fondamenti1 indica qualcosa che non corrisponde al corso di cui io sto parlando e che contiene, invece, un'introduzione alla programmazione, alle strutture di dati, alla teoria della complessita' algoritmica. In questo percorso lo studente inizia a familiarizzare con i concetti di variabile, istruzione, ecc applicati al linguaggio assembly in modo da vedere le interazioni con l'hardware sottostante e avere una idea semplificata di quale sia lo scopo di un compilatore. Acquisiti questi rudimenti, allo studente viene presentata la programamzione OO con una definizione semplice e intuitiva dei concetti fondamentali di oggetto, classe, interfaccia, ecc...

Fondamenti I di Informatica prevede gli argomenti (una parte almeno) di quelli che ho citato in precedenza, almeno nei corsi che nascono sotto l'ala Informatica e affini (e che quindi fanno parte della facoltà di Scienze Matematiche Fisiche e Naturali).

Evidentemente in di Ingegneria Informatica, la scansione risulta differente, anche perchè in Informatica non esiste un unico corso in cui si riassumano argomenti come l'introduzione alla programmazione, la spiegazione del paradigma OO, esempi assembly.

Questo a riprova del fatto che il nome in sè conta relativamente, quel che fa' la differenza è il programma.

a me non pare che, per fare un paragone, al corso di analisi1 il professore prima di introdurre le funzioni faccia giocare gli studenti con le 4 operazioni... al contrario fornisce la definizione rigorosa del concetto di numero, di operatore, ecc... e questo non mi pare sconvolgente, ma anzi molto importante per gettare le fondamenta che reggono l'intera impalcatura del corso.

Stai sbagliando esempio. La formazione matematica di un qualsiasi studente che approda in una facoltà scientifica può variare, ma di certo non si parte da 0 e quindi i concetti di numero, funzione, insieme sono per esempio già noti, anche se si riparte lo stesso da lì.
E' altrettanto ovvio che non si facciano le tabelline.

Mentre nel caso della programmazione, lo studente, a meno che non abbia già visto qlc per conto suo o in un istituto tecnico, è pari a un bambino di 5 anni che comincia a conoscere cos'è una moltiplicazione.

E' un paragone che non calza il tuo.

ti faccio notare che per mettere in pratica i concetti esposti in un corso di introduzione alla programmazione un qualunque linguaggio va bene perche' non e' il linguaggio in se' l'oggetto della didattica.

E allora perchè in un corso universitario invece la scelta del linguaggio è una delle prime?

E se fosse come dici tu perchè un insegnante non tira in alto una monetina per decidere..tanto và bene qualsiasi linguaggio.

quindi non esiste contraddizione nel dire che la teoria risulta piu' efficacie se accompagnata da qualche esercizio e contemporaneamente che il linguaggio adottato per costruire gli esempi e' una questione secondaria (posto che il linguaggio sia adatto allo scopo).

Continui a rimanere general generico e questo fin dall'inizio, quando io ti ho fatto delle domande precise.

Quali sono le nozioni che accenneresti? Qual'è la teoria che spiegheresti ai tuoi studenti, prima di affrontare un esempio specifico?
Quale sarebbe il percorso didattico che costruiresti per far sì che uno studente impari a programmare?

Insomma in parole povere ti avevo chiesto se potevi illustrarmi un ipotetico corso di Programmazione I.

infine, scrivi:
"Il confronto tra i due "Hello World" era mirato a far vedere come, mentre in Python, ci si può concentrare maggiormente sulla parte algoritmica perchè il linguaggio è sintetico ma ricco dal punto di vista espressivo, con Java invece, un principiante si trova a dover utilizzare PER FORZA costrutti di cui all'inizio non potrà capire lo scopo nè il come interagiscano tra loro.

Avrà un quadro generale di cosa sia la POO, conoscerà la definizione di classe, ma non sarà in grado di capire come si utilizza, come si istanzia, di cosa si compone, perchè gli mancano appunto le basi.

Quindi qual'è il senso di imbottire di concetti uno studente, se poi l'applicazione pratica seguirà una progressione differente?
Per me nessuno."

io ripeto che nella definizione di oggetto, classe, ecc non vedo nulla di trascendentale per uno studente universitario di una facolta' di informatica... tant'e' che dopo l'Hello World ci e' stato presentato un piccolo esempio, molto semplice, ma molto formativo, di oggetto, di interazione tra oggetti, ecc... e ripeto che la cosa non ha suscitato il minimo scandandalo negli studenti...

e' evidente che chi VUOLE conoscere a fondo come funzionano le cose non si spaventa per certe cose anzi, ne e' avido e non vuole dolcificanti sintattici perche' non gli interessa la produttivita', gli interessa la conoscenza scientifica degli oggetti che gli vengono presentati

Io continuo a sostenere che sia meglio lasciare che gli studenti si focalizzino passo per passo prima sui mattoni fondamentali della programmazione, poi su strutture + complesse; e se in questo quadro didattico, posso evitare di utilizzare una sintassi che solo + tardi, uno studente imparerà realmente a conoscere, lo preferisco, perchè evito possibili fraintendimenti.

Dato che il paradigma OO è quello ormai + utilizzato, all'inizio spiegherei senz'altro cosa sia un linguaggio OO, ma mi fermerei lì, ai 4 punti principali.
Non tirerei fuori certo, per esempio, il concetto di package, che è inutile, IMHO, ai fini dell'apprendimento iniziale.

DioBrando

07-10-2007, 11:12

ho perso interesse per l'aria

+ che altro ti viene un pò difficile continuare una discussione in cui hai mostrato di non sapere realmente come funzioni un paradigma OO e di come Python lo plasmi all'interno della sua sintassi.

Poi se per cercare di salvare le apparenze, vuoi dire che non ti interessa proseguire, allora non farlo direttamente, senza nemmeno citare in modo aleatorio e ondivago, come quando scrivi "ma vogliamo parlare anche del minor blablabla?"

non mi sembra ragionevole presupporre l'assunzione di mondo chiuso sulle mie affermazioni

Rispondi pure allora.

ps. vedo che hai quotato solo una piccola parte del mio post

Siccome ti ho scritto che agli altri due post non avevi messo una virgola, mi fai notare che non ho risposto ad una parte del tuo post?
Eh vabbè...

Ma se ti fa' sentire meglio ti rispondo, non c'è problema, anzi mea culpa, di solito rispondo a tutto il post:

io quando ho preso in mano java conoscevo solamente pascal, C e C++ eppure è come se l'avessi sempre conosciuto e in poco tempo sono diventato produttivo (due esperienze diverse = due risultati diversi).

Credo sia un'esperienza comune a tutti, perchè banalmente, con Java sei + produttivo che con C/C++.

per quanto riguarda il discorso: basta imparare un linguaggio per imparare il corrispettivo paradigma? la risposta è "dipende" come al solito.

Se il linguaggio ti mette nelle condizioni migliori di farlo, perchè no? Con Python puoi imparare sia il paradigma OO che quello funzionale che quello imperativo ed essere subito produttivo.

se c'è una base teorica sul paradigma in questione prima di procedere all'apprendimento del linguaggio direi che è sufficiente. questo perchè imparare un linguaggio è banale rispetto a imparare un paradigma.

Secondo me no. Questo perchè la scelta di un linguaggio condiziona anche il modo con cui si apprende un paradigma.

E se così non fosse non si spiega il perchè delle tante persone che hanno dovuto fare tabula rasa dopo aver cominciato con C, aver switchato al C++ (avendoci lavorato complessivamente anni) e poi essere passati per esempio a Java

la maggiore difficoltà per chi inizia a programmare secondo me non è il linguaggio in sè, ma proprio entrare nell'ottica della programmazione.

Non posso che concordare. Ma una scelta azzeccata del linguaggio, semplifica la vita.

per questo mi è sembrato assurdo insegnare la programmazione strutturata in java. lasciare dei concetti da parte non è mai bene, ma nessuno ti obbliga a lasciarli da parte, quindi non è colpa di java. le possibilità sono le seguenti:
- inizi con la programmazione strutturata e porti un linguaggio strutturato come esempio (C, pascal ecc..)
- inizi con la programmazione OO e porti un linguaggio OO come esempio (java, C# ecc..)
- proprio al limite si puoi insegnare C++ che supporta tutti e due i paradigmi, ma ultimamente è stato abbastanza svalutato a livello didattico

Proprio perchè al'università le ore sono contate e non si possono fare 10 corsi di programmazione, quel che affermi non è proponibile.

Non si insegnano + paradigmi nè + linguaggi ad esso corrispondenti, perchè questo comporterebbe una perdita di tempo nel dover ogni volta che si affronta un linguaggio diverso, rispiegare la sintassi, le strutture ecc. ecc.

Ed è uno dei motivi per cui si predilige, da un pò di questi anni, l'uso di Java.
Si insegnano le basi, poi quando si passa al paradigma OO (che è di solito il cuore di Programmazione II), il passaggio avviene in modo naturale, rispetto all'uso per es. di C++.

k0nt3

07-10-2007, 12:38

+ che altro ti viene un pò difficile continuare una discussione in cui hai mostrato di non sapere realmente come funzioni un paradigma OO e di come Python lo plasmi all'interno della sua sintassi.

non so cosa te lo fa pensare

Poi se per cercare di salvare le apparenze, vuoi dire che non ti interessa proseguire, allora non farlo direttamente, senza nemmeno citare in modo aleatorio e ondivago, come quando scrivi "ma vogliamo parlare anche del minor blablabla?"

parlo in modo vago perchè non esistono altri modi di descrivere simili concetti.
un linguaggio di programmazione è necessariamente un trade-off di certe caratteristiche perchè spesso queste sono in contrasto fra loro. detto questo non mi sembra che python sia un linguaggio magico, perciò sono portato a pensare che oltre ai vantaggi ha anche degli svantaggi. ora sul fatto che sia il più adatto all'apprendimento della programmazione potremmo anche parlare per giorni, ma con scarsi risultati IMHO. l'apprendimento dipende per prima cosa dall'apprendista

Rispondi pure allora.

alle recenti evoluzioni di java? non ho seguito il discorso.. di che caratteristiche si discuteva?

Siccome ti ho scritto che agli altri due post non avevi messo una virgola, mi fai notare che non ho risposto ad una parte del tuo post?
Eh vabbè...
altrimenti avrei potuto presupporre che eri daccordo con me :D

Credo sia un'esperienza comune a tutti, perchè banalmente, con Java sei + produttivo che con C/C++.

ma io non ho affermato di essere più produttivo in java rispetto al C/C++ :confused: ho solo detto che in poco tempo ero produttivo in java perchè non mi è stato per niente difficile imparare le caratteristiche peculiari di questo linguaggio

Se il linguaggio ti mette nelle condizioni migliori di farlo, perchè no? Con Python puoi imparare sia il paradigma OO che quello funzionale che quello imperativo ed essere subito produttivo.

questione di gusti, io non trovo che sia importante usare lo stesso linguaggio per tutto, anzi trovo molto più educativo impararne diversi.
oltretutto, come spesso accade a un linguaggio pensato per essere multiparadigma, python non eccelle se ci prefissiamo di usare un paradigma alla volta

Secondo me no. Questo perchè la scelta di un linguaggio condiziona anche il modo con cui si apprende un paradigma.

E se così non fosse non si spiega il perchè delle tante persone che hanno dovuto fare tabula rasa dopo aver cominciato con C, aver switchato al C++ (avendoci lavorato complessivamente anni) e poi essere passati per esempio a Java
non è il mio caso, per cui non saprei dirti. probabilmente è meglio avere conoscenze generali prima di specializzarsi in un linguaggio

Non posso che concordare. Ma una scelta azzeccata del linguaggio, semplifica la vita.
la scelta del linguaggio è soggettiva però

Proprio perchè al'università le ore sono contate e non si possono fare 10 corsi di programmazione, quel che affermi non è proponibile.

Non si insegnano + paradigmi nè + linguaggi ad esso corrispondenti, perchè questo comporterebbe una perdita di tempo nel dover ogni volta che si affronta un linguaggio diverso, rispiegare la sintassi, le strutture ecc. ecc.

mi sa che solo da voi funziona così :p
ho fatto un corso intero sui paradigmi, strutture dati e algoritmi in cui era necessario conoscere python, java, ada e un linguaggio astratto simil-assembler (oltre a un paio di accenni su C++ a livello puramente teorico). trovo che conoscere, almeno negli aspetti essenziali, un ampio spettro di linguaggi sia fondamentale per ogni programmatore. non avere questo tipo di impostazione porta a farsi influenzare dal linguaggio con tutto quello che comporta

Ed è uno dei motivi per cui si predilige, da un pò di questi anni, l'uso di Java.
Si insegnano le basi, poi quando si passa al paradigma OO (che è di solito il cuore di Programmazione II), il passaggio avviene in modo naturale, rispetto all'uso per es. di C++.
da noi si è insegnato prima il C e poi java eppure non è morto nessuno, per me è stato naturale

mad_hhatter

07-10-2007, 13:32

Buondì. :)

Allora, direi che è il caso di rientrare sul piano puramente tecnico su una questione che avevo sollevato, ma che non era sta chiusa, e di cui riporto i punti necessari a contestualizzarla in maniera precisa:

Quindi poste le due condizioni (didattica & imparare a programmare), la domanda che ho posto prima sui linguaggi che è possibile adottare per le tre prospettive trova risposta affermativa o negativa (e in questo caso sarebbe interessante conoscerne le motivazioni)?

non conoscendo ne' lisp ne' perl non posso dare una risposta piu' precisa di questa: se l'obiettivo e' soltanto far capire cosa sia una variabile, una procedura (o metodo, o funzione) e far capire il concetto di istruzione e di sequenza di istruzioni, allora si', anche la programmazione in linguaggio assembly puo' servire a dare questo tipo di visione... ma questo tipo di linguaggio non puo' servire ad altro: molto meglio passare ad un linguaggio di alto livello il prima possibile (se non addirittura da subito). detto questo, se l'obiettivo di mostrare la programmazione strutturata e' soltanto quello di far apprendere l'uso dei costrutti iterativi e condizionali, allora tanto vale passare immediatamente a un linguaggio OO (o funzionale se questo fosse in linea con gli obiettivi didattici...). quello che penso, infatti, e' che costrutti di questo tipo non hanno bisogno di essere dimostrati praticamente: se mi dici che
if (condition)
statement1
else
statement2

significa che se condition e' vera viene eseguito statement1 altrimenti viene eseguito staement2, non credo ci sia molto altro da "far vedere" e che necessiti un esempio di implementazione al calcolatore...

in ogni caso anche questi costrutti sono facilmente descrivili in linguaggio assembly... anzi, trovo che offra una comprensione approfondita di come funzionino tali costrutti, la cui logica e' decisamente semplice.

cio' detto, passando a un linguaggio OO avendo gia' idea di cosa sia un'istruzione, un algoritmo, ecc... non penso ci siano ostacoli nell'instrodurre i concetti propri della programmazione OO...

un metodo probabilmente piu' complesso, ma per nulla assurdo potrebbe essere quello di rovesciare la linea temporale: prima spiegare cosa sia un oggetto, descrivendo la programmazione come ricerca di un modello per una data situazione e solo dopo descrivere dettagli tecnici come il concetto di istruzione, variabile ecc... seppur piu complesso, questo metodo ha il vantaggio di dare prima una visione di altissimo livello al concetto di programmazione, e solo dopo introduce lo studente nei dettagli tecnici della programmazione...

e' chiaro comunque che un metodo universale non possa esistere, ma vada scelto il metodo piu adatto in funzione di chi e' il destinatario della lezione

mad_hhatter

07-10-2007, 13:39

Sicuro di non averlo mai affermato?

quale parte di
"faccio notare che fin'ora non ho consigliato neanche un linguaggio: il motivo è che per imparare a programmare, il linguaggio in sè è l'aspetto meno importante"

afferma che
"imparato un qualunque linguaggio, si sia in grado di passare a qualsiasi altro linguaggio in quattro e quattr'otto" ?

l'arte della programamzione, della modellazione della soluzione di un problema, della costruzione di un algoritmo ecc e' cosa ben diversa dall'apprendimento di uno specifico linguaggio... la comunicazione intesa come entita' astratta e' cosa ben distinta dal linguaggio usato per comunicare

mad_hhatter

07-10-2007, 13:56

Stai sbagliando esempio. La formazione matematica di un qualsiasi studente che approda in una facoltà scientifica può variare, ma di certo non si parte da 0 e quindi i concetti di numero, funzione, insieme sono per esempio già noti, anche se si riparte lo stesso da lì.
E' altrettanto ovvio che non si facciano le tabelline.

Mentre nel caso della programmazione, lo studente, a meno che non abbia già visto qlc per conto suo o in un istituto tecnico, è pari a un bambino di 5 anni che comincia a conoscere cos'è una moltiplicazione.

E' un paragone che non calza il tuo.

beh, sicuramente il concetto di variabile, istruzione e "ricetta" qualsiasi studente universitario ce l'ha ben presente... assieme ai concetti di condizione, selezione e ripetizione...

in ogni caso la presentazione assiomatica dei numeri penso abbia lo stesso effetto che puo' avere l'introduzione del concetto di oggetto...

E allora perchè in un corso universitario invece la scelta del linguaggio è una delle prime?

E se fosse come dici tu perchè un insegnante non tira in alto una monetina per decidere..tanto và bene qualsiasi linguaggio.

perche' il docente non cambia linguaggio ogni anno, perche' il corso el gia' stato progettato quando inizia la prima lezione, perche' il linguaggio puo' essere una scelta personale del docente a seconda della sua esperienza didattica pregressa.

Quali sono le nozioni che accenneresti? Qual'è la teoria che spiegheresti ai tuoi studenti, prima di affrontare un esempio specifico?
Quale sarebbe il percorso didattico che costruiresti per far sì che uno studente impari a programmare?

Insomma in parole povere ti avevo chiesto se potevi illustrarmi un ipotetico corso di Programmazione I.

prova a vedere se l'ultima risposta a cdimauro di soddisfa

Io continuo a sostenere che sia meglio lasciare che gli studenti si focalizzino passo per passo prima sui mattoni fondamentali della programmazione, poi su strutture + complesse; e se in questo quadro didattico, posso evitare di utilizzare una sintassi che solo + tardi, uno studente imparerà realmente a conoscere, lo preferisco, perchè evito possibili fraintendimenti.

io invece penso che i dettagli tecnici sia meno importanti di concetti come la modellazione di una situazione, l'astrazione, la creazione di un algoritmo, ecc

cdimauro

08-10-2007, 08:28

io quando ho preso in mano java conoscevo solamente pascal, C e C++ eppure è come se l'avessi sempre conosciuto e in poco tempo sono diventato produttivo (due esperienze diverse = due risultati diversi).
In Pascal (Delphi, per l'esattezza) hai già molti degli elementi che ritrovi in Java (oggetti sempre come riferimenti, interfacce, moduli che racchiudono codice, stringhe, e altro), per cui trovo normale che tu non abbia avuto problemi.
la maggiore difficoltà per chi inizia a programmare secondo me non è il linguaggio in sè, ma proprio entrare nell'ottica della programmazione.
per questo mi è sembrato assurdo insegnare la programmazione strutturata in java. lasciare dei concetti da parte non è mai bene, ma nessuno ti obbliga a lasciarli da parte, quindi non è colpa di java. le possibilità sono le seguenti:
- inizi con la programmazione strutturata e porti un linguaggio strutturato come esempio (C, pascal ecc..)
Io suggerisco di partire dal linguaggio macchina (quindi nemmeno con l'assembly), e in particolare con l'ISA Itanium di Intel.
- inizi con la programmazione OO e porti un linguaggio OO come esempio (java, C# ecc..)
Scelgo Perl.
- proprio al limite si puoi insegnare C++ che supporta tutti e due i paradigmi, ma ultimamente è stato abbastanza svalutato a livello didattico
No no: lasciamo pure ampia libertà, visto che si può scegliere qualunque linguaggio.

Linguaggio macchina e PERL vanno benissimo per imparare la programmazione strutturata e quella a oggetti.
non so cosa te lo fa pensare
Su questo ho avuto già modo di dimostrare che non hai ancora capito com'è fatto e come funziona Python: ci sono dei messaggi in cui l'ho messo in chiaro, ma evidentemente ti saranno sfuggiti.
questione di gusti, io non trovo che sia importante usare lo stesso linguaggio per tutto, anzi trovo molto più educativo impararne diversi.
oltretutto, come spesso accade a un linguaggio pensato per essere multiparadigma, python non eccelle se ci prefissiamo di usare un paradigma alla volta
Adesso ci spieghi anche il perché di questa tua frase lapidaria.

Sul resto concordo con DioBrando.

k0nt3

08-10-2007, 08:51

In Pascal (Delphi, per l'esattezza) hai già molti degli elementi che ritrovi in Java (oggetti sempre come riferimenti, interfacce, moduli che racchiudono codice, stringhe, e altro), per cui trovo normale che tu non abbia avuto problemi.
ma io non ho mai usato delphi

Io suggerisco di partire dal linguaggio macchina (quindi nemmeno con l'assembly), e in particolare con l'ISA Itanium di Intel.

non è costruttivo rispondere con simili affermazioni. non considero nemmeno il linguaggio macchina perchè evidentemente è solo una provocazione, ma l'assembly non va bene solo perchè richiede conoscenze basilari sull'architettura di una cpu, per il resto non ha niente che non va

Scelgo Perl.
e fai male visto che non è prettamente un linguaggio a oggetti, ma è anche procedurale e funzionale

No no: lasciamo pure ampia libertà, visto che si può scegliere qualunque linguaggio.
ci mancherebbe che le scelte siano obbligatorie

Linguaggio macchina e PERL vanno benissimo per imparare la programmazione strutturata e quella a oggetti.

no non vanno bene

Su questo ho avuto già modo di dimostrare che non hai ancora capito com'è fatto e come funziona Python: ci sono dei messaggi in cui l'ho messo in chiaro, ma evidentemente ti saranno sfuggiti.

ma anche no. so come funziona python

Adesso ci spieghi anche il perché di questa tua frase lapidaria.

banalmente perchè non sono pensati per essere usati in questo modo

cdimauro

08-10-2007, 09:08

non conoscendo ne' lisp ne' perl non posso dare una risposta piu' precisa di questa: se l'obiettivo e' soltanto far capire cosa sia una variabile, una procedura (o metodo, o funzione) e far capire il concetto di istruzione e di sequenza di istruzioni, allora si', anche la programmazione in linguaggio assembly puo' servire a dare questo tipo di visione...

ma questo tipo di linguaggio non puo' servire ad altro: molto meglio passare ad un linguaggio di alto livello il prima possibile (se non addirittura da subito).
Imparare a programmare e fermarsi soltanto a questi concetti non sarebbe utile: parli già di cambiare linguaggio quando se ne è appena appreso uno per iniziare.

Comunque stai già affermando che qualunque linguaggio non va bene per imparare a programmare, visto che mi dici che sarebbe addirittura auspicabile partire da SUBITO con uno di alto livello: è evidente che la SCELTA del linguaggio, quindi, ha un ruolo fondamentale, al contrario di quello che hai sostenuto finora.
detto questo, se l'obiettivo di mostrare la programmazione strutturata e' soltanto quello di far apprendere l'uso dei costrutti iterativi e condizionali, allora tanto vale passare immediatamente a un linguaggio OO (o funzionale se questo fosse in linea con gli obiettivi didattici...). quello che penso, infatti, e' che costrutti di questo tipo non hanno bisogno di essere dimostrati praticamente: se mi dici che
if (condition)
statement1
else
statement2

significa che se condition e' vera viene eseguito statement1 altrimenti viene eseguito staement2, non credo ci sia molto altro da "far vedere" e che necessiti un esempio di implementazione al calcolatore...
No, l'obiettivo è quello di iniziare a programmare e NON fermarsi soltanto ai primi concetti che si affrontano. Per inciso, visto che a un programmatore servono strutture dati diverse in base al tipo di problema da risolvere, studierei anche quelli più comuni (stringhe, record/struct, array, alberi, grafi, ecc.).
in ogni caso anche questi costrutti sono facilmente descrivili in linguaggio assembly... anzi, trovo che offra una comprensione approfondita di come funzionino tali costrutti, la cui logica e' decisamente semplice.
L'assembly (come il linguaggio macchina) esprime "nativamente" soltanto questi concetti:
- salto incondizionato;
- salto condizionato;
- salto a subroutine;
- salto a routine del s.o. (supportato soltanto da alcune ISA);
- loop (supportato soltanto da alcune ISA).

Costrutti come if/then/else, switch, for, while, repeat, sono a un livello più alto, e non è necessario studiarli per imparare la programmazione strutturata (parlando sempre di assembly e linguaggio macchina).
cio' detto, passando a un linguaggio OO avendo gia' idea di cosa sia un'istruzione, un algoritmo, ecc... non penso ci siano ostacoli nell'instrodurre i concetti propri della programmazione OO...
Concordo.
un metodo probabilmente piu' complesso, ma per nulla assurdo potrebbe essere quello di rovesciare la linea temporale: prima spiegare cosa sia un oggetto, descrivendo la programmazione come ricerca di un modello per una data situazione e solo dopo descrivere dettagli tecnici come il concetto di istruzione, variabile ecc... seppur piu complesso, questo metodo ha il vantaggio di dare prima una visione di altissimo livello al concetto di programmazione, e solo dopo introduce lo studente nei dettagli tecnici della programmazione...
Generalmente si dà un accenno di cosa voglia dire sviluppare un algoritmo.
e' chiaro comunque che un metodo universale non possa esistere, ma vada scelto il metodo piu adatto in funzione di chi e' il destinatario della lezione
Le condizioni le avevo scritte: insegnare a programmare a chi non ha alcuna conoscenza in materia.

La scelta del linguaggio, come anche tu lasci intendere sopra e contrariamente a quello che avevi affermato finora, è MOLTO importante (altrimenti non si capisce per quale motivo si dovrebbe iniziare da subito con un linguaggio di alto livello, come suggerivi).

Io posso anche basare un corso di introduzione alla programmazione, partendo da quella strutturata, interamente sul linguaggio macchina, se la scelta può essere arbitraria, e quindi NON fermarmi soltanto al concetto di dato, variabile e istruzione, ma affrontare (molto più avanti ovviamente) persino il concetto di albero rosso-nero.
Per far questo sceglierei l'ISA dell'Itanium di Intel, un particolare processore VLIW che esegue bundle a 128 bit contenenti 3 istruzioni debitamente sistemate al suo interno (perché esistono NUMEROSE regole e vincoli: le istruzioni non si possono "mischiare" a piacimento).

Bada bene che ho sempre parlato di linguaggio macchina e mai di assembly. Il fatto che la scelta del linguaggio sia ritenuta del tutto arbitraria, mi permette di optare per il primo, e in particolare per l'ISA di cui sopra.

Questo vuol dire anche rinunciare a tutte le comodità che forniscono gli assemblatori, in primis il calcolo degli offset per le istruzioni di salto e i dati, che col primo si devono necessariamente calcolare a mano e soprattutto ricalcolare ogni volta che vengono inserite nuove istruzioni e/o dati oppure ne vengano cancellate alcune.
Un lavoro inumano che personalmente non augurerei nemmeno al mio peggior nemico (visto che c'ho lavorato per qualche tempo e so cosa significhi).

Ma se la scelta è arbitraria, anche quella del linguaggio macchina per la programmazione strutturata è perfettamente valida.

Come pure sarebbe valida quella di Perl per quella a oggetti, visto che offre la possibilità di lavorarci (guarda qui http://perldoc.perl.org/perlboot.html il tutorial per iniziare a programmare a oggetti con PERL; ci sono altri 3 link sul sito che lo affrontano in maniera più approfondita, ma te li sconsiglio vivamente; se hai poco tempo e vuoi farti velocemente un'idea di come si lavora con gli oggetti in Perl, qui http://www.garshol.priv.no/download/text/perl.html#id3.5. trovi una rapidissima trattazione).

In definitiva, quello che voglio ribadire ancora una volta è che la scelta di un linguaggio ha, invece, notevoli ricadute, e per questo non è vero che qualunque linguaggio che permetta di esprimere un particolare paradigma va bene, in particolare per iniziare.

L'esempio del linguaggio macchina penso sia piuttosto eloquente, e ti assicuro che quello di Perl non è certo da meno. ;)

cdimauro

08-10-2007, 09:18

ma io non ho mai usato delphi
Pensavo di sì, allora per quanto riguarda le classi che usano riferimenti e le interfacce non vale quanto avevo scritto.
non è costruttivo rispondere con simili affermazioni. non considero nemmeno il linguaggio macchina perchè evidentemente è solo una provocazione,
E' chiaro che sia una provocazione, ma la scelta è perfettamente valida sul piano formale, visto che non esistono vincoli e la scelta del linguaggio è libera.
ma l'assembly non va bene solo perchè richiede conoscenze basilari sull'architettura di una cpu, per il resto non ha niente che non va
La scelta dell'architettura non è un vincolo, per cui andrebbe benissimo. D'altra parte quando si inizia a programmare in assembly, una qualunque architettura, anche inventata, la si deve scegliere.

Comunque hai detto che andrebbe bene anche l'assembly, e allora ti voglio vedere a implementare un albero rosso-nero con questo linguaggio (e ringrazia che non t'abbia mostrato il codice di un particolare trie che mi sono inventato una dozzina d'anni fa per comprimere i dati: già in Pascal da implementare mi ha richiesto non poco tempo e codice :D).
e fai male visto che non è prettamente un linguaggio a oggetti, ma è anche procedurale e funzionale
E allora? La scelta è perfettamente legittima, visto che permette di programmare a oggetti, e tanto basta.
ci mancherebbe che le scelte siano obbligatorie

no non vanno bene
E perché? Se posso scegliere qualunque linguaggio (hai detto anche tu le scelte non sono obbligatorie), io sulla carta posso scegliere quello che voglio. Se non è così dovresti spiegarmi perché non andrebbero bene. ;)
ma anche no. so come funziona python
In tal caso ci sono dei messaggi che t'aspettano e a cui puoi replicare, visto che ho dimostrato che, invece, non lo conosci.

Ripeto: non basta aver imparato la sintassi, e scritto qualche esercizio per passare un corso per poter affermare di conoscere Python.
banalmente perchè non sono pensati per essere usati in questo modo
Allora spiegaci come sono stati pensati e perché non andrebbero "usati in questo modo".

mad_hhatter

08-10-2007, 09:45

Imparare a programmare e fermarsi soltanto a questi concetti non sarebbe utile: parli già di cambiare linguaggio quando se ne è appena appreso uno per iniziare.

In definitiva, quello che voglio ribadire ancora una volta è che la scelta di un linguaggio ha, invece, notevoli ricadute, e per questo non è vero che qualunque linguaggio che permetta di esprimere un particolare paradigma va bene, in particolare per iniziare.

L'esempio del linguaggio macchina penso sia piuttosto eloquente, e ti assicuro che quello di Perl non è certo da meno. ;)

continui a prendere i miei discorsi troppo letteralmente e questo, permettimi, non fa proseguire la discussione perchè mi costringi a cesellare anche l'ovvio: è ovvio che la scelta è arbitraria tra i lianguaggi adatti allo scopo. imaparare a programmare coinvolge molti aspetti diversi e per ognuno può essere meglio un linguaggio piuttosto che un altro...

cdimauro

08-10-2007, 09:57

mad_hhatter

08-10-2007, 10:42

Deformazione professionale. :p

Mi è sufficiente che tu abbia affermato che esistono dei linguaggi "più adatti allo scopo". Quindi c'è un qualche criterio (per lo più personale, dovuto ad esperienza, studi et similia) che ci permette di valutare se un linguaggio è "più o meno adatto".

Dunque la scelta di un linguaggio piuttosto che un altro per imparare a programmare HA SENSO, e quindi ha pure senso la discussione che è stata fatta finora e che ha portato alla selezione di Java e Python quali candidati "migliori"; fra i quali mi sembra che Python, con le argomentazioni che abbiamo fornito (vedi anche l'intervista a Eckel, che è molto utile allo scopo), si dimostra il più adatto.

che abbia senso è naturale, che sia prioritaria è molto discutibile...

che python sia piuttosto adatto non lo discuto, non concordo invece sul fatto che sia il più adatto, perché ripeto che molto dipende dai contenuti specifici che si vogliono veicolare... detto questo, spero di non aver mai negato che sia un degno pretendente, anche se ho sollevato alcuni problemi nella sua adozione... senza che questo metta java automaticamente al primo posto, non essendo esente da problemi... a me interessa solo far notare come il linguaggio in sè sia secondario rispetto ai contenuti concettuali. tutto qua

mad_hhatter

08-10-2007, 10:43

Deformazione professionale. :p

si ti capisco :) ma qui non staimo dimostrando un teorema :D

cdimauro

08-10-2007, 13:54

che abbia senso è naturale, che sia prioritaria è molto discutibile...
Se devi iniziare una scelta sei obbligato comunque a farla.
che python sia piuttosto adatto non lo discuto, non concordo invece sul fatto che sia il più adatto, perché ripeto che molto dipende dai contenuti specifici che si vogliono veicolare...
Beh, per iniziare e per quanto riguarda i corsi che vengono trattati all'università Python può essere usato praticamente ovunque, grazie alla sua flessibilità e il vasto campo d'utilizzo.
detto questo, spero di non aver mai negato che sia un degno pretendente, anche se ho sollevato alcuni problemi nella sua adozione... senza che questo metta java automaticamente al primo posto, non essendo esente da problemi...
Complessivamente Python mi sembra la soluzione migliore.

Eckel ha trattato diversi punti, fra cui anche quelli di cui hai parlato, per cui t'invito a leggerti quei link.

Anche Guido van Rossum, il creatore di Python, ne ha parlato in un'altra intervista sempre nello stesso sito e se hai tempo ti consiglio di leggere pure quella.
a me interessa solo far notare come il linguaggio in sè sia secondario rispetto ai contenuti concettuali. tutto qua
La teoria da sola non serve a niente: l'informatica richiede, e non poco, la sperimentazione, e quindi una scelta va comunque fatta.

Python ha il vantaggio non indifferente di poter smanettare grazie al suo interprete interattivo, quindi di provare immediatamente quel che ci frulla per la testa.

Io lo uso molto spesso per modellare "al volo" una soluzione a un problema, e dopo che ho la prova che il tutto funziona come penso, ricopio quello che ho scritto e lo incollo nel sorgente in cui mi serve.

Non hai idea di quanto sia comodo e produttivo quest'approccio: è impagabile.
si ti capisco :) ma qui non staimo dimostrando un teorema :D
Vero, ma c'è un problema di cui stiamo discutendo e come programmatore tendo a fornire una soluzione in maniera piuttosto precisa. ;)

mad_hhatter

08-10-2007, 14:42

Se devi iniziare una scelta sei obbligato comunque a farla.

è comune scegliere un linguaggio e portare avanti la teoria basandosi su quel linguaggio... ma la teoria è al di là delle specifiche incarnazioni (= linguaggi). Guardando l'educazione che mi è stata impartita avrei preferito di gran lunga aver avuto una panoramica esaustiva dei paradigmi di programmazione, delle basi concettuali comuni ai vari linguaggi (ad esempio, teoria del paradigma OO), e solo dopo vedere questi principi applicati... viceversa si tende a identificare un concetto astratto con l'implementazione che ne viene data in un dato linguaggio e questo per molti versi è penalizzante... capisco che come approccio è molto complesso, ma col senno di poi avrei preferito una formazione più concettuale (o almeno, ancora più concettuale). ma capisco che possa non essere condivisibile.

Beh, per iniziare e per quanto riguarda i corsi che vengono trattati all'università Python può essere usato praticamente ovunque, grazie alla sua flessibilità e il vasto campo d'utilizzo.

Complessivamente Python mi sembra la soluzione migliore.

capisco il tuo punto di vista, l'unica cosa che contesto è che python sia l'unica scelta buona. probabilmente è miope da parte mia, ma continuo a vedere il typesystem dinamico rischioso per chi comincia da zero e non sa esattamente cosa sta facendo...

Eckel ha trattato diversi punti, fra cui anche quelli di cui hai parlato, per cui t'invito a leggerti quei link.

avevo iniziato a leggerlo, prima e indipendentemente dalla discussione che staimo affrontando, ma per motivi di tempo non avevo concluso la lettura... è un'altra delle decine di cose che ammasso nei miei memorandum delle cose da fare con urgenza :D

anzi, se mi riposti il link del post di eckel e di guido te ne sarei grato, giusto per non dovermi rispolverare il thread :D

La teoria da sola non serve a niente: l'informatica richiede, e non poco, la sperimentazione, e quindi una scelta va comunque fatta.

concordo, ma solo in parte... va beh, l'avrai capito: sono un patito dell'astrattismo concettuale :D e non condivido sempre il motto "prima le cose (apparentemente) semplici".

Python ha il vantaggio non indifferente di poter smanettare grazie al suo interprete interattivo, quindi di provare immediatamente quel che ci frulla per la testa.

Io lo uso molto spesso per modellare "al volo" una soluzione a un problema, e dopo che ho la prova che il tutto funziona come penso, ricopio quello che ho scritto e lo incollo nel sorgente in cui mi serve.

Non hai idea di quanto sia comodo e produttivo quest'approccio: è impagabile.

io invece trovo che per buttar giù un'abbozzo di soluzione ilo computer sia ancora troppo limitante e mi affido quasi sempre a carta e penna...
eventualmente apsso poi per un prototipo.

Vero, ma c'è un problema di cui stiamo discutendo e come programmatore tendo a fornire una soluzione in maniera piuttosto precisa. ;)

beh, come dicevi tu, questo è uno di quei casi in cui perdersi nei dettagli può essere controproducente :D scherzo, ma immagino tu abbia capito cosa intendo :)

cdimauro

08-10-2007, 20:05

è comune scegliere un linguaggio e portare avanti la teoria basandosi su quel linguaggio... ma la teoria è al di là delle specifiche incarnazioni (= linguaggi). Guardando l'educazione che mi è stata impartita avrei preferito di gran lunga aver avuto una panoramica esaustiva dei paradigmi di programmazione, delle basi concettuali comuni ai vari linguaggi (ad esempio, teoria del paradigma OO), e solo dopo vedere questi principi applicati... viceversa si tende a identificare un concetto astratto con l'implementazione che ne viene data in un dato linguaggio e questo per molti versi è penalizzante... capisco che come approccio è molto complesso, ma col senno di poi avrei preferito una formazione più concettuale (o almeno, ancora più concettuale). ma capisco che possa non essere condivisibile.
Anche perché i programmi non sono teoria, ma pratica. ;)

Già sviluppare delle applicazioni è difficile e usualmente subentrano quelle cose fastidiosissime chiamate bug: figuriamoci se ci limitassimo soltanto alla teoria.

Poi non so quanto resisterebbe uno qualunque che inizia da zero a imparare a programmare, limitandosi alla sola teoria: farebbe il botto in poco tempo.
capisco il tuo punto di vista, l'unica cosa che contesto è che python sia l'unica scelta buona.
Non ho detto che è l'unica, ma trovo che sia la migliore per quanto riguarda lo scopo prefisso.
probabilmente è miope da parte mia, ma continuo a vedere il typesystem dinamico rischioso per chi comincia da zero e non sa esattamente cosa sta facendo...
Proprio perché parte da zero farà meno danni: gli mancano le informazioni per pacioccare col codice indiscriminatamente. :D

Comunque di questo, come ti dicevo, ne parlano bene Eckel e van Rossum.
avevo iniziato a leggerlo, prima e indipendentemente dalla discussione che staimo affrontando, ma per motivi di tempo non avevo concluso la lettura... è un'altra delle decine di cose che ammasso nei miei memorandum delle cose da fare con urgenza :D

anzi, se mi riposti il link del post di eckel e di guido te ne sarei grato, giusto per non dovermi rispolverare il thread :D
Certamente. Per Eckel:
http://www.artima.com/intv/aboutme.html
http://www.artima.com/intv/prodperf.html
http://www.artima.com/intv/typing.html
http://www.artima.com/intv/tipping.html

Per van Rossum trovi tutti i link qui http://www.artima.com/intv/guido.html
concordo, ma solo in parte... va beh, l'avrai capito: sono un patito dell'astrattismo concettuale :D e non condivido sempre il motto "prima le cose (apparentemente) semplici".
OK, però cerca di immedesimarti nel tipo comune. Non so se hai avuto esperienze d'insegnamento, ma con la sola teoria non si va molto avanti.
io invece trovo che per buttar giù un'abbozzo di soluzione ilo computer sia ancora troppo limitante e mi affido quasi sempre a carta e penna...
eventualmente apsso poi per un prototipo.
La carta e la penna le ho usate ben poche volte. A volte utilizzo dei file di testo per annotazioni e todo, ma in generale il mio approccio alla risoluzione di problema è costituito dalla seguenti (macro)fasi:
- meditazione sul problema e individuazione delle possibili soluzioni (è quella in cui spendo più tempo; in ciò sposo la tesi di Nikola Tesla, ribaltando la massima di Edison: il genio è il 99% ispirazione e l'1% traspirazione :p);
- stesura del codice, facendo ricorso a micro-modelli per i casi che devo trattare.
- testing / simulazione, possibilmente con dati reali.

Ovviamente si tratta di un processo iterativo che vede la loro ripetizione fino al raggiungimento dello scopo.

Da un po' di tempo le ultime due fasi tendo a "fonderle", scrivendo dei test e/o delle applicazioni "di controllo" (questo avviene quando l'applicazione è un server; in questo caso sviluppo sempre parallelamente una o più applicazioni client che testano tutte le API del server, una a una, con dati reali o inventati appositamente).

Per come procedo, come dicevo prima, Python mi è estremamente utile perché mi permette di modellizzare velocemente il problema (ed eventuali sottoproblemi), producendo e testando anche il codice allo stesso tempo, grazie all'interprete interattivo.
beh, come dicevi tu, questo è uno di quei casi in cui perdersi nei dettagli può essere controproducente :D scherzo, ma immagino tu abbia capito cosa intendo :)
Onestamente no. :( Sarà perché non ricordo ciò di cui stai parlando, sarà per la giornata pesante, ma non ci sono arrivato.

cdimauro

08-10-2007, 20:11

:mbe:
di meno :fagiano:
Con la trasformata di fourier approssimi il segnale reale con una serie di armoniche che per essere completamente corrispondente al segnale originale dovrebbe tendere ad infinito.
Ovviamente nella realtà si approssima BEN prima di infinito, ma cmq rappresentare ad esempio un'onda quadra nel dominio di fourier degrada abbastanza le informazioni contenute nel segnale originario :p
Era soltanto un esempio per far capire che passando da una base a un'altra il segnale si conserva!!! :p

Poi è che chiaro nel mondo reale le cose sono diverse. ;)

cdimauro

08-10-2007, 20:13

a me personalmente piace + di python :p
:yeah:
Poi ovviamente dipende da quello ke ci devi fare..
per stringhe e accesso ai file preferisco python, per programmazione di rete preferisco ruby :D
Mumble mumble: eppure Python ha un'ottima dotazione (nella libreria standard) anche per questo campo.

cdimauro

08-10-2007, 20:15

Perchè in java non si utilizzano? :fagiano:
java.util.List e java.util.Map cosa sono? :mbe:
Non sono semplici e versatili come gli equivalenti di Python, e devi ricorrere alla libreria standard per usarli. ;)

PGI-Bis

08-10-2007, 20:27

penso sia un bene come lo è in tutti gli altri campi di espressione linguistica (a parte la politica, dove + si fanno giri di parole senza dire niente e + si appare dotati di personalità e dialettica).
Se si è concisi, a patto come diceva Cesare di essere anche chiari, ci si focalizza sulle idee da esporre senza tanti fronzoli.

"Il dono della sintesi", così lo chiamano no? :)

D'accordo ma... perchè? Lo chiedo non per pedanteria ma per vero interesse. Dici che è meglio essere concisi a patto di essere chiari. Dunque c'è un limite alla sintesi? Se c'è quale sarebbe e perchè dovrebbe esserci?

Nelle versioni successive il problema di presentare, in un pezzo di codice banale qual'è un HelloWorld, strutture che vengono accantonate temporaneamente, mi pare rimanga.
E sarà sempre così a meno che Java non diventi un'altra cosa, che non sia Java.

E questo nella didattica, come ho avuto modo di scrivere + volte, non credo sia il massimo per chi ha voglia di addentrarsi nella programmazione.

Non ho mai negato che Python richiedesse meno codice per produrre lo stesso risultato. Anzi, credo di averlo dato per scontato, sulla fiducia. Dico invece che la maggior parte della sintassi di Java è già presente nell'Hello World e si tratta di una parte necessaria e sufficiente a creare sistemi articolati, nel senso di composti da una pluralità di definizioni. Dico che questo è vantaggioso perchè costringe ad apprendere sin dal primo istante delle forme sintattiche che costituiranno la norma in tutto il resto del percorso formativo sia in Java (classe, metodo) sia nell'orientamento agli oggetti (la classe Java è il mezzo attraverso cui si esprime una definizione). L'hello world di Python usa qualcosa di cui è ignota la natura e la struttura. "print" potrebbe benissimo essere il nome di un operatore elementare su un registro di memoria: "chi è che" print? Potrebbe essere il nome di un comportamento di "hello world"? E' così? "print" è un messaggio di [string]?

Stroustrup lo includiamo nella scuola scandinava?
Perchè non mi risulta sia concorde con questa classificazione.

Stroustrup presentò la sua idea di orientamento agli oggetti nel classico "what is object orientation", pienamente realizzata in C++ se non altro a testimoniare il fatto che egli non soffrisse all'epoca di personalità multipla. Non è l'unica idea di orientamento agli oggetti esistente. Basta una rapida occhiata a The Early History of Smalltalk, di Alan Kay, o Object Oriented Programming in The BETA programming language, di K. Nygaard, per vederne le differenze. Ricordo, brevemente, che la differenza tra l'ederitarietà scandinava e l'ereditarietà americana sta in ciò che per la prima è ereditabile esclusivamente la dichiarazione mentre per la seconda è lo è anche la definizione. Java è "scandinavo" nel momento in cui le interfacce consentono unicamemente il trasferimento dell'insieme di dichiarazioni che formano il contratto (pubblico) espresso nell'interfaccia ereditata ed è "americano" rispetto all'ereditarietà tra classi, con l'intermezzo "bastardo" delle classi astratte.

La ragione per cui Java non possiede l'estensibilità multipla è piuttosto banale: non hanno voluto introdurre una regola in più per decidere quale tra due definizioni superiori avrebbe dovuto essere ereditata dalla definizione inferiore. Essendo le interfacce prive di definizione il problema non si pone (in accordo all'ereditarietà scandinava).

Predicare che la portabilità di Java sia un falso mito significa avere in mano le carte per poterlo dimostrare. Specifiche alla mano, quali norme del linguaggio di programmazione Java ne limiterebbero la portabilità? Ripetere per la Java Virtual Machine. Intendiamo[ci], è possibilissimo che non lo sia e con la massima umiltà chiedo: perchè? Immagino che neppure qui otterrò risposta.

Al di là del fatto che trovo i punti + che condivisibili, non mi pare i suoi libri siano così confusi.
Thinkin' in Java l'ho trovato un buon libro e non meno "confuso" dei tanti che trattano il medesimo argomento.

Cmq sarei ben felice di trovarne di meglio, chessò magari scritti di tuo pugno, così da poter constatare le differenze.

Thinking in Java è un pessimo libro sull'orientamento agli oggetti ed un'orrenda opera sul linguaggio di programmazione Java. La ragione per cui io non scrivo un libro sull'orientamento agli oggetti è che non ho ancora pienamente preso posizione circa un bivio che la prospettiva orientata agli oggetti propone quasi immediatamente, vale a dire se la dipendenza di definizione sia una relazione univoca o biunivoca. Per non sembrare più oscuro del necessario ripeto qui quanto affermai in un'altra discussione: la definizione di oggetto nella prospettiva orientata agli oggetti è "definizione autonoma di una porzione di un universo reale o immaginario" dove "autonoma" è quella definizione che non ne assuma altre come parte di sè. Arrivo a questa definizione partendo da un ipotetico punto di vista umano nella rappresentazione dei fenomeni che c'entra con la programmazione essendo quest'ultima l'attività di rappresentazione della soluzione di un problema in una forma riproducibile attraverso un calcolatore. E mi fermo qui per evitare di scrivere il libro che non posso (ancora) scrivere.

^TiGeRShArK^

08-10-2007, 23:36

:yeah:

Mumble mumble: eppure Python ha un'ottima dotazione (nella libreria standard) anche per questo campo.

tranquillo che l'ho provato python per quello che mi serviva..
ma ho risolto prima con ruby :D
questa può significare due cose:
a) ruby era migliore di python per quello che mi serviva
b) la documentazione di ruby migliore di quella di python e sono riuscito a scrivere quello che mi serviva con uno sforzo minore
Probabilmente la risposta corretta è la seconda..
ma ammetto che questo non è che va proprio a favore di python :D

P.S. Hai visto il thread della cena dei siciliani in piazzetta? :O
magari dopo il nubifragio dell'anno scorso a milano potremmo riuscire finalmente ad incontrarci visto che ritorno definitivamente a RC :D

cdimauro

09-10-2007, 07:59

D'accordo ma... perchè? Lo chiedo non per pedanteria ma per vero interesse. Dici che è meglio essere concisi a patto di essere chiari. Dunque c'è un limite alla sintesi? Se c'è quale sarebbe e perchè dovrebbe esserci?
a = {'Qui': 1, 'Quo': 2, 'Qua' : 3}

Esprime un concetto ben preciso, in maniera chiara e compatta.
Prova a tradurre lo stesso concetto in un altro linguaggio: Java, SmallTalk, e perfino in assembly / linguaggio macchina.

Cos'è cambiato? La forma, perché il concetto è rimasto esattamente lo stesso.

Qual è la differenza rispetto al codice di cui sopra? Che per esprimere la stessa cosa sono state richieste diverse linee di codice (in particolare con assembly / linguaggio macchina il listato sarebbe piuttosto lungo) che portano a:
- maggior possibilità di bug;
- dispersività nella rappresentazione e comprensione del concetto.

Se vuoi una definizione formale di quello che ho detto non te la posso dare, perché sai bene che nel campo della programmazione si va spesso per esperienza / "best practices". Un po' come quando si afferma che la programmazione orientata è una "cosa buona e giusta".
Non ho mai negato che Python richiedesse meno codice per produrre lo stesso risultato. Anzi, credo di averlo dato per scontato, sulla fiducia. Dico invece che la maggior parte della sintassi di Java è già presente nell'Hello World e si tratta di una parte necessaria e sufficiente a creare sistemi articolati, nel senso di composti da una pluralità di definizioni. Dico che questo è vantaggioso perchè costringe ad apprendere sin dal primo istante delle forme sintattiche che costituiranno la norma in tutto il resto del percorso formativo sia in Java (classe, metodo) sia nell'orientamento agli oggetti (la classe Java è il mezzo attraverso cui si esprime una definizione).
Opinabile. Io preferisco iniziare dai mattoncini basilari per poi arrivare a quelli più complessi, anziché trovarmi di botto un bel po' di nuovi concetti e sentirmi dire: "per adesso devi fare così, perché queste cose poi le affronteremo più avanti".
L'hello world di Python usa qualcosa di cui è ignota la natura e la struttura. "print" potrebbe benissimo essere il nome di un operatore elementare su un registro di memoria: "chi è che" print? Potrebbe essere il nome di un comportamento di "hello world"? E' così? "print" è un messaggio di [string]?
E' un'istruzione, al pari di if, while, for, ecc. che non sono riconducibili a nessun "operatore elementare" o "messaggio" attribuibile a qualche oggetto. Dunque la sua presenza e il suo utilizzo mi sembrano del tutto leciti.

Comunque a partire da Python 3.0 diventerà una funzione come le altre built-in che offre il linguaggio, perché ci sono dei vantaggi non indifferenti nell'averla definita come tale (c'è un documento scritto da Guido van Rossum in proposito che espone le motivazioni).
Questo per sottolineare che, a differenza di linguaggi come Java, la comunità Python non si fa problemi a rompere la compatibilità col passato pur di avere a disposizione un linguaggio che rispecchia una precisa "filosofia".
Stroustrup presentò la sua idea di orientamento agli oggetti nel classico "what is object orientation", pienamente realizzata in C++ se non altro a testimoniare il fatto che egli non soffrisse all'epoca di personalità multipla. Non è l'unica idea di orientamento agli oggetti esistente. Basta una rapida occhiata a The Early History of Smalltalk, di Alan Kay, o Object Oriented Programming in The BETA programming language, di K. Nygaard, per vederne le differenze. Ricordo, brevemente, che la differenza tra l'ederitarietà scandinava e l'ereditarietà americana sta in ciò che per la prima è ereditabile esclusivamente la dichiarazione mentre per la seconda è lo è anche la definizione. Java è "scandinavo" nel momento in cui le interfacce consentono unicamemente il trasferimento dell'insieme di dichiarazioni che formano il contratto (pubblico) espresso nell'interfaccia ereditata ed è "americano" rispetto all'ereditarietà tra classi, con l'intermezzo "bastardo" delle classi astratte.

La ragione per cui Java non possiede l'estensibilità multipla è piuttosto banale: non hanno voluto introdurre una regola in più per decidere quale tra due definizioni superiori avrebbe dovuto essere ereditata dalla definizione inferiore. Essendo le interfacce prive di definizione il problema non si pone (in accordo all'ereditarietà scandinava).
Al di là del fatto che è evidente che non esiste un solo modo di definire cosa sia la programmazione a oggetti, secondo te è un bene o un male il fatto che Java non abbia abbracciato l'ereditarietà multipla?

Concordi, poi, che l'approccio "tradizionale" alla modellazione della realtà facendo uso di oggetti si è rivelato fallimentare?
Predicare che la portabilità di Java sia un falso mito significa avere in mano le carte per poterlo dimostrare. Specifiche alla mano, quali norme del linguaggio di programmazione Java ne limiterebbero la portabilità?
Nessuna.
Ripetere per la Java Virtual Machine. Intendiamo[ci], è possibilissimo che non lo sia e con la massima umiltà chiedo: perchè? Immagino che neppure qui otterrò risposta.
Questa http://java.sun.com/docs/books/tutorial/extra/fullscreen/index.html quando ho lavorato a Diamonds funzionava soltanto con Windows. Su Linux non andava, e non perché mancasse adeguata accelerazione video.

A parte questo, le implementazioni per Windows x64 non sono complete: mancano delle librerie / funzionalità, e ciò mi ha costretto a dover installare sempre la versione a 32 bit.
Non so se la situazione sia cambiata dall'ultima volta che ho controllato.
Thinking in Java è un pessimo libro sull'orientamento agli oggetti ed un'orrenda opera sul linguaggio di programmazione Java.
Esiste qualche altra opera meritevole?
La ragione per cui io non scrivo un libro sull'orientamento agli oggetti è che non ho ancora pienamente preso posizione circa un bivio che la prospettiva orientata agli oggetti propone quasi immediatamente, vale a dire se la dipendenza di definizione sia una relazione univoca o biunivoca. Per non sembrare più oscuro del necessario ripeto qui quanto affermai in un'altra discussione: la definizione di oggetto nella prospettiva orientata agli oggetti è "definizione autonoma di una porzione di un universo reale o immaginario" dove "autonoma" è quella definizione che non ne assuma altre come parte di sè. Arrivo a questa definizione partendo da un ipotetico punto di vista umano nella rappresentazione dei fenomeni che c'entra con la programmazione essendo quest'ultima l'attività di rappresentazione della soluzione di un problema in una forma riproducibile attraverso un calcolatore. E mi fermo qui per evitare di scrivere il libro che non posso (ancora) scrivere.
Scusa l'ignoranza, ma non ho colto il significato della "dipendenza di definizione".

cdimauro

09-10-2007, 08:05

tranquillo che l'ho provato python per quello che mi serviva..
Immagino. :)
ma ho risolto prima con ruby :D
questa può significare due cose:
a) ruby era migliore di python per quello che mi serviva
b) la documentazione di ruby migliore di quella di python e sono riuscito a scrivere quello che mi serviva con uno sforzo minore
Probabilmente la risposta corretta è la seconda..
ma ammetto che questo non è che va proprio a favore di python :D
Non so che dire. Con Python ho avuto la necessità di lavorare soltanto con HTTP/HTTPs, FTP/sFTP, parsing di pagine HTML e di XML, e mi sono sbrigato molto in fretta.
P.S. Hai visto il thread della cena dei siciliani in piazzetta? :O
magari dopo il nubifragio dell'anno scorso a milano potremmo riuscire finalmente ad incontrarci visto che ritorno definitivamente a RC :D
Non seguo la piazzetta; al più leggo qualche pagina di cui viene postato il link nel dark side. :D Comunque vado a buttarci un occhio.

Quando scendi mi farebbe piacere incontrarci, visto che è da un pezzo che rimandiamo. :)

cdimauro

09-10-2007, 08:15

cmq tornando serio per un attimo.. (in effetti sto facendo uno sforzo incommensurabile x essere serio :D)
Secondo me vale sempre il classico (appena citato tra l'altro :D) "The right tool for the right job" :p
Per progetti di dimensioni medio-grandi (x la mia esperienze e x come vedo io i progetti medio grandi... ovvero sopra le 100k LOC) Java è meglio di python xkè già in compilazione evita di fare cazzate assurde con i tipi,
Beh, c'è da dire intanto che 100mila righe di codice in Python e in Java non sono proprio la stessa cosa :p, comunque sui tipi è vero che si possono introdurre degli errori a causa della mancanza del controllo statico, ma è anche vero che aumentano enormemente la produttività e la possibilità di avere in tempi brevi un modello che consente di effettuare dei test con dati reali (o creati ad arte) e di individuare velocemente anche eventuali bug introdotti dal "weak typing" di Python.

In ogni caso non vedo problemi a gestire progetti anche con più di 100mila righe di codice in Python. Anzi, il fatto di avere codice compatto e chiaro per me lo pone in un netto vantaggio proprio per questioni di manutenibilità.
xkè alla fine costringe a strutturare il progetto in una maniera ben ordinata (sopratutto usando tools come maven),
Non lo conosco. Per la struttura del progetto, la modularizzazione del codice offerta da Python permette di costruire una gerarchia in maniera molto simile a Java.
xkè lo stile del codice può anche risultare migliore di quello di python usando gli strumenti giusti (ricordate il caro vecchio checkstyle che tanto mi ha fatto bestemmiare, vero? :asd: )
Appunto: ha fatto bestemmiare e non poco. Quanto allo stile del codice, preferisco decidere da me: non mi trovo assolutamente nel dover definire le classi con la prima maiuscola e le istanze (e i metodi) con la minuscola invece; è una forzatura che non condivido.
e sopratttto xkè alla fine x il supporto, la documentazione e l'aiuto disponibile alla comunità Java, soprattutto nel caso di bug critici in produzione non ha eguali confrontata con la comunità di python (sempre x quel poco che ho potuto vedere durante la mia esperienza :p).
Posso assicurarti che la comunità Python è mooooolto attiva e disponibile. :)

Sulla documentazione, non sarà ottima come quella di Java, ma almeno non è incasinata e dispersiva. :D
Però, sempre per quello che ho vissuto finora, non avrei alcuna esitazione a consiglire python come linguaggio per iniziare a programmare...
Imho più un linguaggio è ad alto livello e + permette al programmatore di concentrarsi sugli algoritmi.
E alla fine, parlandoci chiaro, sono quelli la vera parte essenziale della programmazione.
Oltre alla forma mentis ovviamente :p
Un linguaggio che permette di concentrarsi sui concetti + che sulle righe di codice "inutili" permette di imparare meglio le cose necessarie.
Perfettamente d'accordo, ed è quello che ribadiamo da un pezzo. :p
L'unica pecca davvero grave che trovo in python è la mancanza di una documentazione adeguata :muro:
Cioè, a parte gli ottimi manuali utilizzati per apprendere le basi del linguaggio, poi ci si deve smenare davvero troppo per capire come funziona una maledetta libreria.
E a quel punto, sinceramente, preferisco scrivere + codice in java, mettendoci + tempo, ma impiegando sicuramente meno che per cercare di capire che cacchio voleva fare l'autore di quella libreria con la documentazione criptica :p
Parli della libreria standard o di quelle "esterne"?
Concludendo...
il percorso ideale per me x iniziare sarebbe il seguente:
Python (o ruby o qualcosa di equivalente) --> Java --> all the rest :p
Io mi fermo a Python. :angel:

cdimauro

09-10-2007, 08:30

non sono daccordo sul fatto che più è alto il livello e meglio è.. anche in questo caso le motivazioni sono fragili.
E' da un pezzo che ne parliamo, ma non porti delle argomentazioni. Dicendo che sono fragili non hai portato nessun contributo alla discussione.
i linguaggi come java, python ecc.. permettono di fare in maniera molto più semplice cose abbastanza complesse da fare in linguaggi come C e pascal per esempio.
Bene, ti sei risposto da solo alle obiezioni di cui sopra. :p
ma quando uno inizia a programmare tipicamente i suoi programmi fanno cose abbastanza stupide come calcolare le soluzioni di un'equazione di secondo grado, calcolare l'ipotenusa dati i due cateti, classificare i triangoli, implementare nibbles :asd: ecc..
da questo punto di vista C e pascal sono semplicissimi da usare e ti permettono di introdurre solo i concetti strettamente necessari facendoti concentrare solamente sugli algoritmi e non sul colore della finestra, la disposizione dei pulsanti e altre inutilità varie. invece linguaggi come python e java ti sbattono in faccia sin dall'inizio concetti più avanzati come gli oggetti, le eccezioni ecc.. ovviamente IMHO
Ancora una volta dimostri di non aver capito nulla di Python.

Parli di "concetti più avanzati" quando le cose che hai descritto con Python le risolvi in maniera MOOOOLTO più semplice rispetto a C e Pascal, e te lo posso dimostrare quando voglio.

Mi chiedo quando imparerai a parlare soltanto di cose che conosci veramente. :rolleyes:

k0nt3

09-10-2007, 08:33

dimostralo pure allora.
io ho detto che le argomentazioni sono fragili in entrambi i sensi (perlomeno intendevo dire), quindi non sono daccordo con chi dice che più è alto il livello e meglio è

^TiGeRShArK^

09-10-2007, 09:59

A me sembra che in queste discussioni stia un po' sfuggendo il quadro di insieme.
Ed il quadro di insieme ci dice che Java è diventato obsoleto e superato in diversi campi applicativi.

ma anche no :D
Ad oggi la diffusione di java in ambito enterprise non ha eguali.
E non dimentichiamo la nuova linfa vitale fornita dalla grandissima base di utilizzatori, tra cui ad esempio il Google Web Toolkit, usato per applicativi quali Google Maps e che è anche capace di girare in modalità offline risolvendo così uno dei + annosi problemi di AJAX.
Quindi sinceramente tanto superato non mi pare :p

Negli anni 90, soprattutto la prima metà, è stato direi rivoluzionario con i suoi concetti, nella capacità di Sun di scorgere le potenzialità del World Wide Web prima degli altri e di approfittare del suo boom per veicolare la piattaforma Java nella quasi totalità dei computer (desktop) in giro per il mondo.

e ad oggi mi pare sinceramente MOLTO + probabile che su un comune pc sia installata una Java VM piuttosto che python o ruby :D

Si sono talmente seduti, che mentre nuovi linguaggi e metodologie di sviluppo prendevano piede (.NET, PHP, Python, Ruby...), il modello di Java e la sua architettura sono rimaste fondamentalmente sempre quelle, da quando Gosling e soci pubblicarono le prime specifiche.

Java e .Net si sono "scambiati" + volte caratteristiche e credo che continuino a farlo in futuro.
Ognuno cerca di prendere il meglio dal competitor e penso che salti subito agli occhi la grande similarità tra Java e C# :D

E ora il ritardo tecnologico accumulato è evidente. Talmente evidente che negli ultimi mesi, dopo anni di silenzio, abbiamo assistito alla presentazione di
- la convergenza verso l'Open Source
- JAX-WS 2.0, JAXB 2.0, JAXP e STAX (tutte specifiche volte a colmare le "lacune" in ambito AJAX)
- JavaFX: linguaggio di scripting server-side
- Quaere, l'alter-ego di LinQ (progetto NET che ha ormai quasi 3 anni), che quindi dovrebbe permettere la modellazione OO di accesso ad una base di dati

JavaFX è client side e le migliorie maggiori applicate ai web services secondo me sono state quelle fornite tramite le anotations :p
E quindi non vedo cosa ci sia di male a migliorare il linguaggio :D

Cominciamo per esempio dalla (annosa) questione dell'ereditarietà multipla.
CUT
io personalmente preferisco molto di + le interfacce all'ereditarietà mutipla :p

L'hype spropositato che si è generato in questi anni e che ha dato vita a falsi miti ( del calibro de "Java è portabile", "Java è multipiattaforma", "Java ha rimosso i difetti di C++ e quindi è virtualmente immune da difetti", oppure "la decadenza prestazionale, seppur sia un linguaggio interpretato, è ininfluente, rispetto ai benefici"), è scemato e gli sviluppatori, sia freelance che in seno alle aziende, hanno fatto scelte oculate che tenessero conto del rapporto costi/benefici, nel caso di un utilizzo della piattaforma Java.

bhè...
che Java sia portabile, multipiattaforma e che abbia rimosso diversi difetti del C++ credo sia innegabile.
Come è altrettanto innegabile che con l'avvento del JIT e l'abbandono definitivo dell'interprete della VM le prestazioni sono molto + vicine al C++ di quanto si pensi e cmq sono senz'altro molto superiori a python/ruby, SOPRATTUTTO quando si ha a che fare con i multi-core, che checchè se ne dica si stanno diffondendo moltissimo viste le varie riduzioni di prezzo di AMD e INTEL (e cmq parlando di applicazioni di una certa grandezza ovviamente).

(come appunto l'estensione di funzionalità tramite la semplice aggiunta di nuove librerie, per esempio nel caso dei dizionari)

Sono nel framework sin da java 1.2.
E x me java prima di quella versione non era propriamente ben fornito degli strumenti giusti.
E cmq non vedo il punto dato che anche in python sono state introdotte innumerevoli possibilità passando da una release alla successiva.
è la naturale evoluzione dei linguaggi e non mi pare proprio una cosa negativa.:p

cdimauro

09-10-2007, 10:51

dimostralo pure allora.
Certamente. Ecco qua:
print "Calcolo delle radici di un'equazione di secondo grado nella forma aX^2 + bX + c"
a = float(raw_input('Inserire il coefficiente a: '))
b = float(raw_input('Inserire il coefficiente b: '))
c = float(raw_input('Inserire il coefficiente c: '))
Delta = b ** 2 - 4 * a * c
RadiceDiDelta = complex(Delta) ** 0.5
x1 = (-b + RadiceDiDelta) / (2 * a)
x2 = (-b - RadiceDiDelta) / (2 * a)
print "Le soluzioni dell'equazione sono", x1, 'e', x2
il programmino per la risoluzione di un'equazione di secondo grado (poi possiamo passare anche agli altri esempi che hai fatto: io sono a disposizione).

Adesso fammi vedere come lo faresti in C o in Pascal, visto che sostenevi che "sono semplicissimi da usare e ti permettono di introdurre solo i concetti strettamente necessari facendoti concentrare solamente sugli algoritmi".
io ho detto che le argomentazioni sono fragili in entrambi i sensi (perlomeno intendevo dire), quindi non sono daccordo con chi dice che più è alto il livello e meglio è
Continui a parlare di "fragilità", ma a non portare niente come argomentazione. Aria fritta insomma.

Vatti a rileggere tutto quello che abbiamo scritto e, se hai qualcosa da dire, quota e contesta pure.

^TiGeRShArK^

09-10-2007, 12:39

il fatto di conoscere un linguaggio non implica che l'utilizzo di un qualsiasi altro linguaggio sia semplice e immediato
se la documentazione è sufficientemente buona e si è appresa a dovere la programmazione ad oggetti allora si, dovrebbe essere semplice e immediato.
O almeno x me di solito è così.
Certo tra l'iniziare a programmare in un linguaggio e saperlo usare al meglio ce ne passa, ma quantomeno le basi dovrebbero essere di immediata comprensione.

k0nt3

09-10-2007, 13:54

Certamente. Ecco qua:
print "Calcolo delle radici di un'equazione di secondo grado nella forma aX^2 + bX + c"
a = float(raw_input('Inserire il coefficiente a: '))
b = float(raw_input('Inserire il coefficiente b: '))
c = float(raw_input('Inserire il coefficiente c: '))
Delta = b ** 2 - 4 * a * c
RadiceDiDelta = complex(Delta) ** 0.5
x1 = (-b + RadiceDiDelta) / (2 * a)
x2 = (-b - RadiceDiDelta) / (2 * a)
print "Le soluzioni dell'equazione sono", x1, 'e', x2
il programmino per la risoluzione di un'equazione di secondo grado (poi possiamo passare anche agli altri esempi che hai fatto: io sono a disposizione).

non gestisci la divisione per 0 e poi sono sufficienti le radici reali nel caso di delta minore di 0 (anche se non lo avevo specificato era sottointeso). tipicamente infatti è un esempio utile per via del fatto che si imparano a usare le condizioni (se il delta è minore ecc..)
per il resto niente da dire a parte che raw_input come dice il termine stesso è grezzo :asd:

Adesso fammi vedere come lo faresti in C o in Pascal, visto che sostenevi che "sono semplicissimi da usare e ti permettono di introdurre solo i concetti strettamente necessari facendoti concentrare solamente sugli algoritmi".
in C o in pascal scrivi giusto in paio di righe in più, ma la differenza è che dichiari le variabili con il loro tipo e le istruzioni fanno una cosa alla volta (non come raw_input che scrive sullo schermo e prende in input dei caratteri).
per me rimane preferibile il pascal però, perchè con il C bisognerebbe usare già i puntatori. il problema del python è che come tu stesso hai detto tutto è un oggetto, solo che questo non è visibile al programmatore (almeno in un primo momento)

Continui a parlare di "fragilità", ma a non portare niente come argomentazione. Aria fritta insomma.

Vatti a rileggere tutto quello che abbiamo scritto e, se hai qualcosa da dire, quota e contesta pure.
qua è tutta aria fritta dalla prima all'ultima pagina, solo voi non l'avete capito

mad_hhatter

09-10-2007, 14:02

se la documentazione è sufficientemente buona e si è appresa a dovere la programmazione ad oggetti allora si, dovrebbe essere semplice e immediato.
O almeno x me di solito è così.
Certo tra l'iniziare a programmare in un linguaggio e saperlo usare al meglio ce ne passa, ma quantomeno le basi dovrebbero essere di immediata comprensione.

perfettamente d'accordo, era quello che intendevo

cdimauro

09-10-2007, 14:30

non gestisci la divisione per 0
Dalle mie parti un'equazione di secondo grado non può avere il coefficiente pari a 0. :rolleyes:
e poi sono sufficienti le radici reali nel caso di delta minore di 0 (anche se non lo avevo specificato era sottointeso).
Le radici reali ci sono soltanto se il delta è maggiore o uguale a 0.

Quelle complesse sono ugualmente le radici dell'equazione.
tipicamente infatti è un esempio utile per via del fatto che si imparano a usare le condizioni (se il delta è minore ecc..)
Le condizioni s'imparano a usare subito? Non mi pare.

Quello che ho postato è una soluzione perfettamente valida al problema:

"Calcolo delle radici di un'equazione di secondo grado nella forma aX^2 + bX + c"

com'era chiaramente attestato nella prima riga del codice.

Non c'erano altri vincoli, se non che l'equazione dev'essere di secondo grado.

Quindi le soluzioni complesse erano incluse, visto che sono soluzioni dell'equazione; non era specificato da nessuna parte che avrei dovuto estrarre soltanto quelle reali.
per il resto niente da dire a parte che raw_input come dice il termine stesso è grezzo :asd:
scanf invece è di una chiarezza estrema, vero? :rolleyes:

Comunque sempre per la tua gioia raw_input() diventerà input() in Python 3.0 (sempre se non ricordo male).

Prova a chiedere al comitato dell'ANSI C se cambiano scanf() in inputf() o simile...
in C o in pascal scrivi giusto in paio di righe in più, ma la differenza è che dichiari le variabili con il loro tipo e le istruzioni fanno una cosa alla volta (non come raw_input che scrive sullo schermo e prende in input dei caratteri).
Non ci sarebbe soltanto quella differenza. Prova a realizzare l'equivalente del programma che ho postato, in C e Pascal, e poi ne riparliamo...
per me rimane preferibile il pascal però, perchè con il C bisognerebbe usare già i puntatori.
Ah, adesso rottamiamo pure il C, che era fra quelli "migliori" per risolvere questo tipo di problema. Vabbé... :rolleyes:
il problema del python è che come tu stesso hai detto tutto è un oggetto, solo che questo non è visibile al programmatore (almeno in un primo momento)
Ti ho già spiegato cosa significa "paradigma di programmazione" applicato a Python, diversi messaggi fa.
qua è tutta aria fritta dalla prima all'ultima pagina, solo voi non l'avete capito
Dimostralo: comincia a quotare le parti che sarebbero aria fritta, confutandole.

^TiGeRShArK^

09-10-2007, 14:33

non gestisci la divisione per 0 e poi sono sufficienti le radici reali nel caso di delta minore di 0 (anche se non lo avevo specificato era sottointeso). tipicamente infatti è un esempio utile per via del fatto che si imparano a usare le condizioni (se il delta è minore ecc..)
per il resto niente da dire a parte che raw_input come dice il termine stesso è grezzo :asd:

:mbe:
ehmm..
veramente non ci sono divisioni per zero se l'equazione è nella forma ax^2 + bx + c :fagiano:

qua è tutta aria fritta dalla prima all'ultima pagina, solo voi non l'avete capito
perchè aria fritta?
in C ti saresti fatto 2 palle così a scrivere quel codice...
o no? :stordita:

cdimauro

09-10-2007, 14:37

No, perché C e Pascal "sono semplicissimi da usare e ti permettono di introdurre solo i concetti strettamente necessari facendoti concentrare solamente sugli algoritmi". :asd:

k0nt3

09-10-2007, 17:41

:mbe:
ehmm..
veramente non ci sono divisioni per zero se l'equazione è nella forma ax^2 + bx + c :fagiano:

perchè aria fritta?
in C ti saresti fatto 2 palle così a scrivere quel codice...
o no? :stordita:

niente vieta di assegnare il valore 0 al coefficiente a, perciò la divisione per zero ci può essere.
è aria fritta perchè l'ho già spiegato che la scelta del linguaggio con cui iniziare non è una cosa oggettiva. inoltre anche volendo non si può fare un confronto tra linguaggi perchè non ci è dato sapere quali caratteristiche sono bene e quali sono male, e nel caso quanto bene e quanto male. ogni linguaggio è un opportuno compromesso di caratteristiche ed è inevitabile visto che molte caratteristiche sono in contrasto fra loro.

ecco le due palle che mi sono fatto :D

#include <stdio.h>
#include <math.h>

int main()
{
float a, b, c;
float delta;

printf("Calcolo delle radici di un'equazione di secondo grado nella forma aX^2 + bX + c\n");
printf("inserire il coefficiente a: ");
scanf("%f", &a);
printf("inserire il coefficiente b: ");
scanf("%f", &b);
printf("inserire il coefficiente c: ");
scanf("%f", &c);

delta = b*b-4*a*c;

if(delta < 0)
{
printf("l'equazione non ha soluzioni reali");
}
else if(delta == 0)
{
float x = -b/(2*a);
printf("l'equazione ha un'unica soluzione reale: %f", x);
}
else
{
float x1 = (-b-sqrt(delta))/(2*a);
float x2 = (-b+sqrt(delta))/(2*a);
printf("l'equazione ha due soluzioni reali: %f e %f", x1, x2);
}

return 0;
}

un programmatore sta cosa se la mangia a colazione :asd: più righe ma il risultato è diverso, anche perchè imparare a programmare non è fare la gara a chi scrive meno righe. altrimenti avrei fatto così (vi risparmio la soluzione su una riga :p ):

#include <stdio.h>
#include <math.h>

int main()
{
float a, b, c;
printf("Calcolo delle radici di un'equazione di secondo grado nella forma aX^2 + bX + c\ninserire il coefficiente a: ");
scanf("%f", &a);
printf("inserire il coefficiente b: ");
scanf("%f", &b);
printf("inserire il coefficiente c: ");
scanf("%f", &c);
printf("le soluzioni sono: %f e %f", (-b-sqrt(b*b-4*a*c))/(2*a), (-b+sqrt(b*b-4*a*c))/(2*a));
}

a voi sembra difficile?
il pascal è preferibile per il solo fatto di non richiedere l'uso del puntatore, ma sono dettagli

PGI-Bis

09-10-2007, 18:40

a = {'Qui': 1, 'Quo': 2, 'Qua' : 3}

Esprime un concetto ben preciso, in maniera chiara e compatta.

Togliamo "ben preciso", "in maniera chiara" e "compatta" perchè non vuol dir nulla. Resta "esprime un concetto". E questo non lo revoco in dubbio.

Prova a tradurre lo stesso concetto in un altro linguaggio: Java, SmallTalk, e perfino in assembly / linguaggio macchina.

Cos'è cambiato? La forma, perché il concetto è rimasto esattamente lo stesso.

Io la vedo un pelo diversa. In assembly cambia la prospettiva, in Smalltalk è identico, in Java, per fortuna, manca una sintassi speciale e si interviene a colpi di invocazioni di metodo su un oggetto.

Qual è la differenza rispetto al codice di cui sopra? Che per esprimere la stessa cosa

Altro è l'effetto di quella parte del programma altro è ciò che è necessario comunicare per ottenerlo.

sono state richieste diverse linee di codice (in particolare con assembly / linguaggio macchina il listato sarebbe piuttosto lungo) che portano a:
- maggior possibilità di bug;

La quantità di codice non è direttamente correlata alla quantità di bug. E posso anche provare a convincertene. Scrivi per cento volte

print "hello world"

Quanti bug ci sono in quelle cento linee? Induttivamente, se ti chiedessi di scriverlo centomila volte quanti errori commetteresti? Io dico zero. La quantità di codice è di per sè irrilevante.

- dispersività nella rappresentazione e comprensione del concetto.

Se vuoi una definizione formale di quello che ho detto non te la posso dare, perché sai bene che nel campo della programmazione si va spesso per esperienza / "best practices". Un po' come quando si afferma che la programmazione orientata è una "cosa buona e giusta".

Io non voglio una definizione formale nè voglio una ragione ottenuta citando Tizio o Caio. Io chiedo le tue ragioni. Perchè, secondo te, meno è meglio. Voglio sapere quando la rappresentazione di un concetto si può dire "dispersiva" e quando no, quando è dispersiva la comprensione, cosa è un concetto... per te.

Opinabile. Io preferisco iniziare dai mattoncini basilari per poi arrivare a quelli più complessi, anziché trovarmi di botto un bel po' di nuovi concetti e sentirmi dire: "per adesso devi fare così, perché queste cose poi le affronteremo più avanti".

E' un'istruzione, al pari di if, while, for, ecc. che non sono riconducibili a nessun "operatore elementare" o "messaggio" attribuibile a qualche oggetto. Dunque la sua presenza e il suo utilizzo mi sembrano del tutto leciti.

Non dovrebbero apparirti leciti tanto quanto non lo appaiono a me in Java. Se prendi Smalltalk, anche i se e i ma sono messaggi da inviare ad oggetti.

Comunque a partire da Python 3.0 diventerà una funzione come le altre built-in che offre il linguaggio, perché ci sono dei vantaggi non indifferenti nell'averla definita come tale (c'è un documento scritto da Guido van Rossum in proposito che espone le motivazioni).
Questo per sottolineare che, a differenza di linguaggi come Java, la comunità Python non si fa problemi a rompere la compatibilità col passato pur di avere a disposizione un linguaggio che rispecchia una precisa "filosofia".

Io lo vedo come un punto a sfavore.

Al di là del fatto che è evidente che non esiste un solo modo di definire cosa sia la programmazione a oggetti, secondo te è un bene o un male il fatto che Java non abbia abbracciato l'ereditarietà multipla?

Java dispone di ereditarietà multipla ed estensione singola. Io avrei preferito che, per chiarezza, le classi fossero state evitate in favore della possibilità di dichiarare un oggetto, a mo' di singleton, come in scala. Basti pensare all'imbarazzo in cui si trova chi debba rispondere alla domanda "ma che differenza c'è tra un'interfaccia ed una classe totalmente astratta"? La risposta è nessuna: è un punto in cui due strumenti del linguaggio si sovrappongono.

Concordi, poi, che l'approccio "tradizionale" alla modellazione della realtà facendo uso di oggetti si è rivelato fallimentare?

No. L'approccio tradizionale all'orientamento agli oggetti è quello, per intenderci, di Design Pattern: solo un'altra prospettiva da applicare ai fenomeni perchè... diavolo non si sa perchè. Che questa sia la tesi tutt'oggi dominante è chiaro sol che si leggano i capitoli relativi all'orientamento agli oggetti dei molti libri che trattano di programmazione. Sai che non è la tesi a cui io aderisco. Io perseguo l'ideale della prospettiva orientata agli oggetti come applicazione del punto di vista di un qualsiasi essere umano alla realtà e dico che questo approccio è superiore perchè risparmia una trasformazione di prospettiva - da come io vedo le cose a come devo vederle per poter scrivere un programma. E' una superiorità logica, incontrovertibile. Col grande problema dell'incertezza sugli esatti contorni del modo umano di vedere le cose.

Questa http://java.sun.com/docs/books/tutorial/extra/fullscreen/index.html quando ho lavorato a Diamonds funzionava soltanto con Windows. Su Linux non andava, e non perché mancasse adeguata accelerazione video.

E' un problema che mi incuriosisce perchè per ogni funzione "nativa" le librerie Java forniscono anche un meccanismo per determinare la presenza del supporto. Oso dire che un codice Java correttamente scritto non dovrebbe incontrare problemi nella gestione del caso "modalità fullscreen non disponibile". Si tratta in ogni caso di una questione di librerie e non di lingua o tecnologia, altrimenti basterebbe citare Java3D per ridurre l'alveo dei sistemi operativi supportati ad una manciata.

A parte questo, le implementazioni per Windows x64 non sono complete:

mancano delle librerie / funzionalità, e ciò mi ha costretto a dover installare sempre la versione a 32 bit.
Non so se la situazione sia cambiata dall'ultima volta che ho controllato.

Questo è un problema di risorse necessarie allo sviluppo di una versione della piattaforma Java. Ma se qualcuno dichiara mitologica la portabilità di Java il minimo che si può pretendere prima di stendersi ai piedi del blaterante di turno è che dichiari cosa impedirebbe l'esistenza di una piattaforma Java su sistemi diversi da quelli esistenti. Non mi pare eccessiva come pretesa.

Esiste qualche altra opera meritevole?

Sull'orientamento agli oggetti quello che io preferisco è Object Oriented Programming in The BETA programming language, con particolare riferimento al capitolo sul "conceptual framework". Sul linguaggio di programmazione Java non vedo alternative a The Java Programming Language, di Gosling e altri. Mi acchiappa anche l'ultimo Java - Mattone dopo mattone.

Scusa l'ignoranza, ma non ho colto il significato della "dipendenza di definizione".

Devi aver rimosso. Tipo un trauma :D. Ne avevamo già parlato. Ricordi quella faccenda del "ma che diavolo è un oggetto? Un oggetto è una definizione autonoma, la definizione di un oggetto può richiedere altre definizioni, in tal caso oggetto sarà l'unione di tutte le definizioni richieste più la definizione richiedente eccetera eccetera... Ti sovviene alla memoria?

PGI-Bis

09-10-2007, 18:57

con le argomentazioni che abbiamo fornito

Eridaje. Se qui qualcuno ha fornito argomentazioni vi assicuro che a me sono sfuggite. Quanto a Eckel, sul dizionario alla voce "argomentazione" mi risulta sotto "contrari".

cdimauro

09-10-2007, 19:47

niente vieta di assegnare il valore 0 al coefficiente a, perciò la divisione per zero ci può essere.
Lo vieta la matematica: non si parlerebbe di equazioni di secondo grado, altrimenti. Nel programma è specificato a chiare lettere, e non mi risulta che esistano equazioni di secondo grado con coefficiente "a" pari a zero.
è aria fritta perchè l'ho già spiegato che la scelta del linguaggio con cui iniziare non è una cosa oggettiva.
A giudicare dai numerosi esempi che abbiamo tirato fuori finora, sembrerebbe che sia importante, invece.

Comunque su questo avevamo già parlato (anche con te, che però hai preferito abbandonare velocemente questo ramo della discussione) e avevo anche suggerito di utilizzare il linguaggio macchina dell'Itanium di Intel per il paradigma imperativo, Lisp per quello funzionale e Perl per quello a oggetti.

Sei d'accordo che è tranquillamente possibile utilizzare questi linguaggi per iniziare con quei paradigmi?
inoltre anche volendo non si può fare un confronto tra linguaggi perchè non ci è dato sapere quali caratteristiche sono bene e quali sono male, e nel caso quanto bene e quanto male.
Non ti capisco: sii più chiaro, cortesemente.
ogni linguaggio è un opportuno compromesso di caratteristiche ed è inevitabile visto che molte caratteristiche sono in contrasto fra loro.
Sei sempre più difficile da capire.
ecco le due palle che mi sono fatto :D

#include <stdio.h>
#include <math.h>

int main()
{
float a, b, c;
float delta;

printf("Calcolo delle radici di un'equazione di secondo grado nella forma aX^2 + bX + c\n");
printf("inserire il coefficiente a: ");
scanf("%f", &a);
printf("inserire il coefficiente b: ");
scanf("%f", &b);
printf("inserire il coefficiente c: ");
scanf("%f", &c);

delta = b*b-4*a*c;

if(delta < 0)
{
printf("l'equazione non ha soluzioni reali");
}
else if(delta == 0)
{
float x = -b/(2*a);
printf("l'equazione ha un'unica soluzione reale: %f", x);
}
else
{
float x1 = (-b-sqrt(delta))/(2*a);
float x2 = (-b+sqrt(delta))/(2*a);
printf("l'equazione ha due soluzioni reali: %f e %f", x1, x2);
}

return 0;
}

un programmatore sta cosa se la mangia a colazione :asd: più righe ma il risultato è diverso,
Infatti il risultato non è affatto lo stesso: ti sei mangiato le radici complesse e coniugate, che sono possibili soluzioni di un'equazione di secondo grado, al pari delle altre.

Da notare, comunque, che hai dovuto aggiungere degli #include per poter utilizzare alcune funzioni di libreria, e col significato tutt'altro che semplice da apprendere. Questo per dovere di cronaca.
anche perchè imparare a programmare non è fare la gara a chi scrive meno righe. altrimenti avrei fatto così (vi risparmio la soluzione su una riga :p ):

#include <stdio.h>
#include <math.h>

int main()
{
float a, b, c;
printf("Calcolo delle radici di un'equazione di secondo grado nella forma aX^2 + bX + c\ninserire il coefficiente a: ");
scanf("%f", &a);
printf("inserire il coefficiente b: ");
scanf("%f", &b);
printf("inserire il coefficiente c: ");
scanf("%f", &c);
printf("le soluzioni sono: %f e %f", (-b-sqrt(b*b-4*a*c))/(2*a), (-b+sqrt(b*b-4*a*c))/(2*a));
}

print "Calcolo delle radici di un'equazione di secondo grado nella forma aX^2 + bX + c"
a = float(raw_input('Inserire il coefficiente a: '))
b = float(raw_input('Inserire il coefficiente b: '))
c = float(raw_input('Inserire il coefficiente c: '))
print "Le soluzioni dell'equazione sono", (-b + complex(b ** 2 - 4 * a * c) ** 0.5) / (2 * a), 'e', (-b - complex(b ** 2 - 4 * a * c) ** 0.5) / (2 * a)
Cinque righe. E anche su una riga il codice sarebbe comunque inferiore e sempre più leggibile.

a voi sembra difficile?
Rispetto a Python lo è di gran lunga.
il pascal è preferibile per il solo fatto di non richiedere l'uso del puntatore, ma sono dettagli
No, il Pascal è preferibile anche perché non devi ricorrere a nessuna funzione di libreria, e le procedure Write/ln e Readln sono decisamente più leggibili e facile da usare rispetto a printf e scanf.

cdimauro

09-10-2007, 20:30

Togliamo "ben preciso", "in maniera chiara" e "compatta" perchè non vuol dir nulla. Resta "esprime un concetto". E questo non lo revoco in dubbio.
Va bene.
Io la vedo un pelo diversa. In assembly cambia la prospettiva, in Smalltalk è identico, in Java, per fortuna, manca una sintassi speciale e si interviene a colpi di invocazioni di metodo su un oggetto.

Altro è l'effetto di quella parte del programma altro è ciò che è necessario comunicare per ottenerlo.
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.
La quantità di codice non è direttamente correlata alla quantità di bug. E posso anche provare a convincertene. Scrivi per cento volte

print "hello world"

Quanti bug ci sono in quelle cento linee? Induttivamente, se ti chiedessi di scriverlo centomila volte quanti errori commetteresti? Io dico zero. La quantità di codice è di per sè irrilevante.
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).

Ti faccio anche presente che applicando lo stesso principio che hai esposto (partire da codice "sicuramente senza bug" e combinarlo ad libidum), induttivamente dovremmo poter costruire un'intera applicazione, complessa quanto si vuole, che in linea teorica dovrebbe essere sempre priva di bug, ma ho il non vago sospetto che qualche rogna prima o poi capiterà.
Io non voglio una definizione formale nè voglio una ragione ottenuta citando Tizio o Caio. Io chiedo le tue ragioni. Perchè, secondo te, meno è meglio. Voglio sapere quando la rappresentazione di un concetto si può dire "dispersiva" e quando no, quando è dispersiva la comprensione, cosa è un concetto... per te.
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?
Non dovrebbero apparirti leciti tanto quanto non lo appaiono a me in Java.
A me appaiono perfettamente leciti: anche in Java esistono delle istruzioni che NON rappresentano scambi di messaggi fra oggetti.
Se prendi Smalltalk, anche i se e i ma sono messaggi da inviare ad oggetti.
In SmallTalk non esistono istruzioni?
Io lo vedo come un punto a sfavore.
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.
Java dispone di ereditarietà multipla ed estensione singola. Io avrei preferito che, per chiarezza, le classi fossero state evitate in favore della possibilità di dichiarare un oggetto, a mo' di singleton, come in scala. Basti pensare all'imbarazzo in cui si trova chi debba rispondere alla domanda "ma che differenza c'è tra un'interfaccia ed una classe totalmente astratta"? La risposta è nessuna: è un punto in cui due strumenti del linguaggio si sovrappongono.
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.

Comunque non hai risposto sull'ereditarietà ed estensione multipla: ti piace? Non ti piace? Ed eventualmente perché.
No. L'approccio tradizionale all'orientamento agli oggetti è quello, per intenderci, di Design Pattern: solo un'altra prospettiva da applicare ai fenomeni perchè... diavolo non si sa perchè. Che questa sia la tesi tutt'oggi dominante è chiaro sol che si leggano i capitoli relativi all'orientamento agli oggetti dei molti libri che trattano di programmazione. Sai che non è la tesi a cui io aderisco. Io perseguo l'ideale della prospettiva orientata agli oggetti come applicazione del punto di vista di un qualsiasi essere umano alla realtà e dico che questo approccio è superiore perchè risparmia una trasformazione di prospettiva - da come io vedo le cose a come devo vederle per poter scrivere un programma. E' una superiorità logica, incontrovertibile. Col grande problema dell'incertezza sugli esatti contorni del modo umano di vedere le cose.
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.
E' un problema che mi incuriosisce perchè per ogni funzione "nativa" le librerie Java forniscono anche un meccanismo per determinare la presenza del supporto. Oso dire che un codice Java correttamente scritto non dovrebbe incontrare problemi nella gestione del caso "modalità fullscreen non disponibile". Si tratta in ogni caso di una questione di librerie e non di lingua o tecnologia, altrimenti basterebbe citare Java3D per ridurre l'alveo dei sistemi operativi supportati ad una manciata.

Questo è un problema di risorse necessarie allo sviluppo di una versione della piattaforma Java. Ma se qualcuno dichiara mitologica la portabilità di Java il minimo che si può pretendere prima di stendersi ai piedi del blaterante di turno è che dichiari cosa impedirebbe l'esistenza di una piattaforma Java su sistemi diversi da quelli esistenti. Non mi pare eccessiva come pretesa.
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.
Sull'orientamento agli oggetti quello che io preferisco è Object Oriented Programming in The BETA programming language, con particolare riferimento al capitolo sul "conceptual framework". Sul linguaggio di programmazione Java non vedo alternative a The Java Programming Language, di Gosling e altri. Mi acchiappa anche l'ultimo Java - Mattone dopo mattone.
OK grazie. Li metto nel "must be read". :p
Devi aver rimosso. Tipo un trauma :D. Ne avevamo già parlato. Ricordi quella faccenda del "ma che diavolo è un oggetto? Un oggetto è una definizione autonoma, la definizione di un oggetto può richiedere altre definizioni, in tal caso oggetto sarà l'unione di tutte le definizioni richieste più la definizione richiedente eccetera eccetera... Ti sovviene alla memoria?
Purtroppo no, e non è questione di trauma: è proprio la mia memoria che dimostra ancora una volta di essere alquanto scarsa (per la disperazione di mia moglie, che comunque ormai ha perso le speranze di un mio miglioramento). :muro:
Eridaje. Se qui qualcuno ha fornito argomentazioni vi assicuro che a me sono sfuggite.
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. ;)
Quanto a Eckel, sul dizionario alla voce "argomentazione" mi risulta sotto "contrari".
ROTFL. Mi fai morire. :p

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

k0nt3

09-10-2007, 21:38

Lo vieta la matematica: non si parlerebbe di equazioni di secondo grado, altrimenti. Nel programma è specificato a chiare lettere, e non mi risulta che esistano equazioni di secondo grado con coefficiente "a" pari a zero.
allora il tuo programma non sta alle leggi della matematica (e nemmeno il mio :fagiano: ma ora l'ho corretto :p )

Comunque su questo avevamo già parlato (anche con te, che però hai preferito abbandonare velocemente questo ramo della discussione) e avevo anche suggerito di utilizzare il linguaggio macchina dell'Itanium di Intel per il paradigma imperativo, Lisp per quello funzionale e Perl per quello a oggetti.
Sei d'accordo che è tranquillamente possibile utilizzare questi linguaggi per iniziare con quei paradigmi?

ho già risposto. il linguaggio macchina richiede la conoscenza dell'architettura della cpu, lisp è ok per quel che ne so mentre perl non è un linguaggio prettamente a oggetti, quindi no

Non ti capisco: sii più chiaro, cortesemente.

Sei sempre più difficile da capire.
è facile: qualsiasi affermazione atta a dimostrare la superiorità di un linguaggio su un altro è aria fritta

Infatti il risultato non è affatto lo stesso: ti sei mangiato le radici complesse e coniugate, che sono possibili soluzioni di un'equazione di secondo grado, al pari delle altre.
non le ho mangiate, semplicemente non le volevo. comunque sei tu che ti sei mangiato un paio di controlli
questo è completo:

#include <stdio.h>
#include <math.h>
#include <complex.h>

int main()
{
float a = 0, b, c;
float delta;

printf("Calcolo delle radici di un'equazione di secondo grado nella forma aX^2 + bX + c\n");
while(a == 0)
{
printf("inserire il coefficiente a (diverso da 0): ");
scanf("%f", &a);
}
printf("inserire il coefficiente b: ");
scanf("%f", &b);
printf("inserire il coefficiente c: ");
scanf("%f", &c);

delta = b*b-4*a*c;

if(delta > 0)
{
float x1 = (-b-sqrt(delta))/(2*a);
float x2 = (-b+sqrt(delta))/(2*a);
printf("l'equazione ha due soluzioni reali: %f e %f", x1, x2);
}
else if(delta == 0)
{
float x = -b/(2*a);
printf("l'equazione ha un'unica soluzione reale: %f", x);
}
else
{
float _Complex x1 = (-b-csqrt(delta+0*I))/(2*a);
float _Complex x2 = (-b+csqrt(delta+0*I))/(2*a);
printf("l'equazione ha due soluzioni complesse: %f%fi e %f+%fi", creal(x1), cimag(x1), creal(x2), cimag(x2));
}

return 0;
}

Da notare, comunque, che hai dovuto aggiungere degli #include per poter utilizzare alcune funzioni di libreria, e col significato tutt'altro che semplice da apprendere. Questo per dovere di cronaca.
dai non è difficile..

print "Calcolo delle radici di un'equazione di secondo grado nella forma aX^2 + bX + c"
a = float(raw_input('Inserire il coefficiente a: '))
b = float(raw_input('Inserire il coefficiente b: '))
c = float(raw_input('Inserire il coefficiente c: '))
print "Le soluzioni dell'equazione sono", (-b + complex(b ** 2 - 4 * a * c) ** 0.5) / (2 * a), 'e', (-b - complex(b ** 2 - 4 * a * c) ** 0.5) / (2 * a)
Cinque righe. E anche su una riga il codice sarebbe comunque inferiore e sempre più leggibile.

Rispetto a Python lo è di gran lunga.

peccato che non si vince niente

No, il Pascal è preferibile anche perché non devi ricorrere a nessuna funzione di libreria, e le procedure Write/ln e Readln sono decisamente più leggibili e facile da usare rispetto a printf e scanf.
ho sempre consigliato pascal infatti, ma anche imparare il C non è la fine del mondo

cdimauro

09-10-2007, 22:39

allora il tuo programma non sta alle leggi della matematica (e nemmeno il mio :fagiano: ma ora l'ho corretto :p )
Ci sta benissimo: i requisiti sono quelli di avere i coefficienti per un'equazione di secondo grado, e libri di testo di analisi ecc. alla mano, dev'essere diverso da zero.
ho già risposto. il linguaggio macchina richiede la conoscenza dell'architettura della cpu,
Si tratta di sempre di scegliere, quindi va bene.
lisp è ok per quel che ne so mentre perl non è un linguaggio prettamente a oggetti, quindi no
Dove sta scritto che per imparare a programmare a oggetti serve un linguaggio "prettamente a oggetti"? L'importante è poter programmare con questa prospettiva. Quindi Perl va bene.
è facile: qualsiasi affermazione atta a dimostrare la superiorità di un linguaggio su un altro è aria fritta
Veramente parli di "bene", "male" e "compromessi".

Per il resto, il contesto era quello di "iniziare a programmare", e la scelta dev'essere ben ponderata. Altrimenti torniamo al discorso di cui sopra su linguaggio macchina, Lisp e Perl.
non le ho mangiate, semplicemente non le volevo.
Un'equazione di secondo grado prevede SEMPRE delle soluzioni, e il tuo programma non le calcola tutte.
comunque sei tu che ti sei mangiato un paio di controlli
Non mi sono mangiato niente: vedi sopra e/o un qualunque testo di analisi, geometria et similia.
questo è completo:

#include <stdio.h>
#include <math.h>
#include <complex.h>

int main()
{
float a = 0, b, c;
float delta;

printf("Calcolo delle radici di un'equazione di secondo grado nella forma aX^2 + bX + c\n");
while(a == 0)
{
printf("inserire il coefficiente a (diverso da 0): ");
scanf("%f", &a);
}
printf("inserire il coefficiente b: ");
scanf("%f", &b);
printf("inserire il coefficiente c: ");
scanf("%f", &c);

delta = b*b-4*a*c;

if(delta > 0)
{
float x1 = (-b-sqrt(delta))/(2*a);
float x2 = (-b+sqrt(delta))/(2*a);
printf("l'equazione ha due soluzioni reali: %f e %f", x1, x2);
}
else if(delta == 0)
{
float x = -b/(2*a);
printf("l'equazione ha un'unica soluzione reale: %f", x);
}
else
{
float _Complex x1 = (-b-csqrt(delta+0*I))/(2*a);
float _Complex x2 = (-b+csqrt(delta+0*I))/(2*a);
printf("l'equazione ha due soluzioni complesse: %f%fi e %f+%fi", creal(x1), cimag(x1), creal(x2), cimag(x2));
}

return 0;
}

Ti sei salvato in calcio d'angolo: complex.h è stato introdotta soltanto con l'ANSI C99.
dai non è difficile..
Ma dico: hai provato a confrontarlo con la versione Python che ho postato? Non è difficile, ma è decisamente contorto.
peccato che non si vince niente
Mi serve per confermare ancora una volta che la scelta del linguaggio per imparare a programmare è importante, e finora non mi sembra ci sia niente di meglio rispetto a Python.
ho sempre consigliato pascal infatti, ma anche imparare il C non è la fine del mondo
Lo è: è fra i più brutti, contorti e inutili linguaggi della storia dei linguaggi di programmazione.

Ah, dimenticavo: per Delta = 0 si hanno DUE soluzioni, reali e coincidenti. ;)

^TiGeRShArK^

09-10-2007, 23:13

niente vieta di assegnare il valore 0 al coefficiente a, perciò la divisione per zero ci può essere.

si, lo vieta esplicitamente la traccia dell'esercizio (o il requisito del problema se preferisci).

print "Calcolo delle radici di un'equazione di secondo grado nella forma aX^2 + bX + c"

Come fa ad essere un'equazione di secondo grado se il coefficiente a è uguale a 0? :mbe:
Nel caso in cui quel coefficiente sia uguale a zero è semplicemente un'errore di chi ha inserito i dati.
Si potrebbe criticare il fatto di non avere introdotta una gestione delle eccezioni per presentare meglio all'utente l'errore da lui commesso..
ma mi pare che il discorso non verteva sulla forma dell'errore da presentare all''utente quanto piuttosto sulla risoluzione di equazioni di secondo grado.
Se poi si vuole estendere il programma per risolvere equazioni di grado diverso dal secondo quello è un altro requirement che non è stato in alcun modo specificato.

k0nt3

10-10-2007, 08:41

si, lo vieta esplicitamente la traccia dell'esercizio (o il requisito del problema se preferisci).

la traccia era calcolare le soluzioni delle equazioni di secondo grado, il che lascia spazio a ogni tipo di ambiguità (compresa quella sui numeri complessi). fatto sta che io posso inserire il valore 0 e quindi in realtà sto considerando un'equazione di primo grado al contrario di quello che dice la traccia
non facciamoci un processo su sta cosa.. l'unica specifica era che l'equazione doveva essere di secondo grado (quindi con a <> 0)

cdimauro

10-10-2007, 09:03

la traccia era calcolare le soluzioni delle equazioni di secondo grado, il che lascia spazio a ogni tipo di ambiguità (compresa quella sui numeri complessi).
Senti, le equazioni di secondo grado in forma aX^2+bX+C=0 non me le sono certo inventate io, e matematicamente sono degli oggetti BEN FINITI: hanno il coefficiente "a" diverso da zero e ammettono SEMPRE due soluzioni (reali e distinte, reali e coicidenti, o complesse e coniugate).

Il problema, quindi, era BEN POSTO, e la soluzione che ho proposto ASSOLUTAMENTE CORRETTA.
fatto sta che io posso inserire il valore 0 e quindi in realtà sto considerando un'equazione di primo grado al contrario di quello che dice la traccia
Questo caso non ricadrebbe nel dominio del problema, per cui ciò che succede non è affar mio.

Il "contratto" stipulato fra programmatore e utente è chiarissimo: si parla di equazioni di secondo grado. In QUESTO contesto il programma funziona alla perfezione.
non facciamoci un processo su sta cosa.. l'unica specifica era che l'equazione doveva essere di secondo grado (quindi con a <> 0)
L'unica specifica è che il programma provvede a fornire le soluzioni (SEMPRE, visto che esistono in ogni caso) di un'equazione di secondo grado (che per definizione NON può avere il coefficiente "a" pari a zero). Punto.

Io, da buon programmatore, mi sono attenuto strettamente e perfettamente al problema.

Guille

10-10-2007, 09:16

Senti, le equazioni di secondo grado in forma aX^2+bX+C=0 non me le sono certo inventate io, e matematicamente sono degli oggetti BEN FINITI: hanno il coefficiente "a" diverso da zero e ammettono SEMPRE due soluzioni (reali e distinte, reali e coicidenti, o complesse e coniugate).

Il problema, quindi, era BEN POSTO, e la soluzione che ho proposto ASSOLUTAMENTE CORRETTA.

Questo caso non ricadrebbe nel dominio del problema, per cui ciò che succede non è affar mio.

Il "contratto" stipulato fra programmatore e utente è chiarissimo: si parla di equazioni di secondo grado. In QUESTO contesto il programma funziona alla perfezione.

L'unica specifica è che il programma provvede a fornire le soluzioni (SEMPRE, visto che esistono in ogni caso) di un'equazione di secondo grado (che per definizione NON può avere il coefficiente "a" pari a zero). Punto.

Io, da buon programmatore, mi sono attenuto strettamente e perfettamente al problema.

In astratto potrei anche darti ragione ma a patto che nell'ultima affermazione sostituisci buon programmatore con bravo coder :D

k0nt3

10-10-2007, 09:18

Si tratta di sempre di scegliere, quindi va bene.

Dove sta scritto che per imparare a programmare a oggetti serve un linguaggio "prettamente a oggetti"? L'importante è poter programmare con questa prospettiva. Quindi Perl va bene.
stai cercando di travisare quello che ho detto. io ho detto che prima di imparare un linguaggio bisogna avere una conoscenza teorica del paradigma a cui il linguaggio fa riferimento. nel caso di perl non mi basta conoscere la programmazione a oggetti perchè supporta anche altri paradigmi, ma in linea di principio niente mi vieta di iniziare dal perl (a parte che devo conoscere più di un paradigma)
considerare il linguaggio macchina ha poco senso perchè per prima cosa è un linguaggio di natura diversa e richiede la conoscenza dell'hardware su cui gira.
in ogni caso l'asm (non il linguaggio macchina) può essere una scelta se si è interessati a questo tipo di programmazione e si conosce l'architettura della cpu.

Veramente parli di "bene", "male" e "compromessi".

Per il resto, il contesto era quello di "iniziare a programmare", e la scelta dev'essere ben ponderata. Altrimenti torniamo al discorso di cui sopra su linguaggio macchina, Lisp e Perl.
bene, male = aria fritta :D

Un'equazione di secondo grado prevede SEMPRE delle soluzioni, e il tuo programma non le calcola tutte.
un'equazione di secondo grado prevede sempre delle soluzioni complesse, ma non sempre delle soluzioni reali. visto che non era specificato era corretto anche il mio

Non mi sono mangiato niente: vedi sopra e/o un qualunque testo di analisi, geometria et similia.
nel senso che è utile dividere i casi a seconda del delta. serve a imparare a programmare, altrimenti l'esempio non serve a niente :)

Ti sei salvato in calcio d'angolo: complex.h è stato introdotta soltanto con l'ANSI C99.

praticamente l'hanno aggiunta ieri :doh:

Ma dico: hai provato a confrontarlo con la versione Python che ho postato? Non è difficile, ma è decisamente contorto.
dove è contorto

Mi serve per confermare ancora una volta che la scelta del linguaggio per imparare a programmare è importante, e finora non mi sembra ci sia niente di meglio rispetto a Python.
e dove sta scritto che il linguaggio più adatto a imparare è quello che richiede meno righe? è un'affermazione senza senso

Lo è: è fra i più brutti, contorti e inutili linguaggi della storia dei linguaggi di programmazione.
ai posteri la dimostrazione

Ah, dimenticavo: per Delta = 0 si hanno DUE soluzioni, reali e coincidenti. ;)
non mi sembra il caso di fare dell'umorismo

k0nt3

10-10-2007, 09:25

Il problema, quindi, era BEN POSTO, e la soluzione che ho proposto ASSOLUTAMENTE CORRETTA.
assolutamente falso. il problema era posto in maniera ambigua, come spesso accade anche nella realtà

Io, da buon programmatore, mi sono attenuto strettamente e perfettamente al problema.
mi risulta difficile attenermi strettamente a qualcosa di ambiguo. comunque prevenire potenziali comportamenti non voluti è da buon programmatore

cdimauro

10-10-2007, 09:42

Non c'è NESSUNA ambiguità e ti stai arrampicando sugli specchi.

Non so dove e come tu abbia studiato, ma la definizione matematica di equazione di secondo grado in quella forma che ho riportato è quella corretta, e il programma che ho scritto ricava le sue soluzioni (TUTTE, visto che ci sono sempre).

Se hai una definizione diversa, sei pregato di farmela avere, altrimenti evita di rigirare la frittata perché è del tutto inutile.

k0nt3

10-10-2007, 11:17

fek

10-10-2007, 11:34

mi risulta difficile attenermi strettamente a qualcosa di ambiguo. comunque prevenire potenziali comportamenti non voluti è da buon programmatore

No, non lo e'. Un programmatore che cerca di prevenire potenziali problemi sta sovrangegnerizzando e perdendo tempo.
Un buon programmatore risolve solo il problema che gli e' fornito e si attiene strettamente alle specifiche date. Non implementa nulla di piu'.
Il buon programmatore prende un problema ambiguo e ne ricava specifiche non ambigue sulle quali lavorare discutendole col cliente.
E poi scrive il codice piu' semplice possibile che risolve il problema.

più righe ma il risultato è diverso, anche perchè imparare a programmare non è fare la gara a chi scrive meno righe.

Si', e' anche quello.

"La soluzione e' finita non quando non c'e' piu' nulla da aggiungere, ma quando non c'e' piu' nulla da togliere"

cdimauro

10-10-2007, 12:52

è ambigua ad esempio perchè non ho detto che il dominio era quello dei numeri complessi e non sta scritto da nessuna parte che è sottointeso
Hai detto quanto bastava, e se la matematica non è un'opinione (ma a questo punto ho il non vago sospetto che per te lo sia), un'equazione di secondo grado (nella forma data) è un "oggetto" che ha delle ben precise caratteristiche che ti ho già elencato: "a" diverso da zero e ha SEMPRE DUE soluzioni. Punto.

Se ti serve il parere di un matematico non hai che da chiederlo: nel forum ce ne sono diversi e basta scomodarne gentilmente qualcuno, ma in linea teorica certe nozioni avresti dovute averle affrontate e assimilate anche tu, sia alla scuola dell'obbligo sia all'università.

Il mio codice le rispetta in pieno: non fa né più né meno di quello richiesto, e lo fa nel più semplice dei modi.

Poi se vuoi continuare a farti ragione stravolgendo le basi della matematica e dell'informatica, dimmelo chiaramente perché la chiudiamo qui: non ho intenzione di perdere altro tempo su cose così banali e che dovrebbero essere scontate.

cdimauro

10-10-2007, 13:06

stai cercando di travisare quello che ho detto.
Nessuna travisazione: è da un pezzo che fai lascia e prendi col discorso della scelta o non scelta del linguaggio.
io ho detto che prima di imparare un linguaggio bisogna avere una conoscenza teorica del paradigma a cui il linguaggio fa riferimento.
L'argomento è stato affrontato: per chi deve iniziare a programmare sarebbe la cosa peggiore. Non si può vivere di teoria, ma serve la pratica, altrimenti per chi deve imparare diventerebbe troppo pesante nel giro di poco tempo.

Affiancare pochi, o anche uno solo, concetti di teoria alla volta immergendosi subito nella pratica e sperimentando quanto appreso è il modo migliore per impararli e fissarli in testa.
nel caso di perl non mi basta conoscere la programmazione a oggetti perchè supporta anche altri paradigmi, ma in linea di principio niente mi vieta di iniziare dal perl (a parte che devo conoscere più di un paradigma)
Gli altri paradigmi non c'entrano niente: è sufficiente focalizzarsi su quello che interessa. Perl, quindi, va benissimo.
considerare il linguaggio macchina ha poco senso perchè per prima cosa è un linguaggio di natura diversa e richiede la conoscenza dell'hardware su cui gira.
in ogni caso l'asm (non il linguaggio macchina) può essere una scelta se si è interessati a questo tipo di programmazione e si conosce l'architettura della cpu.
Per prima cosa dovresti specificare cosa intendi con "linguaggio di natura diversa", poi ti faccio notare che l'assembly è sostanzialmente la trasposizione mnemonica del linguaggio macchina, e il requisito dell'architettura da scegliere rimane ugualmente.

Adesso dovresti cortesemente spiegarmi perché l'assembly sì e il linguaggio macchina no.
un'equazione di secondo grado prevede sempre delle soluzioni complesse, ma non sempre delle soluzioni reali. visto che non era specificato era corretto anche il mio
Ti ho già risposto nell'altro messaggio. Hai torto e non puoi ridefinire il concetto di equazione di secondo grado soltanto per farti ragione.
nel senso che è utile dividere i casi a seconda del delta. serve a imparare a programmare, altrimenti l'esempio non serve a niente :)
Stai aggiungendo altra carne al fuoco che è del tutto inutile: un programmatore deve innanzitutto imparare a rispettare fedelmente i requisiti del problema.

In questo caso i controlli di cui parli sono inutili, perché stai aggiungendo cose non richieste, codice e possibilità di introdurre bug.
praticamente l'hanno aggiunta ieri :doh:
Non sono tanti i compilatori che sono perfettamente aderenti allo standard ANSI 99.
dove è contorto
Basta guardare la gestione dell'input (che, tra l'altro, richiede l'uso di puntatori, e che guarda caso è una delle maggiori fonti di introduzione di bug, visto che a scanf puoi passare anche della spazzatura e non batterà ciglio) e dell'output (idem come prima, e almeno qui non sei costretto a passare puntatori, ma la spazzatura puoi sempre passargliela).
e dove sta scritto che il linguaggio più adatto a imparare è quello che richiede meno righe? è un'affermazione senza senso
Anche. Non c'è solo quello. Sei tu che stai a travisare quello che ho detto.
ai posteri la dimostrazione
Per me non c'è bisogno di aspettare così tanto tempo. Dovresti aver imparato da tempo che diffusione non è sinonimo di qualità.
non mi sembra il caso di fare dell'umorismo
Non mi sembra il caso di stravolgere la matematica: la puntualizzazione che ho fatto è doverosa. Un'equazione di secondo grado AMMETTE SEMPRE DUE SOLUZIONI, quindi anche nel caso di delta pari a zero.

k0nt3

10-10-2007, 17:23

Hai detto quanto bastava, e se la matematica non è un'opinione (ma a questo punto ho il non vago sospetto che per te lo sia), un'equazione di secondo grado (nella forma data) è un "oggetto" che ha delle ben precise caratteristiche che ti ho già elencato: "a" diverso da zero e ha SEMPRE DUE soluzioni. Punto.
no ti sbagli! ha sempre due soluzioni solo se stai considerando i numeri complessi.
per il coefficiente diverso da zero sono daccordo con te, ma allora se il programma accetta uno zero è sbagliato

Se ti serve il parere di un matematico non hai che da chiederlo: nel forum ce ne sono diversi e basta scomodarne gentilmente qualcuno, ma in linea teorica certe nozioni avresti dovute averle affrontate e assimilate anche tu, sia alla scuola dell'obbligo sia all'università.
certo che li ho affrontati, non ho problemi con la matematica. il fatto che ho scritto una soluzione al posto di due coincidenti non dimostra niente, era secondario nel contesto in cui l'ho scritto

PGI-Bis

10-10-2007, 19:03

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 :coffee: Mi sono anche dimenticato perchè ho risposto come ho risposto la prima volta. :coffee:. 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. :p

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

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

cdimauro

10-10-2007, 20:43

per il coefficiente diverso da zero sono daccordo con te, ma allora se il programma accetta uno zero è sbagliato
Assolutamente no. Il programma ha un "contratto" ben definito: se gli viene dato in pasto un'equazione di secondo, com'è anche riportato TESTUALMENTE (vai a rileggerti la prima print, se dovesse esserti sfuggita, perché è scritto a chiare lettere), funziona perfettamente, ritornando le DUE soluzioni (anche complesse quindi).

Se gli fornisci qualcosa che NON è un'equazione di secondo grado, il suo comportamento E' INDEFINITO (nel senso che NON l'ho assolutamente definito e non m'importa).

Come non è definito neppure se al posto di un numero in virgola mobile digiti, ad esempio, "Pippo". Caso che, "stranamente", tu non hai considerato nemmeno di striscio con la tua versione C: eppure, secondo la tua logica, un controllo avrebbe dovuto esserci anche qui.

Comunque per maggiori informazioni su cosa significhi sviluppare programmi: http://it.wikipedia.org/wiki/Algoritmo di cui riporto uno spezzone:

"In informatica, con il termine algoritmo si intende un metodo per la soluzione di un problema adatto a essere implementato sotto forma di programma. Intuitivamente, un algoritmo si può definire come un procedimento che consente di ottenere un risultato atteso eseguendo, in un determinato ordine, un insieme di passi semplici corrispondenti ad azioni scelte solitamente da un insieme finito."
no ti sbagli! ha sempre due soluzioni solo se stai considerando i numeri complessi.

certo che li ho affrontati, non ho problemi con la matematica. il fatto che ho scritto una soluzione al posto di due coincidenti non dimostra niente, era secondario nel contesto in cui l'ho scritto
No, dimostra semplicemente che hai una concezione da scuola dell'obbligo di quelle cose: soltanto lì, quando si iniziano a trattare queste cose, si parla di un'equazione di secondo grado che può:
- avere due soluzioni;
- avere una soluzione;
- non avere soluzioni.

All'università, posto che il docente sappia fare bene il proprio dovere, si insegna che le soluzioni sono sempre due. Le soluzioni complesse si escludono SE E SOLO SE il codominio viene ristretto al campo dei reali (che, non essendo stato specificato, non è il caso nostro).

Vediamo se devi ancora continuare con questa storia. :rolleyes:

cdimauro

10-10-2007, 21:08

Qui avrei voluto rispondere ma... mi sono dimenticato cosa io dovessi dire :coffee: Mi sono anche dimenticato perchè ho risposto come ho risposto la prima volta. :coffee:. Bella la giovinezza, eh?
OK, lasciamo perdere.
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".
Dove la definizione di "complicato" però latita.
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.
I bug originano dall'introduzione del concetto di salto condizionato, del tutto assente nell'esempio che hai esposto.
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.
OK. Cosa ne pensi del mio punto di vista?
Nel senso di qualcosa che non sia un messaggio inviato ad un oggetto? No, non esistono.
L'istruzione di assegnazione come si configura? Anch'essa come "messaggio spedito"?
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à).
Mumble. Io lo vedo come una classe che definisce un metodo di classe: faccio male o c'è qualcosa che mi sfugge?
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.
Lo so, il tuo pensiero in merito l'hai esposto diverse volte, ma le eccezioni tante volte sono un'esigenza per poter lavorare più comodamente. Fra rischiare il suicidio pur di far fede sempre ai principi, e sviluppare con serenità un'applicazione, preferisco la seconda.

Tornando al discorso dell'ereditarietà multipla, se il linguaggio definisce bene il meccanismo di ricerca dei metodi e/o attributi, io non vedo particolari problemi nell'adottarla.

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?
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?
Facciamo che mi riferivo alle librerie anziché alla VM: va bene lo stesso riguardo alla discorso sulla portabilità di Java?
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. :p
Meglio: prendere le cose troppo seriamente fa male. :D

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?

La sintesi serve principalmente a rimuovere delle informazioni ridondanti o inutili.
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 :D.
Va bene. Tanto prima o poi capiterà di tornare sull'argomento. :p

^TiGeRShArK^

11-10-2007, 08:09

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

ma anche no :p
il tuo codice è una mera ridondanza.
E' possibile esprimere il concetto che tu hai espresso con un semplicissimo

for (int i = 0; i < 100; i++){
System.out.println("Hello world!");
}

E si ottiene lo stesso risultato.
Ora..
secondo te, inserendo lo snippet di codice col for e quello "unrolled" in un'applicazione reale, quale versione è più o meno soggetta ad errori?
(da notare che hai specificato 100 volte, quindi se sbagliando nel copia e incolla ne metti 99 o 101 allora stai introducendo dei bug)
Inoltre mettendo quello più lungo complichi incredibilmente la tua applicazione e per seguire il filo logico tra prima del tuo snippet e dopo dovresti fare i salti mortali, a meno ovviamente di non usare un extract method che ha esattamente la stessa funzione di ridurre la quantità di codice in quel metodo in modo da aumentarne la leggibilità e diminuire così la possibilità d'errore (credo che venga da se che un programma + leggibile sia meno soggetto ai bug).

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.

su questo invece mi trovi pienamente d'accordo :p

^TiGeRShArK^

11-10-2007, 08:17

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?
:mbe:
perchè? :fagiano:
Nelle interfacce non definisci l'implementazione, sono solo utilizzate per definire un contratto.
Dato che la tua classe che implementa le interfacce deve rispettare il contratto basta che implementi un solo metodo che faccia quanto richiesto.
Quindi il caso di due metodi in due interfacce diverse mi ricorda tanto l'esempio di cui sopra delle due soluzioni reali e coincidenti (:D), in cui con una sola implementazione di metodo hai rispettato due contratti :p

cdimauro

11-10-2007, 08:25

:mbe:
perchè? :fagiano:
Nelle interfacce non definisci l'implementazione, sono solo utilizzate per definire un contratto.
Dato che la tua classe che implementa le interfacce deve rispettare il contratto basta che implementi un solo metodo che faccia quanto richiesto.
Quindi il caso di due metodi in due interfacce diverse mi ricorda tanto l'esempio di cui sopra delle due soluzioni reali e coincidenti (:D), in cui con una sola implementazione di metodo hai rispettato due contratti :p
Mumble. Forse dovevo essere più chiaro. Se ho due interfacce che hanno responsabilità diverse ma definiscono lo stesso metodo getValue, questo dovrebbe definire un "comportamento" diverso per ognuna.

Per intenderci: una cosa è la getValue di un'interfaccia "ListCollection" e tutt'altra cosa è la getValue di una "DBField".

Se ho una sola implementazione per le due definizioni, quale dovrebbe essere il comportamento plasmato? Quella della prima? Quello della seconda? O una sorta di "combinazione"?

^TiGeRShArK^

11-10-2007, 08:41

Mumble. Forse dovevo essere più chiaro. Se ho due interfacce che hanno responsabilità diverse ma definiscono lo stesso metodo getValue, questo dovrebbe definire un "comportamento" diverso per ognuna.

Per intenderci: una cosa è la getValue di un'interfaccia "ListCollection" e tutt'altra cosa è la getValue di una "DBField".

Se ho una sola implementazione per le due definizioni, quale dovrebbe essere il comportamento plasmato? Quella della prima? Quello della seconda? O una sorta di "combinazione"?

boh..
alla fine è una tua scelta immagino...
Probabilmente se arrivi a questa situazione comunque il tuo oggetto non rispetta il principio di separazione dei compiti (o come cavolo si chiama :D) perchè effettua operazioni di due tipi di oggetti troppo diversi tra loro e che renderebbero il tuo oggetto una sottospecie di "ibrido".
Io personalmente separerei quindi il mio oggetto in due oggetti che implementano ognuno una delle due interfacce.
Questo sempre per restare nel tema che l'ereditarietà multipla comporta solo casini e dovrebbe essere applicata solo in caso un oggetto possa comportarsi effettivamente come specificato dalle varie interfacce che lo compongono.
Se ad esempio ho un oggetto Animale che è sia un uccello che un mammifero allora c'è qualcosa che non va :D

cdimauro

11-10-2007, 09:34

Le operazioni, anche se hanno lo stesso nome, sono separate ed è possibile "indirizzarle" con lo scoping.

Comunque neanch'io farei casini di questo tipo: era soltanto un dubbio esclusivamente sul piano formale che m'era sovvenuto.

Quindi la risposta è: no, si può implementare il metodo una sola volta per entrambe le interfacce.
A questo punto mi aspetto che se due interfacce definiscono lo stesso metodo, ma che tornano risultati diversi, linguaggi come Java, Delphi, ecc. sollevino un'errore in fase di compilazione.

k0nt3

11-10-2007, 12:30

Assolutamente no. Il programma ha un "contratto" ben definito: se gli viene dato in pasto un'equazione di secondo, com'è anche riportato TESTUALMENTE (vai a rileggerti la prima print, se dovesse esserti sfuggita, perché è scritto a chiare lettere), funziona perfettamente, ritornando le DUE soluzioni (anche complesse quindi).

Se gli fornisci qualcosa che NON è un'equazione di secondo grado, il suo comportamento E' INDEFINITO (nel senso che NON l'ho assolutamente definito e non m'importa).

Come non è definito neppure se al posto di un numero in virgola mobile digiti, ad esempio, "Pippo". Caso che, "stranamente", tu non hai considerato nemmeno di striscio con la tua versione C: eppure, secondo la tua logica, un controllo avrebbe dovuto esserci anche qui.

Comunque per maggiori informazioni su cosa significhi sviluppare programmi: http://it.wikipedia.org/wiki/Algoritmo di cui riporto uno spezzone:

"In informatica, con il termine algoritmo si intende un metodo per la soluzione di un problema adatto a essere implementato sotto forma di programma. Intuitivamente, un algoritmo si può definire come un procedimento che consente di ottenere un risultato atteso eseguendo, in un determinato ordine, un insieme di passi semplici corrispondenti ad azioni scelte solitamente da un insieme finito."
e dove l'hai visto il contratto :| io ho visto solo una richiesta ambigua, per cui ho dato una risposta che può non essere di tuo gradimento, ma secondo me rispetta la richiesta

No, dimostra semplicemente che hai una concezione da scuola dell'obbligo di quelle cose: soltanto lì, quando si iniziano a trattare queste cose, si parla di un'equazione di secondo grado che può:
- avere due soluzioni;
- avere una soluzione;
- non avere soluzioni.

All'università, posto che il docente sappia fare bene il proprio dovere, si insegna che le soluzioni sono sempre due. Le soluzioni complesse si escludono SE E SOLO SE il codominio viene ristretto al campo dei reali (che, non essendo stato specificato, non è il caso nostro).

Vediamo se devi ancora continuare con questa storia. :rolleyes:
NO
le soluzioni complesse si includono SE E SOLO SE il codominio viene ESTESO ai numeri complessi.
ti faccio notare che qualunque insegnante serio di analisi specifica sempre all'inizio qual'è il dominio e il codominio, per cui se stiamo parlando di numeri reali anche all'università ti insegnano che possono non esserci soluzioni. i numeri complessi si usano soltanto quando servono, mentre nella maggiorparte dei casi si fa riferimento a reali
ora.. rispondi a questa domanda:
perchè non dovrebbe essere possibile dare in input al programma numeri complessi? non è sottointeso?

direi che è il caso di non andare oltre

^TiGeRShArK^

11-10-2007, 12:52

NO
le soluzioni complesse si includono SE E SOLO SE il codominio viene ESTESO ai numeri complessi.
ti faccio notare che qualunque insegnante serio di analisi specifica sempre all'inizio qual'è il dominio e il codominio, per cui se stiamo parlando di numeri reali anche all'università ti insegnano che possono non esserci soluzioni. i numeri complessi si usano soltanto quando servono, mentre nella maggiorparte dei casi si fa riferimento a reali
ora.. rispondi a questa domanda:
perchè non dovrebbe essere possibile dare in input al programma numeri complessi? non è sottointeso?

direi che è il caso di non andare oltre
:mbe:

quadratic equation is a polynomial equation of the second degree. The general form is

ax^2+bx+c=0

where a ≠ 0. (For a = 0, the equation becomes a linear equation.)

The letters a, b, and c are called coefficients: the quadratic coefficient a is the coefficient of x2, the linear coefficient b is the coefficient of x, and c is the constant coefficient, also called the free term or constant term.

Quadratic equations are called quadratic because quadratus is Latin for "square"; in the leading term the variable is squared.

A quadratic equation with real (or complex) coefficients has two (not necessarily distinct) solutions, called roots, which may be real or complex, given by the quadratic formula,

:fagiano:
l'unica cosa che puoi dire a cesare è che non ha trattato il caso di coefficienti complessi, ma la sua soluzione si accorda perfettamente con la definizione di equazione polinomiale di secondo grado, come puoi anche vedere da quanto riportato.
La distinzione per delta > e < di 0 viene fatta solo quando gli studenti ancora non hanno appreso il concetto di numeri complessi.
Ma è solo una spiegazione per superare questa limitazione, infatti ti specificano chiaramente che nel domino dei numeri reali tale equazione non ammette soluzione per delta < 0.
Ma mica vuol dire che per delta minore di zero non la puoi risolvere....
Infatti se prendi la definizione generale (come quella riportata da wikipedia) vedi testualmente scritto che l'equazione di secondo grado ammette sempre due soluzioni.

k0nt3

11-10-2007, 12:55

cdimauro

11-10-2007, 12:59

Non c'è nemmeno bisogno che rispondo perché mi sono già espresso chiaramente e sono d'accordo con quanto ha scritto Danilo, tranne che su una cosa: non ho aggiunto niente; al contrario, semplicemente non ho tolto niente.

Per me la questione "risoluzione di un'equazione di secondo grado" finisce qui.

fek

11-10-2007, 14:09

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à :fagiano:
lui ha aggiunto anche le soluzioni complesse solo per scrivere meno righe di codice.. nient'altro

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.

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

variabilepippo

11-10-2007, 14:28

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

12-10-2007, 10:13

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.

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 :fagiano:
comunque ti anticipo che se in matematica definisci una funzione senza specificarne il dominio e il codominio in realtà non definisci una funzione.

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

12-10-2007, 10:30

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

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

12-10-2007, 10:40

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

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 :asd:

variabilepippo

12-10-2007, 10:54

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

12-10-2007, 11:44

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

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

12-10-2007, 16:34

non so cosa intendi per oggetto matematico :fagiano:

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

12-10-2007, 19:30

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

13-10-2007, 00:43

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

13-10-2007, 08:48

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:

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^

13-10-2007, 09:27

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 :D

(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 :p

PGI-Bis

13-10-2007, 09:38

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 :p

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^

13-10-2007, 10:01

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 :p
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

13-10-2007, 10:03

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 :O ed è anche abbastanza importante

PGI-Bis

13-10-2007, 10:13

è sbagliato perchè stai introducendo dele ridondanze senza aggiungere alcun contenuto informativo nel codice come avevo specificato precedentemente nella nota :p
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

13-10-2007, 11:03

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

13-10-2007, 12:05

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

13-10-2007, 12:32

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

13-10-2007, 12:59

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

13-10-2007, 13:15

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.

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

fek

13-10-2007, 13:27

PGI-Bis

13-10-2007, 13:34

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

13-10-2007, 16:57

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

13-10-2007, 17:46

scusate ma non ho resistito :asd:

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!
http://www.corradoguzzanti.it/img/foto_personaggi/big/vulvia2.jpg

Su Rieduchescional Ciannel!

:rotfl:

...SubbAqqQQui!!!!

:asd:

PGI-Bis

13-10-2007, 17:57

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

13-10-2007, 17:59

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 :D 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

13-10-2007, 18:44

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.

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

13-10-2007, 19:18

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

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

13-10-2007, 19:33

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

13-10-2007, 21:02

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/Funzione_ricorsiva_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. :p

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

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

13-10-2007, 22:24

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

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

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

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

13-10-2007, 22:36

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.

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

14-10-2007, 07:39

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 :D) 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. :D Ma c'è qualcosa che si salva in Java, dal tuo punto di vista? :p
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 :rotfl: :rotfl: :rotfl: Mi farai morire con le tue battute!!! :p

Ma non vorrei essere nei panni di chi dovesse sviluppare con un siffatto linguaggio... :asd:
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. :D

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

Lyane

14-10-2007, 09:14

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.

:confused:

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

14-10-2007, 09:44

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

14-10-2007, 20:28

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

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-1/Dispense_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

14-10-2007, 22:57

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-1/Dispense_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

15-10-2007, 08:21

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^

15-10-2007, 08:52

uno di questi fattori è il programmatore infatti :O 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^

15-10-2007, 08:56

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

^TiGeRShArK^

15-10-2007, 09:02

un'altro esempio è lo unit testing :D 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.
Scrivere un test non è funzionale all'algoritmo che risolve il problema.
E' solo uno strumento messo in mano al programmatore per controllare che l'algoritmo disegnato faccia il suo lavoro.
E' l'equivalente automatizzato del testing manuale.
O forse mi vorrai dire che fare del testing manuale implica l'aumento di righe di codice? :rolleyes:

Lyane

15-10-2007, 10:28

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

Ammetto che il dubbio mi e' venuto.

marco.r

15-10-2007, 13:30

Se dovessi considerare cose che non c'entrano con le premesse del discorso è chiaro che la faccenda cambierebbe.

Mi sembra che il punto di partenza sia stata la frase "expressing much in a few words. Implies clean-cut brevity, attained by excision of the superfluous", sulla quale hai chiesto "Perchè è bene essere concisi? Non si sa." e alla quale e' stato risposto fondamentalmente "perche' si introducono meno bug".
Stante questo, direi che il mio discorso rientra pienamente nelle premesse. Il motivo principale per cui quest'ultima affermazione e' ragionevole sta proprio nella frase iniziale: l'eliminazione del superfluo.
Per definizione stessa, il superfluo non aggiunge nulla al codice ma toglie risorse al programmatore: tempo per scriverlo, tempo per leggerlo, tempo per modificarlo per adattarlo alle modifiche al resto del programma. Tutto tempo che viene distolto da altre attivita' piu' produttive. Di conseguenza il programmatore da un lato viene distratto dalla componente rilevante dal codice, dall'altro deve accellerare i tempi per ottenere lo stesso risultato in meno tempo. Da qui un maggior numero di errori.
Se vuoi una dimostrazione matematica non ce l'ho, sicuramente ci sono una serie di dati statistici a supporto.

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.
Le condizioni non ottimali di cui parli sono quelle normali nel lavoro di tutti i giorni, soprattutto tempo e concentrazione limitati. Impossibile non tenerne conto se si vuole avere un qualcosa che abbia un valore pratico.