Iniziare a programmare

[cdimauro]

Originariamente inviato da PGI-Bis

Esatto. Non c'è qualcosina di diverso tra questo Python e quello dei programmi incollati? Dimmi di no e ti tiro una makumba .

Sì, non c'è proprio niente di diverso (SGRAT SGRAT SGRAT ), e il motivo è molto semplice: in Python OGNI COSA è un oggetto e le operazioni riguardano interazioni (o scambio di messaggi) fra oggetti.

Sia che scrivo:

a = 1

oppure il pezzo di codice che hai riportato:

class Tk(Misc, Wm):

il risultato è che nel namespace viene inserito un nuovo simbolo con un oggetto.

Sì, entrambi sono oggetti, ma sono istanze di classi diverse e hanno caratteristiche diverse.

In particolare Tk rappresenta la definizione di una classe, ed è un oggetto che in Python è definito come "callable", cioé richiamabile (come fosse una funzione; anch'essa oggetto "callable") e che come risultato della chiamata restituisce un'istanza della classe che definisce.

Come vedi Python è un linguaggio a oggetti "puro", e in ciò è assolutamente coerente.

La stessa cosa, però, non si può dire di Java, dove gli oggetti esistono soltanto nella misura in cui sei proprio tu a crearli, tramite la chiamata a un costruttore pubblico (con l'operatore new) oppure "occulto" (stringhe, array).

Le classi, quindi, non sono l'unità fondamentale della programmazione in Java: lo sarebbero se al posto di definire una variabile di tipo int ci fosse Integer, tanto per fare un esempio, e quindi lavorasse sempre con oggetti, ossia istanze di particolari classi.

Ciò non è, e quindi Java lo possiamo definire come un ibrido, un linguaggio che è un misto fra dati / codice strutturati e oggetti, e che offre due paradigmi di programmazione: a oggetti e strutturato.

Python lo possiamo definire un linguaggio puramente a oggetti, e che offre però diversi paradigmi di programmazione: a oggetti, strutturato, funzionale, ad aspetti e anche metaprogrammazione.
Questo lo possiamo considerare un "effetto collaterale" dovuto alle intrinseche caratteristiche che offrono gli oggetti che questo linguaggio mette a disposizione.

Non so se sono stato chiaro.

La concorrenza l'ho citata perchè in Java occorre tenerne conto, che piaccia o no. Relegare l'esposizione dei Thread Java in un capitoletto finale, della serie "ah già, c'è anche questo..." significa non avere ben chiare le caratteristiche della lingua. Se l'unità fondamentale della programmazione Java è la classe, l'unità fondamentale dell'esecuzione di un programma Java è il metodo in quanto frame di un Thread.

Tenerlo nascosto per non complicare le cose è cialtroneria informatica.

Se usate Java dovete studiare la programmazione concorrente. E non c'è nulla da temere perchè la programmazione concorrente in Java è uno scherzetto.

Stiamo partendo dalle basi, PGI: Java può offrire o meno la programmazione concorrente, ma al momento è del tutto trascurabile per chi non sa nemmeno cos'è una variabile.

Poi anche Python dà questa possibilità e lo fa pure in maniera molto semplice. Ma al momento, per quanto detto, non è nemmeno in discussione.

[cdimauro]

Originariamente inviato da k0nt3

io ho visto solo argomentazioni fragili e basate sulle esperienze personali più che su dati di fatto

Se sono fragili non hai che da smontarle, eh! Peccato che è da un pezzo che ci provi, ma con scarsi risultati.

in questo caso più che aiutare il diretto interessato scrivo per dovere di cronaca.. tanto non è la prima volta che decide di partire con python, eppure è ancora in alto mare

Sarebbe ancora peggio se avesse cominciato con Java: per scrivere il banale programmino della somma di due numeri avrebbe dovuto scomodare la definizione di una classe, di un metodo, e l'importazione di alcune librerie standard... oltre al codice vero e proprio che serve allo scopo.

Con Python, invece, deve scrivere soltanto il codice che serve a risolvere il problema. E scusa se è poco (anche come dimensioni ).

impossibile! non aveva un contesto

Vabbé, lasciamo perdere.

urca non lo sapevo
il fatto che le eccezioni sono gestibili non mi aiuta a imparare a programmare

Invece i segmentation fault sì: alleluia!

per prima cosa bisogna sapere come si legge lo stack trace, anzi prima ancora bisogna sapere cos'è uno stack. dopodichè certamente è molto utile per individuare il bug, ma di solito per uno che sta imparando a programmare non c'è bisogno di uno strumento così potente

E' uno strumento che è disponibile aggratis, e anche un niubbo riesce velocemente a capire come funziona.

sarebbe il caso di imparare a usare un debugger, quindi didatticamente non cambia molto

Ancora deve iniziare e già tiri fuori il debugger. Ma dico io, hai presente che non conosce nemmeno il concetto di variabile?

La prossima volta cosa gli consiglierai? Dai un'occhiata alla finestra della CPU, col valore dei registri, e i dump dei segmenti di codice, dati e stack?

Un traceback è nettamente più a portata di mano di un debugger, specialmente per chi comicia a programmare.

Poi ai debugger preferisco di gran lunga una batteria di test.

Qui però ci stiamo infognando su discorsi che vanno ben oltre lo scopo del thread.

[k0nt3]

Originariamente inviato da cdimauro

Se sono fragili non hai che da smontarle, eh! Peccato che è da un pezzo che ci provi, ma con scarsi risultati.

il problema è che voi sostenete che python è il linguaggio migliore per imparare, mentre per me la scelta del linguaggio è abbastanza secondaria, nonostante ho espresso la mia preferenza per pascal.
quindi semplicemente la pensiamo in maniera diversa.. sarà dura convincerti della mia idea, ma non credere che le tue argomentazioni hanno un effetto diverso su di me

Originariamente inviato da cdimauro

Sarebbe ancora peggio se avesse cominciato con Java: per scrivere il banale programmino della somma di due numeri avrebbe dovuto scomodare la definizione di una classe, di un metodo, e l'importazione di alcune librerie standard... oltre al codice vero e proprio che serve allo scopo.

certo che non sarebbe male capire questi concetti visto che lo scopo era imparare

Originariamente inviato da cdimauro

Con Python, invece, deve scrivere soltanto il codice che serve a risolvere il problema. E scusa se è poco (anche come dimensioni ).

anche creare una classe fa parte della risoluzione del problema

Originariamente inviato da cdimauro

Invece i segmentation fault sì: alleluia!

nel caso non si fosse capito sostenevo che è indifferente

Originariamente inviato da cdimauro

E' uno strumento che è disponibile aggratis, e anche un niubbo riesce velocemente a capire come funziona.

non resta che provare allora

Originariamente inviato da cdimauro

Ancora deve iniziare e già tiri fuori il debugger. Ma dico io, hai presente che non conosce nemmeno il concetto di variabile?

La prossima volta cosa gli consiglierai? Dai un'occhiata alla finestra della CPU, col valore dei registri, e i dump dei segmenti di codice, dati e stack?

Un traceback è nettamente più a portata di mano di un debugger, specialmente per chi comicia a programmare.

Poi ai debugger preferisco di gran lunga una batteria di test.

Qui però ci stiamo infognando su discorsi che vanno ben oltre lo scopo del thread.

il debugger è uno strumento importantissimo, non sapevo che ci vuole una laurea in ingegneria nucleare per usarlo. scorrere il codice riga per riga è una delle cose più utili al mondo per capire come funziona la programmazione.

la batteria di test non sostituisce in nessun modo il debugger

la batteria di test la deve scrivere uno che se la cava abbastanza, altrimenti fa più danni di quelli che risolve (quindi dubito che sia il nostro caso)

[DioBrando]

Originariamente inviato da k0nt3

sarò breve e conciso.. l'ho già scritto prima e lo ripeto: per imparare a programmare il linguaggio che usi importa relativamente, le cose più importanti sono la passione per l'argomento e la determinazione. perciò trovo superficiali affermazioni come "python è senza dubbio la scelta migliore" ecc.. sono cose campate lì senza molte argomentazioni.

Le argomentazioni sn state date ampiamente, se poi uno fà finta di non vederle per portare acqua al proprio mulino, possiamo andare avanti anche fino al giorno del Giudizio perchè non si convincerà mai e rimarrà sulle proprie posizioni.

esempi
"in python si scrivono meno righe di codice"
e chi ha detto che per imparare a programmare bisogna scrivere il minor numero di righe di codice?

Non è solo questione di righe, è questione di codice sorgente in toto.
+ è il codice e + aumentano gli errori, inoltre se il codice risulta sintetico e ridotto allo stretto necessario, è possibile concentrarsi maggiormente sulla risoluzione del problema e sull'algoritmo da implementare.

Questi sn ragionamenti che si applicano per la programmazione in generale, non certo per la programmazione in un dato linguaggio.

"la sintassi di python è bellissima fighissima e leggibilissima"

dai non fare il bambino, è stato scritto altro, non stupidaggini buttate lì così come se si dovesse vendere un detersivo.

questione di gusti, a me non piace ad esempio

che la sintassi e la semantica di un linguaggio sia + semplice a quelle di un altro non è affatto questione di gusti.
In primis vi sono studi scientifici così come vi sono analisi che determinano la scelta di un linguaggio +ttosto che un altro nella realizzazione di qualsiasi progetto e qualsiasi software "serio".
In secundis se io dico che la sintassi del Perl è + complessa di quella di Java, credo di non dire una bestialità per nessuno.

E allora cos'è questo "gusto" piace a tutti mentre se si tratta di Python no?

Dai su, fai la persona seria

"non ci sono i segmentation fault"
in compenso ci sono le eccezioni

e così via

Perchè in Java non ci sono le eccezioni? E altri linguaggi non utilizzano meccanismi per gestirle?


Siete riusciti a dire che Java utilizza un solo paradigma di programmazione (OO), siete riusciti a dire che Python non dispone di strumenti di sviluppo qualitativamente pari a quelli Java, ora le eccezioni e poi me ne dimentico altre per strada.


Chissà quale sarà la prossima panzana che vi inventerete pur di dare sostanza alle vostre argomentazioni

[cdimauro]

Originariamente inviato da k0nt3

il problema è che voi sostenete che python è il linguaggio migliore per imparare, mentre per me la scelta del linguaggio è abbastanza secondaria, nonostante ho espresso la mia preferenza per pascal.
quindi semplicemente la pensiamo in maniera diversa.. sarà dura convincerti della mia idea, ma non credere che le tue argomentazioni hanno un effetto diverso su di me

Allora con te è inutile continuare questa parte della discussione.

certo che non sarebbe male capire questi concetti visto che lo scopo era imparare

E per chi inizia con la matematica non sarebbe male capire il concetto di equazione differenziale.

anche creare una classe fa parte della risoluzione del problema

Solo in linguaggi come Java, dove si è obbligati a usa una classe come "contenitore" della funzione da chiamare per avviare l'esecuzione dell'applicazione.

Una classe io la uso soltanto per modellare il comportamento di un oggetto.

nel caso non si fosse capito sostenevo che è indifferente

Non lo è, perché un segmentation fault non aiuta, mentre un'eccezione sì.

non resta che provare allora

Ottimo.

il debugger è uno strumento importantissimo, non sapevo che ci vuole una laurea in ingegneria nucleare per usarlo.

Ci vuole esperienza: quella che manca a chi inizia a programmare.

scorrere il codice riga per riga è una delle cose più utili al mondo per capire come funziona la programmazione.

Certamente, prima però ti servono le basi per capire quello che c'è scritto nelle righe di codice.

la batteria di test non sostituisce in nessun modo il debugger

Ne limita non poco l'uso, e a volte permette di farne del tutto a meno.

Poi non sempre è possibile utilizzare un debugger.

la batteria di test la deve scrivere uno che se la cava abbastanza, altrimenti fa più danni di quelli che risolve (quindi dubito che sia il nostro caso)

Danni non ne può fare: al più può scrivere test inutili.

[k0nt3]

Originariamente inviato da DioBrando

Le argomentazioni sn state date ampiamente, se poi uno fà finta di non vederle per portare acqua al proprio mulino, possiamo andare avanti anche fino al giorno del Giudizio perchè non si convincerà mai e rimarrà sulle proprie posizioni.

quello che state facendo anche voi del resto.. non mi sorprende che ognuno rimane della sua idea, è abbastanza normale

Originariamente inviato da DioBrando

Non è solo questione di righe, è questione di codice sorgente in toto.
+ è il codice e + aumentano gli errori, inoltre se il codice risulta sintetico e ridotto allo stretto necessario, è possibile concentrarsi maggiormente sulla risoluzione del problema e sull'algoritmo da implementare.

Questi sn ragionamenti che si applicano per la programmazione in generale, non certo per la programmazione in un dato linguaggio.

premettendo che la mia intenzione era solo fare degli esempi tanto per intenderci... rispondo ugualmente
non è vero che meno codice = meno errori

a = 1
b = "pippo"
c = a/b

mentre invece

int a
int b
int c

a = 1
b = "pippo"
c = a/b

darebbe errore di compilazione
nonostante sia più codice è evidente che nel secondo caso il linguaggio mi viene in aiuto per evitare degli errori

Originariamente inviato da DioBrando

dai non fare il bambino, è stato scritto altro, non stupidaggini buttate lì così come se si dovesse vendere un detersivo.

l'impressione era appunto da televendita

Originariamente inviato da DioBrando

che la sintassi e la semantica di un linguaggio sia + semplice a quelle di un altro non è affatto questione di gusti.
In primis vi sono studi scientifici così come vi sono analisi che determinano la scelta di un linguaggio +ttosto che un altro nella realizzazione di qualsiasi progetto e qualsiasi software "serio".
In secundis se io dico che la sintassi del Perl è + complessa di quella di Java, credo di non dire una bestialità per nessuno.

E allora cos'è questo "gusto" piace a tutti mentre se si tratta di Python no?

Dai su, fai la persona seria

non so cosa c'entra perl.. è ancora tutto da dimostrare che python è più leggibile di java (per me ad esempio vale il contrario)
è tutto serio quello che ho detto

Originariamente inviato da DioBrando

Perchè in Java non ci sono le eccezioni? E altri linguaggi non utilizzano meccanismi per gestirle?

considerando che tutti e due sappiamo che java ha le eccezioni è evidente che non stavo parlando di java
e comunque non so perchè tutti hanno letto: "le eccezioni sono inutili"
ho detto questo per caso?

Originariamente inviato da DioBrando

Siete riusciti a dire che Java utilizza un solo paradigma di programmazione (OO), siete riusciti a dire che Python non dispone di strumenti di sviluppo qualitativamente pari a quelli Java, ora le eccezioni e poi me ne dimentico altre per strada.
Chissà quale sarà la prossima panzana che vi inventerete pur di dare sostanza alle vostre argomentazioni

difatti java utilizza solo il paradigma OO (e la programmazione strutturata solo se si è abbastanza perversi)
e python dispone di strumenti di sviluppo totalmente differenti da quelli di java, quindi un confronto è abbastanza inutile

[DioBrando]

Originariamente inviato da k0nt3

quello che state facendo anche voi del resto.. non mi sorprende che ognuno rimane della sua idea, è abbastanza normale

noi abbiamo esplicitato con codice, argomentazioni, dati, fatti per cui Python sia, secondo noi, la scelta migliore per il primo approccio con la programmazione da parte di un neofita, desideroso di imparare.

Per esempio è un fatto che l'indentazione forzata di Python costringa il programmatore a scrivere codice in un dato modo, ordinato, evitando che vi siano spaziature diverse per una medesima struttura e all'interno di un unico file di codice sorgente.
Con Java da questo punto di vista si ha + libertà.




A parte scrivere "voi avete torto", non mi sembra di aver scorto molta sostanza, men che meno da parte tua.
Ma puoi sempre rimediare, argomentando con eloquenza i tuoi punti

premettendo che la mia intenzione era solo fare degli esempi tanto per intenderci... rispondo ugualmente
non è vero che meno codice = meno errori

a = 1
b = "pippo"
c = a/b

mentre invece

int a
int b
int c

a = 1
b = "pippo"
c = a/b

darebbe errore di compilazione
nonostante sia più codice è evidente che nel secondo caso il linguaggio mi viene in aiuto per evitare degli errori

che discorsi, se fai un esempio ad hoc dove nel primo caso non dichiari il tipo di variabile, mentre nel secondo sì è ovvio che si giunga alla tua conclusione.

Io parlo di esempi che siano raffrontabili.


E in ogni caso, sfuggi al discorso già menzionato, il numero di linee di codice sorgente è una discriminante per poi poter valutare la qualità del codice stesso che è dato ANCHE dal numero di errori ivi presenti.
Se tu o chi altro, vuole continuare a sostenere che non sia un parametro importante ai fini della correttezza, della manutenibilità e della leggibilità del codice allora siete liberi di farlo.
E conseguentemente di riscrivere buona parte della teoria di Ingegneria del Software degli ultimi 30 anni (per carità le teorie nuove sono sempre bene accette...a volte si tratta di vere e proprie rivoluzioni )

non so cosa c'entra perl.. è ancora tutto da dimostrare che python è più leggibile di java (per me ad esempio vale il contrario)
è tutto serio quello che ho detto

era un esempio per dimostrare come la sintassi di un linguaggio non sia semplice a seconda dei gusti di chi la legge e di chi ne fà uso.

considerando che tutti e due sappiamo che java ha le eccezioni è evidente che non stavo parlando di java
e comunque non so perchè tutti hanno letto: "le eccezioni sono inutili"
ho detto questo per caso?

hai risposto in merito a quello che ha scritto Cesare sul fatto che in Python non si corra il pericolo dei segmentation fault.
Tu hai risposto che ci sono le eccezioni.
Mbè?

Ci sono anche in Java come in altri linguaggi, quindi non capisco il motivo per cui tu abbia dato una risposta del genere.

Lui ha dato una motivazione per cui sia preferibile cominciare con Python, tu hai risposto dando un'annotazione che non mette in luce Java, bensì qualsiasi linguaggio che sappia gestire delle eccezioni.


Non sò quali siano i tuoi interlocutori abituali, ma rigirare la minestra qui credo funzioni molto poco

difatti java utilizza solo il paradigma OO (e la programmazione strutturata solo se si è abbastanza perversi)

A meno che l'italiano non sia improvvisamente diventato un'opinione, avere è diverso da "usare". (PGI-BIS aveva parlato di "essere unicamente orientato agli oggetti". Non è così,è un ibrido come la quasi totalità dei linguaggi + utilizzati al mondo)
E infatti nei corsi di programmazione in Java, quando si studiano i mattoni fondamentali si parte proprio dalla programmazione strutturata...evidentemente in Java e non in un altro linguaggio (cosa che poi sarebbe necessaria se si seguisse il tuo consiglio di cominciare dal Basic, quando poi ci si trova ad affrontare l'OOP...), dato che uno switching dopo nemmeno un trimestre di corso sarebbe un suicidio didattico-educativo.

e python dispone di strumenti di sviluppo totalmente differenti da quelli di java, quindi un confronto è abbastanza inutile

E si vede quanto tu lo conosca Python.

Sono così diversi per cui, esistono versioni di Eclipse sviluppate ad hoc per sviluppare sia in Java che in Python, oppure si può utilizzare i plugin per sfruttare il medesimo ambiente (PyDev il + famoso).
Questo vale per Eclipse, vale per Visual Studio, vale per jEdit, IntelliJIDEA, JDeveloper ecc...praticamente tutti gli IDE migliori e + famosi in circolazione che usano, com'è logico che sia, una struttura a plugin.


Sempre + Zelig Circus

[mad_hhatter]

Originariamente inviato da cdimauro

Sì, non c'è proprio niente di diverso (SGRAT SGRAT SGRAT ), e il motivo è molto semplice: in Python OGNI COSA è un oggetto e le operazioni riguardano interazioni (o scambio di messaggi) fra oggetti.

provo ad azzardare... ereditarieta' multipla (con il problema di ambiguita' che si porta dietro)?

Originariamente inviato da cdimauro

Come vedi Python è un linguaggio a oggetti "puro", e in ciò è assolutamente coerente.

La stessa cosa, però, non si può dire di Java, dove gli oggetti esistono soltanto nella misura in cui sei proprio tu a crearli, tramite la chiamata a un costruttore pubblico (con l'operatore new) oppure "occulto" (stringhe, array).

e in quale altro momento dovrebbero esistere? cos'ha che non va la creazione esplicita di un'istanza di una classe ben precisa?

poi butti li' un "occulto" quasi in senso spregiativo... ma non eri tu che, a proposito delle forme implicite, dicevi che queste sono ben documentate nelle specifiche del linguaggio?

Originariamente inviato da cdimauro

Le classi, quindi, non sono l'unità fondamentale della programmazione in Java: lo sarebbero se al posto di definire una variabile di tipo int ci fosse Integer, tanto per fare un esempio, e quindi lavorasse sempre con oggetti, ossia istanze di particolari classi.

java e' talmente pervaso di tipi primitivi che non ti si puo' dar torto se per ogni variabile temporanea che fa da indice a un ciclo iterativo dovessi creare un oggetto da mettere nello heap e che deve essere gestito in termini di garbage collection avrei un'efficienza spaventosamente bassa vedi io sono convinto che le cose debbano essere mantenute semplici: ti serve un oggetto, usa un oggetto... ti serve un dato primitivo, non scomodare cose inutilmente complesse... l'eleganza e' semplicita'.

Originariamente inviato da cdimauro

Ciò non è, e quindi Java lo possiamo definire come un ibrido, un linguaggio che è un misto fra dati / codice strutturati e oggetti, e che offre due paradigmi di programmazione: a oggetti e strutturato.

il fatto che esistano dei tipi primitivi non implica che si adotti il punto di vista della programmazione strutturata... in java, visto che sostenevi che la classe non e' l'unita' fondamentale, nulla esiste se non all'interno di una definizione di una classe, neppure un main... fai tu. poi in java e' talmente arduo, cognitivamente parlando, scrivere codice in modo puramente strutturato che direi che la tua affermazione e' priva di senso.

Originariamente inviato da cdimauro

Python lo possiamo definire un linguaggio puramente a oggetti, e che offre però diversi paradigmi di programmazione: a oggetti, strutturato, funzionale, ad aspetti e anche metaprogrammazione.
Questo lo possiamo considerare un "effetto collaterale" dovuto alle intrinseche caratteristiche che offrono gli oggetti che questo linguaggio mette a disposizione.

Non so se sono stato chiaro.

chiarissimo in python tutto ha una collocazione metafisica assolutamente voluta e cercata, negli altri linguaggi qualche difettuccio sfugge sempre...

Originariamente inviato da cdimauro

Stiamo partendo dalle basi, PGI: Java può offrire o meno la programmazione concorrente, ma al momento è del tutto trascurabile per chi non sa nemmeno cos'è una variabile.

Poi anche Python dà questa possibilità e lo fa pure in maniera molto semplice. Ma al momento, per quanto detto, non è nemmeno in discussione.

ma guarda, non consigliavi python perche' consente diversi paradigmi di programmazione? argomento decisamente elementare per un novizio che ha problemi con la somma di due numeri... se vogliamo guardare solo alle basi va bene carta e penna, o al massimo un QUALSIASI linguaggio... certo java puo' offrire la programmazione concorrente, ma al momento e' trascurabile... pero' una delle argomentazioni a favore di python era che permettendo vari paradigmi di programmazione si poteva, in futuro, utilizzare il linguaggio gia' noto per una miriade di situazioni diverse... invece per la programmazione concorrente perche' dovrebbe valere lo stesso? no, e' talmente trascurabile... ma guarda un po'.

l'ho gia' detto e lo ripeto, con la speranza di sbagliarmi: tutto cio' sa molto di "101 modi per giustificare l'uno di python a ogni costo".

[mad_hhatter]

Originariamente inviato da DioBrando

il numero di linee di codice sorgente è una discriminante per poi poter valutare la qualità del codice stesso che è dato ANCHE dal numero di errori ivi presenti.
Se tu o chi altro, vuole continuare a sostenere che non sia un parametro importante ai fini della correttezza, della manutenibilità e della leggibilità del codice allora siete liberi di farlo.

ineccepibile... vogliamo pero' parlare del fatto che essendo dinamicamente tipizzato python spalanca la porta a numerosissimi bug "da errore di battitura" (scrivo "abbc" al posto di "abc")?

parlando di manutenibilita'... vogliamo parlare di quanto possa essere difficile, per chi prende in mano un codice non suo, districarsi tra oggetti di tipo ignoto (cosa che rende il codice NON auto esplicativo)?

[Tadde]

Ma di ruby cosa mi dite?

http://www.ruby-lang.org/en/document...y-from-python/

http://www.ruby-lang.org/en/document...uby-from-java/

[cdimauro]

Originariamente inviato da mad_hhatter

provo ad azzardare... ereditarieta' multipla (con il problema di ambiguita' che si porta dietro)?

No, tutto il mio primo quote in realtà è incentrato sul fatto che PGI-Bis lamenta (da tempo ) di Python il fatto che metta a disposizione diversi modi / sintassi per "costruire oggetti".

Questo lo fa anche Java, perché è oggettivamente utile avere delle "scorciatoie" in alcuni casi, che semplificano di molto la scrittura del codice.

e in quale altro momento dovrebbero esistere? cos'ha che non va la creazione esplicita di un'istanza di una classe ben precisa?

Per quanto mi riguarda non ha niente.

poi butti li' un "occulto" quasi in senso spregiativo... ma non eri tu che, a proposito delle forme implicite, dicevi che queste sono ben documentate nelle specifiche del linguaggio?

Non hai capito il senso del mio discorso: vedi sopra.

Io non ho alcuna difficoltà ad accetterle: è PGI-Bis che oppone una forte resistenza, e la forma "dispregiativa" che ho usato era proprio per calcare la mano.

Per quanto riguarda queste "forme implicite", non sono tali perché si tratta di oggetti aventi PRECISE caratteristiche, che tra l'altro sono anche ben documentate.

Esempio: se definisco un oggetto funzione, so ESATTAMENTE cosa potrò fare. Non c'è niente di "occulto", "implicito", "poco documentato".

java e' talmente pervaso di tipi primitivi che non ti si puo' dar torto se per ogni variabile temporanea che fa da indice a un ciclo iterativo dovessi creare un oggetto da mettere nello heap e che deve essere gestito in termini di garbage collection avrei un'efficienza spaventosamente bassa

E chi se ne frega. Abbiamo forte parlato di efficienza qui? Mi pare di no.

A me hanno insegnato intanto a RISOLVERE i problemi. POI, SE E SOLO SE le prestazioni sono un problema, si pensa a soluzioni ALGORITMICHE, e come ultima possibilità c'è quella di riscriverne parti con linguaggi più a basso livello.

Tra l'altro col termine efficienza abbracciamo sia le prestazioni che lo spazio di memoria occupato, e in quest'ultimo caso Python, dai test effettuati (di cui ho riportato anche un link), mediamente risulta gestire meglio la memoria.

vedi io sono convinto che le cose debbano essere mantenute semplici: ti serve un oggetto, usa un oggetto... ti serve un dato primitivo, non scomodare cose inutilmente complesse... l'eleganza e' semplicita'.

Ma dove starebbe la complessità, scusa? Anzi, è pure molto più semplice ed elegante avere un solo modello per tutto (tutti gli elementi usati sono oggetti).

il fatto che esistano dei tipi primitivi non implica che si adotti il punto di vista della programmazione strutturata... in java, visto che sostenevi che la classe non e' l'unita' fondamentale, nulla esiste se non all'interno di una definizione di una classe, neppure un main... fai tu. poi in java e' talmente arduo, cognitivamente parlando, scrivere codice in modo puramente strutturato che direi che la tua affermazione e' priva di senso.

Certo, e infatti si vede dagli esempi che sono stati riportati l'uso che se ne è stato fatto delle classi: banali contenitori di codice.

Ai miei tempi queste cose si chiamavano unit, moduli, ecc. In Java tra l'altro vengono chiamati "package".

Per me è privo di senso usare una classe per scopi diversi da questo: http://it.wikipedia.org/wiki/Classe_(informatica)

Sui tipi primitivi, vedi sopra
Tra l'altro è bene notare che in Java avere le classi e usarle sono due cose diverse.

chiarissimo in python tutto ha una collocazione metafisica assolutamente voluta e cercata, negli altri linguaggi qualche difettuccio sfugge sempre...

In Python non c'è niente di metafisico, ma tutto ha una sua BEN PRECISA logica (oltre che coerenza).

ma guarda, non consigliavi python perche' consente diversi paradigmi di programmazione? argomento decisamente elementare per un novizio che ha problemi con la somma di due numeri... se vogliamo guardare solo alle basi va bene carta e penna, o al massimo un QUALSIASI linguaggio... certo java puo' offrire la programmazione concorrente, ma al momento e' trascurabile... pero' una delle argomentazioni a favore di python era che permettendo vari paradigmi di programmazione si poteva, in futuro, utilizzare il linguaggio gia' noto per una miriade di situazioni diverse... invece per la programmazione concorrente perche' dovrebbe valere lo stesso? no, e' talmente trascurabile... ma guarda un po'.

l'ho gia' detto e lo ripeto, con la speranza di sbagliarmi: tutto cio' sa molto di "101 modi per giustificare l'uno di python a ogni costo".

Vorrei capire il senso di questo tuo post, perché non riesco a trovarne uno.

PGI-Bis ha parlato di programmazione concorrente, e io ho sottolineato due cose:
- che per l'argomento del topic è inutile citarla;
- che non è un'esclusiva di Java visto che altri linguaggi la mettono a disposizione.

Mi spieghi cosa c'è che non va in quello che ho scritto, e come si concilia il tuo quote con tutto ciò?

[cdimauro]

Originariamente inviato da Tadde

Ma di ruby cosa mi dite?

http://www.ruby-lang.org/en/document...y-from-python/

http://www.ruby-lang.org/en/document...uby-from-java/

Non lo trovo abbastanza leggibile, specialmente per alcuni suoi costrutti sintattici.

[k0nt3]

per prima cosa modera i toni che non stai parlando con tua sorella, zelig circus tientelo per te

Originariamente inviato da DioBrando

noi abbiamo esplicitato con codice, argomentazioni, dati, fatti per cui Python sia, secondo noi, la scelta migliore per il primo approccio con la programmazione da parte di un neofita, desideroso di imparare.

e per me invece non avete dimostrato niente, continuate a ripetere che python è migliore perchè ha una sintassi semplice (fosse l'unico), è il più leggibile (IMHO falso) ecc.. le argomentazioni serie dove sono? cosa comporta iniziare a programmare da python?

Originariamente inviato da DioBrando

Per esempio è un fatto che l'indentazione forzata di Python costringa il programmatore a scrivere codice in un dato modo, ordinato, evitando che vi siano spaziature diverse per una medesima struttura e all'interno di un unico file di codice sorgente.
Con Java da questo punto di vista si ha + libertà.

però il fatto di non avere dei simboli che racchiudono i blocchi vanifica questo tentativo di migliorare la leggibilità. prendi ad esempio un (pseudo)codice del genere:

while(a<b)
    dosomething()
    if(b>c)
        a = a +1
        ...
    else
        c = c - 2
        ...
        try
            dosomethingelse()
        except Error
            print "error"

se piazzi questo frammento di codice in un programma capisci che risulta difficile distinguere i blocchi a occhio (risulta più evidente in sorgenti di una certa complessità)
altra cosa che balza subito all'occhio è la mancanza di omogeneità nel linguaggio. perchè print "error" e non print("error") per esempio?

Originariamente inviato da DioBrando

A parte scrivere "voi avete torto", non mi sembra di aver scorto molta sostanza, men che meno da parte tua.
Ma puoi sempre rimediare, argomentando con eloquenza i tuoi punti

ti sbagli.. voi continuate a ripetere "abbiamo ragione" senza molta sostanza a vostro favore. io dico semplicemente che il linguaggio scelto è una cosa secondaria, ci sono cose più importanti se si vuole imparare a programmare.
la sensazione che ho è che ultimamente il consiglio a chi vuole imparare è "non sporcarti le mani", ovvero "è meglio che stai in una cupolina di vetro perchè sennò rischi di farti male" ecc..
ragazzi se uno vuole diventare programmatore le mani se le deve sporcare e deve pure capire tutto quello che succede nel suo codice. hanno insegnato e da qualche parte continuano a insegnare C come primo linguaggio di programmazione eppure non è mai morto nessuno. anzi se il risultato di un segmentation fault è il panico consiglio di cambiare hobby (parlo di programmazione al livello iniziale, non programmi di decine di migliaia di righe codice.. lì il panico ci sta )

Originariamente inviato da DioBrando

che discorsi, se fai un esempio ad hoc dove nel primo caso non dichiari il tipo di variabile, mentre nel secondo sì è ovvio che si giunga alla tua conclusione.

Io parlo di esempi che siano raffrontabili.


E in ogni caso, sfuggi al discorso già menzionato, il numero di linee di codice sorgente è una discriminante per poi poter valutare la qualità del codice stesso che è dato ANCHE dal numero di errori ivi presenti.
Se tu o chi altro, vuole continuare a sostenere che non sia un parametro importante ai fini della correttezza, della manutenibilità e della leggibilità del codice allora siete liberi di farlo.
E conseguentemente di riscrivere buona parte della teoria di Ingegneria del Software degli ultimi 30 anni (per carità le teorie nuove sono sempre bene accette...a volte si tratta di vere e proprie rivoluzioni )

incredibile.. ho appena dimostrato che ci sono casi in cui scrivere più codice corrisponde a evitare errori eppure tu continui a sostenere l'opposto perchè non posti un esempio in cui nella versione java è più facile commettere errori? daltronde in java si scrive molto più codice.. dovrebbe esserti facile

Originariamente inviato da DioBrando

era un esempio per dimostrare come la sintassi di un linguaggio non sia semplice a seconda dei gusti di chi la legge e di chi ne fà uso.

dimostrare?
il fatto che perl sia "oggettivamente" poco leggibile non significa che python sia "oggettivamente" leggibile. tu continui a dire di dimostrare cose, ma io non vedo niente

Originariamente inviato da DioBrando

hai risposto in merito a quello che ha scritto Cesare sul fatto che in Python non si corra il pericolo dei segmentation fault.
Tu hai risposto che ci sono le eccezioni.
Mbè?

in realtà la mia non era una risposta a un post in particolare

Originariamente inviato da DioBrando

Ci sono anche in Java come in altri linguaggi, quindi non capisco il motivo per cui tu abbia dato una risposta del genere.

Lui ha dato una motivazione per cui sia preferibile cominciare con Python, tu hai risposto dando un'annotazione che non mette in luce Java, bensì qualsiasi linguaggio che sappia gestire delle eccezioni.


Non sò quali siano i tuoi interlocutori abituali, ma rigirare la minestra qui credo funzioni molto poco

per prima cosa non ho rigirato nessuna minestra, ho detto dall'inizio che ai fini didattici il lancio di un eccezione e o un errore sono praticamente indifferenti.
ho dato una risposta del genere perchè il mio obiettivo non era confrontare python con java, ma stavo facendo considerazioni più generali. e in queste considerazioni generali ho affermato che il fatto che python gestisce le eccezioni non è un motivo per preferirlo come linguaggio per imparare a programmare. non perchè le eccezioni sono inutili, ma perchè sono superflue ai fini dell'apprendimento (della programmazione in generale). c'è sempre tempo per imparare a usarle

Originariamente inviato da DioBrando

A meno che l'italiano non sia improvvisamente diventato un'opinione, avere è diverso da "usare". (PGI-BIS aveva parlato di "essere unicamente orientato agli oggetti". Non è così,è un ibrido come la quasi totalità dei linguaggi + utilizzati al mondo)
E infatti nei corsi di programmazione in Java, quando si studiano i mattoni fondamentali si parte proprio dalla programmazione strutturata...evidentemente in Java e non in un altro linguaggio (cosa che poi sarebbe necessaria se si seguisse il tuo consiglio di cominciare dal Basic, quando poi ci si trova ad affrontare l'OOP...), dato che uno switching dopo nemmeno un trimestre di corso sarebbe un suicidio didattico-educativo.

a te hanno insegnato la programmazione strutturata in java? roba da pazzi..
un dato di fatto è che in java non si può fare a meno di un qualche oggetto e quindi la definizione di programmazione strutturata in questo caso è un pò tirata. diciamo che si può emulare la programmazione strutturata usando solo metodi statici, ma è diverso da dire che java supporta la programmazione strutturata

Originariamente inviato da DioBrando

E si vede quanto tu lo conosca Python.

in effetti ho preso solo 27 all'esame

Originariamente inviato da DioBrando

Sono così diversi per cui, esistono versioni di Eclipse sviluppate ad hoc per sviluppare sia in Java che in Python, oppure si può utilizzare i plugin per sfruttare il medesimo ambiente (PyDev il + famoso).
Questo vale per Eclipse, vale per Visual Studio, vale per jEdit, IntelliJIDEA, JDeveloper ecc...praticamente tutti gli IDE migliori e + famosi in circolazione che usano, com'è logico che sia, una struttura a plugin.


Sempre + Zelig Circus

e eclipse dovrebbe essere la dimostrazione che java e python hanno strumenti simili?
per prima cosa non mi puoi paragonare il plugin per python di eclipse con quello di java
seconda cosa io parlavo del framework, non dell'IDE... hai un pò di confusione in testa

[mad_hhatter]

Originariamente inviato da cdimauro

E chi se ne frega. Abbiamo forte parlato di efficienza qui? Mi pare di no.

A me hanno insegnato intanto a RISOLVERE i problemi. POI, SE E SOLO SE le prestazioni sono un problema, si pensa a soluzioni ALGORITMICHE, e come ultima possibilità c'è quella di riscriverne parti con linguaggi più a basso livello.

non sto parlando di algoritmica, sto parlando di scelte implementative a livello di linguaggio... non mischiamo le cose. Tra l'altro, se una feature del linguaggio è tale da inficiare le performance e tale linguaggio non offre alternative a tale feature, mi spieghi come ottimizzi nel caso fosse necessario?

Originariamente inviato da cdimauro

Ma dove starebbe la complessità, scusa? Anzi, è pure molto più semplice ed elegante avere un solo modello per tutto (tutti gli elementi usati sono oggetti).

non è detto che il modello più generale sia il più semplice o il più efficace in ogni circostanza.

Originariamente inviato da cdimauro

Certo, e infatti si vede dagli esempi che sono stati riportati l'uso che se ne è stato fatto delle classi: banali contenitori di codice.

Ai miei tempi queste cose si chiamavano unit, moduli, ecc. In Java tra l'altro vengono chiamati "package".

Per me è privo di senso usare una classe per scopi diversi da questo: http://it.wikipedia.org/wiki/Classe_(informatica)

banali contenitori di codice? mi domando perché tu programmi con linguaggi OO

se ho una classe che esegue solo istruzioni sto definendo un tipo di oggetto che espone un determinato comportamento... non mi interessa cosa faccia internamente, so che è un'entità con caratteristiche definite, cioè un oggetto... non mi pare scandaloso e anzi, del tutto in linea con il link che hai postato.

Originariamente inviato da cdimauro

Vorrei capire il senso di questo tuo post, perché non riesco a trovarne uno.

è molto semplice: molti tuoi post mi sembrano orientati a voler giustificare python sempre e comunque e ad ogni costo.

[k0nt3]

@DioBrando
quasi dimenticavo... non mi confondere basic con pascal

[mindwings]

Primo anno di "Informatica e Tecnologie produzione software " (Bari)
Esame di Programmazione :
Linguaggio usato ---> Java
argomenti del corso in pillole ---> programmazione strutturata (come si è arrivati e il perchè [GOTO] ecc ecc)
---> Cos'è l' OOP e infarinatura di Java
---> Algoritmi fondamentali (metodi di ordinamento e di ricerca principalmente)
---> Case of study (programmazione in piccolo per la risoluzione di un problema )

[cionci]

Questo sopra mi sembra un ottimo corso universitario per principianti...bello. Giudizio dopo averlo seguito ?

[mindwings]

Originariamente inviato da cionci

Questo sopra mi sembra un ottimo corso universitario per principianti...bello. Giudizio dopo averlo seguito ?

Il giudizio è buono . Io avrei preferito un' iniezione pesante di Java e un caso di studio moolto più complicato , ci hanno spiegato concetti potenti interfacce polimorfismo ereditarietà ma non ci hanno stimolato ad usarli o meglio non ce n'è mai stata la necessità. (forse con l'esame di ing del sw)

[DioBrando]

Originariamente inviato da Tadde

Ma di ruby cosa mi dite?

http://www.ruby-lang.org/en/document...y-from-python/

http://www.ruby-lang.org/en/document...uby-from-java/

la sintassi perliana non mi piace, però è oggettivamente uno dei linguaggi + "trendy" del momento, ci sono parecchi screencast sia su Ruby che su RubyOnRails (mi pare abbiano fatto una conferenza internazionale da poco).

[DioBrando]

Originariamente inviato da k0nt3

@DioBrando
quasi dimenticavo... non mi confondere basic con pascal

ho pensato ad uno e ho scritto l'altro.
Il concetto è il medesimo, dato che nessuno dei due nasce con il paradigma OO, quindi i discorsi si applicano nella medesima sostanza e quindi lo switch dovresti farlo cmq.