[Java e Pyton] Differenze tra i due?

[D4rkAng3l]

Ciao,
stò studiando Java per un secondo esame universitario.
Ho sentito parecchio parlare di Pyton, anche lui object oriented e credo anche lui interpretato (anche se suppongo in maniera ben diversa da Java che usa il bytecode ed una macchina virtuale vera e propria).

Volevo avere qualche info (per ora è pura curiosità...nel futuro chissà)

1) Differenza di difficoltà nello studiare Java rispetto a Pyton (da quello che ho capito Pyton è abbastanza più semplice, o sbaglio?)

2) Applicazioni pratiche di Pyton?

3) Pyton supporta un qualche tipo di polimorfismo?

Grazie
Andrea

[wingman87]

Python con l' "h"

[cdimauro]

Originariamente inviato da D4rkAng3l

Ciao,
stò studiando Java per un secondo esame universitario.
Ho sentito parecchio parlare di Pyton, anche lui object oriented e credo anche lui interpretato (anche se suppongo in maniera ben diversa da Java che usa il bytecode ed una macchina virtuale vera e propria).

Python ha una sua virtual machine e un suo bytecode. Da questo punto di vista è identico a Java.

La differenza è che la VM di Java ha un compilatore JIT integrato, che ne accelera molto la velocità di esecuzione.

Volevo avere qualche info (per ora è pura curiosità...nel futuro chissà)

1) Differenza di difficoltà nello studiare Java rispetto a Pyton (da quello che ho capito Pyton è abbastanza più semplice, o sbaglio?)

E' molto più semplice.

2) Applicazioni pratiche di Pyton?

Praticamente le stesse di Java e di numerosi altri linguaggi.

3) Pyton supporta un qualche tipo di polimorfismo?

Grazie
Andrea

Python supporta l'ereditarietà multipla. Java quella singola + interfacce multiple.

Quindi il modello di Python è più "generale" / flessibile.

[D4rkAng3l]

Originariamente inviato da cdimauro

Python ha una sua virtual machine e un suo bytecode. Da questo punto di vista è identico a Java.

La differenza è che la VM di Java ha un compilatore JIT integrato, che ne accelera molto la velocità di esecuzione.

E' molto più semplice.

Praticamente le stesse di Java e di numerosi altri linguaggi.

Python supporta l'ereditarietà multipla. Java quella singola + interfacce multiple.

Quindi il modello di Python è più "generale" / flessibile.

mmm si vabbè poi mi pare che Java per garantire la type safty attui anche delle regole più restrittivi rispetto alle normali regole di varianza e controvarianza...se non erro in Java i metodi dichiarati nelle classi figlie devono avere la stessa signature di quelli dichiarati nella classe padre...quindi in Pyton questa cosa non è obbligatoria? E' cmq type safe?

Cos'è il compilatore Jit integrato alla virtual machine di java?

Grazie delle info
Andrea

[PGI-Bis]

Il supporto di Python all'ereditarietà multipla è un tantinello bizzarro perchè una classe è conforme o non conforme al contratto delle sue superclassi a seconda dell'ordine di inizializzazione se esiste una convergenza nella firma di più metodi ereditati da genitori diversi (che è poi il problema classico dell'estensione multipla).

Per i metodi Java, sebbene il tipo restituito non sia considerato parte della firma a partire da Java 5 un metodo A sovrascrive un metodo B se la firma è identica e il tipo restituito da A è compatibile in assegnamento col tipo restituito da B (sono diventati covarianti, prima erano invarianti).

Il JIT traduce l'intera rappresentazione di un metodo da bytecode java a codice macchina dopo l'N-sima invocazione di quel metodo (1000 volte nella JVM client). Agli albori era possibile solo con i metodi non virtuali, ora grazie alla capacità del JIT di compiere il processe inverso (da codice macchina a byte code) lo fa con tutti i metodi. Quindi un programma Java è interamente interpretato all'avvio e tende a diventare interamente compilato nel corso della sua esecuzione.

[D4rkAng3l]

Originariamente inviato da PGI-Bis

Il supporto di Python all'ereditarietà multipla è un tantinello bizzarro perchè una classe è conforme o non conforme al contratto delle sue superclassi a seconda dell'ordine di inizializzazione se esiste una convergenza nella firma di più metodi ereditati da genitori diversi (che è poi il problema classico dell'estensione multipla).

Per i metodi Java, sebbene il tipo restituito non sia considerato parte della firma a partire da Java 5 un metodo A sovrascrive un metodo B se la firma è identica e il tipo restituito da A è compatibile in assegnamento col tipo restituito da B (sono diventati covarianti, prima erano invarianti).

Il JIT traduce l'intera rappresentazione di un metodo da bytecode java a codice macchina dopo l'N-sima invocazione di quel metodo (1000 volte nella JVM client). Agli albori era possibile solo con i metodi non virtuali, ora grazie alla capacità del JIT di compiere il processe inverso (da codice macchina a byte code) lo fa con tutti i metodi. Quindi un programma Java è interamente interpretato all'avvio e tende a diventare interamente compilato nel corso della sua esecuzione.

Gia che ci siamo fammi sto ripassotto, quando dici che: il tipo restituito da A è compatibile in assegnamento col tipo restituito da B intendi dire che il tipo restituito da B è A o un sottotipo di A?

Tnx
Andrea

[PGI-Bis]

è A che sovrascrive B. Comunque sì, se B restituisce Number allora A può restituire ad esempio Integer.

[cdimauro]

Originariamente inviato da D4rkAng3l

mmm si vabbè poi mi pare che Java per garantire la type safty attui anche delle regole più restrittivi rispetto alle normali regole di varianza e controvarianza...se non erro in Java i metodi dichiarati nelle classi figlie devono avere la stessa signature di quelli dichiarati nella classe padre...quindi in Pyton questa cosa non è obbligatoria? E' cmq type safe?

In Python i metodi delle classi figlie possono cambiare la "signature" dello stesso metodo della classe padre, e restituire anche un valore completamente diverso.

Originariamente inviato da PGI-Bis

Il supporto di Python all'ereditarietà multipla è un tantinello bizzarro perchè una classe è conforme o non conforme al contratto delle sue superclassi a seconda dell'ordine di inizializzazione se esiste una convergenza nella firma di più metodi ereditati da genitori diversi (che è poi il problema classico dell'estensione multipla).

Sì, ma un'ordine è comunque stabilito (o, per meglio dire, imposto): http://www.python.org/download/releases/2.3/mro/

[PGI-Bis]

Imposto mica tanto. L'mro cambia a seconda di come scrivi la clausola di estensione. Tra l'altro è possibile che un ordine dei nomi nella clausola di estesione produca una gerarchia valida (nel senso che ogni metodo esteso è effettivamente invocabile) e un altro no.

[cdimauro]

Originariamente inviato da PGI-Bis

Imposto mica tanto. L'mro cambia a seconda di come scrivi la clausola di estensione.

Vero. E' l'unica cosa su cui puoi agire per specificare una certa priorità all'override, ma riguarda soltanto l'ultimo livello di "estensione".

Tra l'altro è possibile che un ordine dei nomi nella clausola di estesione produca una gerarchia valida (nel senso che ogni metodo esteso è effettivamente invocabile) e un altro no.

Questo dipende da come sono implementati i metodi "sovrascritti": se richiamano super correttamente, tutti i metodi con la stessa signature verranno invocati.

L'uso del termine semplice in informatica dovrebbe essere punito con cinquanta frustate.

Immagino ti riferisca a questo:

E' molto più semplice.

che avevo scritto prima.

Per fortuna che siamo abbastanza distanti.

Comunque l'uso del termine "semplice" non è di dominio esclusivo del tipico pythonista (fa parte dello "Zen di Python": Simple is better than complex).

Fa parte anche del principio K.I.S.S., e in generale (quindi non soltanto riguardo l'informatica) tendere alla semplicità non mi sembra una cattiva cosa.

[PGI-Bis]

Originariamente inviato da cdimauro

Immagino ti riferisca a questo:

E' molto più semplice.

che avevo scritto prima.

Per fortuna che siamo abbastanza distanti.

Comunque l'uso del termine "semplice" non è di dominio esclusivo del tipico pythonista (fa parte dello "Zen di Python": Simple is better than complex).

Fa parte anche del principio K.I.S.S., e in generale (quindi non soltanto riguardo l'informatica) tendere alla semplicità non mi sembra una cattiva cosa.

E' che l'altro giorno ho riletto "Extreme Programming" di Beck e m'è venuta la solita incazzatura, ho visto quel "semplice" e non ho più resistito.

Il problema è sempre quello: l'informatica è una questione di quantità, non di qualità. Le cose sono zero, uno o mille, non sono "belle", "brutte", "facili", "difficili".

Tutte cose di cui già vaneggiai in altro notorio thread .

[cdimauro]

Immaginavo che fosse quello il pomo della discordia, ma volevo esserne sicuro.

Però, se ricordi, nessuno ha mai parlato di teorie, quanto di "best practices" dettate dall'esperienza e da prove empiriche.

Un po' come dire: "la programmazione a oggetti aiuta a scrivere codice migliore". E' un'affermazione puramente empirica, e come tale criticabile:

"Object-oriented programming is an exceptionally bad idea which could only have originated in California." --Edsger Dijkstra.

[PGI-Bis]

Tu mi inciti all'off-topic ma non cadrò nel tranello. Non concordo, fortissimamente non concordo .

[cdimauro]

Si può sempre aprire un thread ad hoc per parlarne.

L'argomento è interessante, e penso che possa servire anche agli altri utenti del forum.

[mad_hhatter]

a me, per esempio, interesserebbe. Tra l'altro, mi trovo un po' in disaccordo con quanto accennato da PGI-bis e non conosco il thread di cui parlava...

@cdimauro: bel talk il tuo a Firenze, peccato non ci sia stata occasione per parlare di persona

[banryu79]

Anche a me interesserebbe.
In effetti sono thread-post con considerazioni/posizioni di confronto come queste che in passato mi hanno stimolato di più a pormi delle domande.

[mad_hhatter]

Originariamente inviato da banryu79

Anche a me interesserebbe.
In effetti sono thread-post con considerazioni/posizioni di confronto come queste che in passato mi hanno stimolato di più a pormi delle domande.

verissimo!

[cdimauro]

Originariamente inviato da mad_hhatter

@cdimauro: bel talk il tuo a Firenze, peccato non ci sia stata occasione per parlare di persona

Ma perché non ti sei avvicinato? M'avrebbe fatto piacere conoscerti dal vivo e scambiare due chiacchiere.

[mad_hhatter]

Originariamente inviato da cdimauro

Ma perché non ti sei avvicinato? M'avrebbe fatto piacere conoscerti dal vivo e scambiare due chiacchiere.

eh lo so, ma eri sempre impegnato e non mi piace interrompere una conversazione sarà per il prossimo anno

[cdimauro]

Beh, almeno tu hai conosciuto me.

Il prossimo anno tocca a me conoscere te.