Matrixbob
08-02-2008, 20:08
Insomma passare da linguaggio C a Java o C++ o C#.
Occorre cambiare filosofia giusto?
Cosa consigliate x approciarsi al OO?
Occorre cambiare filosofia giusto?
Cosa consigliate x approciarsi al OO?
View Full Version : Devo cambiare modo di pensare per passare ai linguaggi ad oggetti?
cdimauro
08-02-2008, 20:09
Questo: http://www.python.it/doc/Howtothink/Howtothink-html-it/index.htm :)
^TiGeRShArK^
08-02-2008, 20:41
questo:
rm -rf /brain/programming
:asd:
rm -rf /brain/programming
:asd:
Matrixbob
08-02-2008, 20:51
questo:
rm -rf /brain/programming
:asd:
Ehm al max:
tar cvf languageC.tar *.c
Che non si sa mai!
Sto scaricando sul P2P le lezioni Uninettuno di Java, vedo se da li tiro fuori qualcosa di buono.
rm -rf /brain/programming
:asd:
Ehm al max:
tar cvf languageC.tar *.c
Che non si sa mai!
Sto scaricando sul P2P le lezioni Uninettuno di Java, vedo se da li tiro fuori qualcosa di buono.
Matrixbob
08-02-2008, 20:52
Questo: http://www.python.it/doc/Howtothink/Howtothink-html-it/index.htm :)
Ma devo partire dall'INTRO dici?! :rolleyes: :mc: :stordita:
Ma devo partire dall'INTRO dici?! :rolleyes: :mc: :stordita:
AnonimoVeneziano
08-02-2008, 21:30
Personalmente ritengo Java un linguaggio migliore nel paradigma Object oriented di python.
In python non esiste il concetto di visibilità di attiributi e metodi nelle classi e supporta l'ereditarietà multipla.
Java mi piace molto di più da questo punto di vista. Ha 3 livelli di visibilità , non supporta ereditarietà multipla, ma ha le interfacce che permettono un' più accurato design object oriented rispetto a python. Inoltre venendo dal C non avrai problemi a trovarti subito con la sintassi di Java .
Io dico Java.
Ciao
PS = Ah, un altra cosa. Python permette letteralmente di aggiungere attributi e metodi dopo che la classe è stata instanziata ... anche questo non mi piace molto a livello di rigorosità del paradigma object oriented.
In python non esiste il concetto di visibilità di attiributi e metodi nelle classi e supporta l'ereditarietà multipla.
Java mi piace molto di più da questo punto di vista. Ha 3 livelli di visibilità , non supporta ereditarietà multipla, ma ha le interfacce che permettono un' più accurato design object oriented rispetto a python. Inoltre venendo dal C non avrai problemi a trovarti subito con la sintassi di Java .
Io dico Java.
Ciao
PS = Ah, un altra cosa. Python permette letteralmente di aggiungere attributi e metodi dopo che la classe è stata instanziata ... anche questo non mi piace molto a livello di rigorosità del paradigma object oriented.
cdimauro
08-02-2008, 21:35
Ma devo partire dall'INTRO dici?! :rolleyes: :mc: :stordita:
Se vuoi imparare il linguaggio, sì. Se t'interessa soltanto la programmazione a oggetti, puoi partire dal capitolo 12 http://www.python.it/doc/Howtothink/Howtothink-html-it/chap12.htm che è sufficientemente chiaro per chi mastica già un po' di programmazione.
Se vuoi imparare il linguaggio, sì. Se t'interessa soltanto la programmazione a oggetti, puoi partire dal capitolo 12 http://www.python.it/doc/Howtothink/Howtothink-html-it/chap12.htm che è sufficientemente chiaro per chi mastica già un po' di programmazione.
Matrixbob
08-02-2008, 21:36
Personalmente ritengo Java un linguaggio migliore nel paradigma Object oriented di python.
In python non esiste il concetto di visibilità di attiributi e metodi nelle classi e supporta l'ereditarietà multipla.
Java mi piace molto di più da questo punto di vista. Ha 3 livelli di visibilità , non supporta ereditarietà multipla, ma ha le interfacce che permettono un' più accurato design object oriented rispetto a python. Inoltre venendo dal C non avrai problemi a trovarti subito con la sintassi di Java .
Io dico Java.
Ciao
Si ma infatti Java è l'anti C++, non so se anche del C#, ma non mi pare.
Eterna gara chi è meglio tra C++ e Java, ma io a priori sono per Java.
Il fatto NON è che linguaggio imparare, ma come devo vedere le cose mentalmente.
Non è + 1 include di librerie, ma qui si importano le classi.
1 oggetto è 1 istanza della classe, cioè quando faccio new.
Devo fare sempre il catch delle eccezioni.
Posso estendere le classi esistenti, questo dovrebbe dare ereditarietà, mi pare.
CMQ mi sento deficiente col Java ... mi sembra tutto così strano ...
In python non esiste il concetto di visibilità di attiributi e metodi nelle classi e supporta l'ereditarietà multipla.
Java mi piace molto di più da questo punto di vista. Ha 3 livelli di visibilità , non supporta ereditarietà multipla, ma ha le interfacce che permettono un' più accurato design object oriented rispetto a python. Inoltre venendo dal C non avrai problemi a trovarti subito con la sintassi di Java .
Io dico Java.
Ciao
Si ma infatti Java è l'anti C++, non so se anche del C#, ma non mi pare.
Eterna gara chi è meglio tra C++ e Java, ma io a priori sono per Java.
Il fatto NON è che linguaggio imparare, ma come devo vedere le cose mentalmente.
Non è + 1 include di librerie, ma qui si importano le classi.
1 oggetto è 1 istanza della classe, cioè quando faccio new.
Devo fare sempre il catch delle eccezioni.
Posso estendere le classi esistenti, questo dovrebbe dare ereditarietà, mi pare.
CMQ mi sento deficiente col Java ... mi sembra tutto così strano ...
AnonimoVeneziano
08-02-2008, 21:39
Se vuoi imparare bene l'object oriented non ritengo il C++ il miglior linguaggio con cui partire perchè risulta essere piuttosto confuso da quel punto di vista, per lo meno molto più sia di Java che di Python.
Io ti consiglio di partire da Java, visto che sai il C per approdare al C++ c'è sempre tempo eventualmente dopo (e una volta imparato il Java sarà ancora più semplice :) Con questo però non voglio dire che sarà una passeggiata padroneggiare il C++)
Ciao
Io ti consiglio di partire da Java, visto che sai il C per approdare al C++ c'è sempre tempo eventualmente dopo (e una volta imparato il Java sarà ancora più semplice :) Con questo però non voglio dire che sarà una passeggiata padroneggiare il C++)
Ciao
Matrixbob
08-02-2008, 21:41
E poi perchè ai colloqui mi chiedono se so usare il Java2 enterprise? Che caz cambia dal Java normale? Cosa intendono?
AnonimoVeneziano
08-02-2008, 21:46
Java enterprise è un estensione delle librerie di Java per programmare applicazioni in campo enterprise attraverso strumenti come gli Enterprise JavaBeans , JTA e JMS.
Sono solo strumenti in più a disposizione rispetto all'edizione standard. Se vuoi imparare Java devi comunque partire dalla Java SE :)
Ciao
Sono solo strumenti in più a disposizione rispetto all'edizione standard. Se vuoi imparare Java devi comunque partire dalla Java SE :)
Ciao
cdimauro
08-02-2008, 21:46
Personalmente ritengo Java un linguaggio migliore nel paradigma Object oriented di python.
In python non esiste il concetto di visibilità di attiributi e metodi nelle classi
Sono tutti pubblici, è vero, ma in Java, C++, Delphi, ecc. puoi comunque "fregare" il linguaggio nel caso di dichiarazioni protected, usando i cracker (e volendo, conoscendo certi dettagli interni, anche quelli privati). :D
e supporta l'ereditarietà multipla.
Perché sarebbe un male?
Java mi piace molto di più da questo punto di vista. Ha 3 livelli di visibilità ,
Fino a qui, vedi sopra.
non supporta ereditarietà multipla, ma ha le interfacce che permettono un' più accurato design object oriented rispetto a python.
Le interfacce sono perfettamente emulabili grazie all'ereditarietà multipla. Il viceversa ovviamente non è vero. ;)
Inoltre venendo dal C non avrai problemi a trovarti subito con la sintassi di Java .
Sintassi poco leggibile e prona a produrre codice offuscato.
Meglio una sintassi semplice e più leggibile. ;)
Io dico Java.
Ciao
PS = Ah, un altra cosa. Python permette di aggiungere attributi e metodi alle classi andandoli ad aggiungere letteralmente dopo che la classe è stata instanziata ... anche questo non mi piace molto a livello di rigorosità del paradigma object oriented.
Dove sta scritto che il paradigma OO prevede rigorosamente la non mutabilità del comportamento di un oggetto? Da nessuna parte mi pare.
Anzi, un linguaggio dinamico come Python permette di approcciarsi alla programmazione OO in maniera decisamente più "naturale", poiché è sufficiente che un oggetto esponga una determinata interfaccia (metodi, attributi) affinché si possa dire che si comporti come tale.
Mi spiego meglio con un esempio molto semplice. Se voglio che un oggetto si comporti come un file / stream, è sufficiente che esponga il metodo read(): in questo modo posso passarlo a tutte le funzioni/metodi che si aspettano un file come parametro, e che su di esso invocheranno il metodo read() per leggerne i dati.
Io posso aggiungere un metodo read() a un'istanza o a un'intera classe (e quindi ereditato automaticamente da tutte le sue istanze) in qualsiasi momento, e in questo modo si "comporterà" come un file / stream. ;)
Tutto ciò con un linguaggio come C++ o Java NON è fattibile, perché ogni istanza discende da una ben precisa classe che è assolutamente immutabile.
In python non esiste il concetto di visibilità di attiributi e metodi nelle classi
Sono tutti pubblici, è vero, ma in Java, C++, Delphi, ecc. puoi comunque "fregare" il linguaggio nel caso di dichiarazioni protected, usando i cracker (e volendo, conoscendo certi dettagli interni, anche quelli privati). :D
e supporta l'ereditarietà multipla.
Perché sarebbe un male?
Java mi piace molto di più da questo punto di vista. Ha 3 livelli di visibilità ,
Fino a qui, vedi sopra.
non supporta ereditarietà multipla, ma ha le interfacce che permettono un' più accurato design object oriented rispetto a python.
Le interfacce sono perfettamente emulabili grazie all'ereditarietà multipla. Il viceversa ovviamente non è vero. ;)
Inoltre venendo dal C non avrai problemi a trovarti subito con la sintassi di Java .
Sintassi poco leggibile e prona a produrre codice offuscato.
Meglio una sintassi semplice e più leggibile. ;)
Io dico Java.
Ciao
PS = Ah, un altra cosa. Python permette di aggiungere attributi e metodi alle classi andandoli ad aggiungere letteralmente dopo che la classe è stata instanziata ... anche questo non mi piace molto a livello di rigorosità del paradigma object oriented.
Dove sta scritto che il paradigma OO prevede rigorosamente la non mutabilità del comportamento di un oggetto? Da nessuna parte mi pare.
Anzi, un linguaggio dinamico come Python permette di approcciarsi alla programmazione OO in maniera decisamente più "naturale", poiché è sufficiente che un oggetto esponga una determinata interfaccia (metodi, attributi) affinché si possa dire che si comporti come tale.
Mi spiego meglio con un esempio molto semplice. Se voglio che un oggetto si comporti come un file / stream, è sufficiente che esponga il metodo read(): in questo modo posso passarlo a tutte le funzioni/metodi che si aspettano un file come parametro, e che su di esso invocheranno il metodo read() per leggerne i dati.
Io posso aggiungere un metodo read() a un'istanza o a un'intera classe (e quindi ereditato automaticamente da tutte le sue istanze) in qualsiasi momento, e in questo modo si "comporterà" come un file / stream. ;)
Tutto ciò con un linguaggio come C++ o Java NON è fattibile, perché ogni istanza discende da una ben precisa classe che è assolutamente immutabile.
k0nt3
08-02-2008, 22:00
java è il miglior linguaggio che io abbia mai conosciuto per entrare nella mentalità object oriented. a volte ti costringe proprio :D
python è multiparadigma e quindi lo scarterei
python è multiparadigma e quindi lo scarterei
AnonimoVeneziano
08-02-2008, 22:05
Sono tutti pubblici, è vero, ma in Java, C++, Delphi, ecc. puoi comunque "fregare" il linguaggio nel caso di dichiarazioni protected, usando i cracker (e volendo, conoscendo certi dettagli interni, anche quelli privati). :D
Perché sarebbe un male?
Fino a qui, vedi sopra.
Le interfacce sono perfettamente emulabili grazie all'ereditarietà multipla. Il viceversa ovviamente non è vero. ;)
Sintassi poco leggibile e prona a produrre codice offuscato.
Meglio una sintassi semplice e più leggibile. ;)
Dove sta scritto che il paradigma OO prevede rigorosamente la non mutabilità del comportamento di un oggetto? Da nessuna parte mi pare.
Anzi, un linguaggio dinamico come Python permette di approcciarsi alla programmazione OO in maniera decisamente più "naturale", poiché è sufficiente che un oggetto esponga una determinata interfaccia (metodi, attributi) affinché si possa dire che si comporti come tale.
Mi spiego meglio con un esempio molto semplice. Se voglio che un oggetto si comporti come un file / stream, è sufficiente che esponga il metodo read(): in questo modo posso passarlo a tutte le funzioni/metodi che si aspettano un file come parametro, e che su di esso invocheranno il metodo read() per leggerne i dati.
Io posso aggiungere un metodo read() a un'istanza o a un'intera classe (e quindi ereditato automaticamente da tutte le sue istanze) in qualsiasi momento, e in questo modo si "comporterà" come un file / stream. ;)
Tutto ciò con un linguaggio come C++ o Java NON è fattibile, perché ogni istanza discende da una ben precisa classe che è assolutamente immutabile.
Bel papiro.
Ma io sto parlando di apprendimento non di potenza in generale.
Puoi craccare gli attributi protected e private? Bene, ma è una forzatura, non è la norma per il linguaggio. Il linguaggio ti guida verso un altra strada.
L'ereditarietà multipla porta,per chi non ha mai usato il paradigma object oriented, a mostruosi errori come schemi di ereditarietà a rombo .
Si può fare benissimo a meno dell'ereditarietà multipla e didatticamente non è il massimo.
Le interfacce sono uno strumento fantastico in Java . Formalizzano in maniera chiara il comportamento di una classe permettendo di separare nettamente l'implementazione dal comportamento. Tutto a favore di leggibilità e apprendimento al contrario dell'"emulazione" (come già dice il nome) tramite ereditarietà multipla.
Per quanto riguarda la sintassi ... beh, a me la sintassi di Python aborre :D . Ritengo Python un linguaggio dai tanti lati positivi, ma la sintassi per me non è uno di quelli. La sintassi è una questione di gusto comunque, ormai è provato da lunghe discussioni in questo stesso forum che non è un parametro di valutazione oggettivo valido.
Per l'ultima parte ... beh,non sta scritto da nessuna parte, ma didatticamente a mio parere può confondere non definendo bene la strada da seguire per creare un buon progetto OO , portando magari a ragionamenti come : " adesso definisco la classe, dopo una volta istanziata la classe ci aggiungo attributi e metodi", che per me sono sbagliati . Un oggetto è un entità con delle sue proprietà ed è importante che uno impari a definirle fin da subito.
Saluti
Perché sarebbe un male?
Fino a qui, vedi sopra.
Le interfacce sono perfettamente emulabili grazie all'ereditarietà multipla. Il viceversa ovviamente non è vero. ;)
Sintassi poco leggibile e prona a produrre codice offuscato.
Meglio una sintassi semplice e più leggibile. ;)
Dove sta scritto che il paradigma OO prevede rigorosamente la non mutabilità del comportamento di un oggetto? Da nessuna parte mi pare.
Anzi, un linguaggio dinamico come Python permette di approcciarsi alla programmazione OO in maniera decisamente più "naturale", poiché è sufficiente che un oggetto esponga una determinata interfaccia (metodi, attributi) affinché si possa dire che si comporti come tale.
Mi spiego meglio con un esempio molto semplice. Se voglio che un oggetto si comporti come un file / stream, è sufficiente che esponga il metodo read(): in questo modo posso passarlo a tutte le funzioni/metodi che si aspettano un file come parametro, e che su di esso invocheranno il metodo read() per leggerne i dati.
Io posso aggiungere un metodo read() a un'istanza o a un'intera classe (e quindi ereditato automaticamente da tutte le sue istanze) in qualsiasi momento, e in questo modo si "comporterà" come un file / stream. ;)
Tutto ciò con un linguaggio come C++ o Java NON è fattibile, perché ogni istanza discende da una ben precisa classe che è assolutamente immutabile.
Bel papiro.
Ma io sto parlando di apprendimento non di potenza in generale.
Puoi craccare gli attributi protected e private? Bene, ma è una forzatura, non è la norma per il linguaggio. Il linguaggio ti guida verso un altra strada.
L'ereditarietà multipla porta,per chi non ha mai usato il paradigma object oriented, a mostruosi errori come schemi di ereditarietà a rombo .
Si può fare benissimo a meno dell'ereditarietà multipla e didatticamente non è il massimo.
Le interfacce sono uno strumento fantastico in Java . Formalizzano in maniera chiara il comportamento di una classe permettendo di separare nettamente l'implementazione dal comportamento. Tutto a favore di leggibilità e apprendimento al contrario dell'"emulazione" (come già dice il nome) tramite ereditarietà multipla.
Per quanto riguarda la sintassi ... beh, a me la sintassi di Python aborre :D . Ritengo Python un linguaggio dai tanti lati positivi, ma la sintassi per me non è uno di quelli. La sintassi è una questione di gusto comunque, ormai è provato da lunghe discussioni in questo stesso forum che non è un parametro di valutazione oggettivo valido.
Per l'ultima parte ... beh,non sta scritto da nessuna parte, ma didatticamente a mio parere può confondere non definendo bene la strada da seguire per creare un buon progetto OO , portando magari a ragionamenti come : " adesso definisco la classe, dopo una volta istanziata la classe ci aggiungo attributi e metodi", che per me sono sbagliati . Un oggetto è un entità con delle sue proprietà ed è importante che uno impari a definirle fin da subito.
Saluti
^TiGeRShArK^
08-02-2008, 22:07
E poi perchè ai colloqui mi chiedono se so usare il Java2 enterprise? Che caz cambia dal Java normale? Cosa intendono?
e cmq lascia perdere ASSOLUTAMENTE J2EE.
Parti direttamente da JEE5 che è molto meglio.
(solo qua in italia ai colloqui possono chiedere ancora di J2EE :muro: )
e cmq lascia perdere ASSOLUTAMENTE J2EE.
Parti direttamente da JEE5 che è molto meglio.
(solo qua in italia ai colloqui possono chiedere ancora di J2EE :muro: )
AnonimoVeneziano
08-02-2008, 22:09
e cmq lascia perdere ASSOLUTAMENTE J2EE.
Parti direttamente da JEE5 che è molto meglio.
(solo qua in italia ai colloqui possono chiedere ancora di J2EE :muro: )
Ehm, credo che ai colloqui di lavoro con J2EE si riferiscano a JEE :stordita: :D
Parti direttamente da JEE5 che è molto meglio.
(solo qua in italia ai colloqui possono chiedere ancora di J2EE :muro: )
Ehm, credo che ai colloqui di lavoro con J2EE si riferiscano a JEE :stordita: :D
cdimauro
08-02-2008, 22:13
java è il miglior linguaggio che io abbia mai conosciuto per entrare nella mentalità object oriented. a volte ti costringe proprio :D
Hai dimenticato SmallTalk. ;)
python è multiparadigma e quindi lo scarterei
Ne abbiamo già discusso n volte, con n sufficientemente grande da non lasciar dubbi su com'è fatto Python e come funziona, ma vedo che puntualmente ritorni con lo stesso ritornello. :rolleyes:
Ripeti con me: in Python ogni elemento è un oggetto e ciò che si può fare (leggi: i paradigmi che si possono usare) dipende strettamente dal modo in cui li usi.
Hai dimenticato SmallTalk. ;)
python è multiparadigma e quindi lo scarterei
Ne abbiamo già discusso n volte, con n sufficientemente grande da non lasciar dubbi su com'è fatto Python e come funziona, ma vedo che puntualmente ritorni con lo stesso ritornello. :rolleyes:
Ripeti con me: in Python ogni elemento è un oggetto e ciò che si può fare (leggi: i paradigmi che si possono usare) dipende strettamente dal modo in cui li usi.
Matrixbob
08-02-2008, 22:14
e cmq lascia perdere ASSOLUTAMENTE J2EE.
Parti direttamente da JEE5 che è molto meglio.
(solo qua in italia ai colloqui possono chiedere ancora di J2EE :muro: )
Pensa che io pensavo fosse JSP/Servlet/Tomcat ...
CMQ mi ricodo che 8 anni fa cercavano programmatori Java con J2ee ed adesso cercano ancora quelli.
Come mai? Siamo sempre alla rincorsa di qualcosa?
Parti direttamente da JEE5 che è molto meglio.
(solo qua in italia ai colloqui possono chiedere ancora di J2EE :muro: )
Pensa che io pensavo fosse JSP/Servlet/Tomcat ...
CMQ mi ricodo che 8 anni fa cercavano programmatori Java con J2ee ed adesso cercano ancora quelli.
Come mai? Siamo sempre alla rincorsa di qualcosa?
Matrixbob
08-02-2008, 22:16
C'è qualcuno tra di voi che quando la prox settimana (lun o già dom sera) inizio a smanettare in Java i offre da farmi da mentore?! :)
[PS]
Ma la fisolofia della programmazione OO qual'è?
Che esistono solo oggetti che comunicano tra loro?
[PS]
Ma la fisolofia della programmazione OO qual'è?
Che esistono solo oggetti che comunicano tra loro?
Matrixbob
08-02-2008, 22:19
UE!
Non bisticciate sui linguaggi di programmazione Turing completi!
Non è il caso! Ogni uno usa quello che gli piace! :D
Non bisticciate sui linguaggi di programmazione Turing completi!
Non è il caso! Ogni uno usa quello che gli piace! :D
fek
08-02-2008, 22:20
Questo: http://www.python.it/doc/Howtothink/Howtothink-html-it/index.htm :)
Ormai sei peggio di Criceto con Apple :asd:
Ormai sei peggio di Criceto con Apple :asd:
cdimauro
08-02-2008, 22:24
Bel papiro.
Questo è niente: in genere sono decisamente più prolisso. :p
Ma io sto parlando di apprendimento non di potenza in generale.
Io non parlavo di potenza, ma di modellazione della realtà. ;)
Puoi craccare gli attributi protected e private? Bene, ma è una forzatura, non è la norma per il linguaggio. Il linguaggio ti guida verso un altra strada.
OK, ma non è detto che sia quella giusta.
L'ereditarietà multipla porta,per chi non ha mai usato il paradigma object oriented, a mostruosi errori come schemi di ereditarietà a rombo .
Li consente, ma arrivarci è tutto un altro paio di maniche.
Si può fare benissimo a meno dell'ereditarietà multipla e didatticamente non è il massimo.
Didatticamente è più semplice e naturale imparare il concetto che una classe possa ereditare da più classi, piuttosto che possa ereditare da una sola classe ed eventualmente implementare una o più interfacce.
Poi, come hai detto, si può anche fare a meno dell'ereditarietà multipla (e io generalmente ne faccio a meno, ma in alcuni casi m'è tornata molto comoda e utile).
Le interfacce sono uno strumento fantastico in Java . Formalizzano in maniera chiara il comportamento di una classe permettendo di separare nettamente l'implementazione dal comportamento. Tutto a favore di leggibilità e apprendimento al contrario dell'"emulazione" (come già dice il nome) tramite ereditarietà multipla.
Emulazione è un modo di dire: con l'ereditarietà multipla posso modellare "quello che voglio", per cui anche il comportamento delle interfacce.
Utilizzare delle classi (con l'ereditarietà multipla) per definire un "comportamento" non è un'emulazione né tanto meno una loro "castrazione", ma una precisa scelta di design. ;)
Per quanto riguarda la sintassi ... beh, a me la sintassi di Python aborre :D . Ritengo Python un linguaggio dai tanti lati positivi, ma la sintassi per me non è uno di quelli. La sintassi è una questione di gusto comunque, ormai è provato da lunghe discussioni in questo stesso forum che non è un parametro di valutazione oggettivo valido.
Esatto, per cui non ho nulla da dire: de gustibus, appunto. :p
Per l'ultima parte ... beh,non sta scritto da nessuna parte, ma didatticamente a mio parere può confondere non definendo bene la strada da seguire per creare un buon progetto OO , portando magari a ragionamenti come : " adesso definisco la classe, dopo una volta istanziata la classe ci aggiungo attributi e metodi", che per me sono sbagliati . Un oggetto è un entità con delle sue proprietà ed è importante che uno impari a definirle fin da subito.
Saluti
Ed è una cosa che puoi fare (e, anzi, generalmente si fa) benissimo in Python: quando dichiari una classe definisci anche i suoi attribuiti e/o metodi esattamente come faresti con Java, C#, C++, Delphi o qualunque altro linguaggio OO "tradizionale".
IN PIU' hai la possibilità di cambiare il comportamento di singole istanze o di un'intera classe a runtime, se il modello del tuo progetto lo prevede oppure ti accorgi che lo semplifica (il modello).
Riassumendo il tutto: con Python non hai nulla di meno di quanto offrono linguaggi come Java in termini di modellazione di una soluzione tramite il concetto di oggetto. Anzi, hai una semplificazione (grazie anche al weak typing) ed eventualmente degli strumenti aggiuntivi. ;)
Questo è niente: in genere sono decisamente più prolisso. :p
Ma io sto parlando di apprendimento non di potenza in generale.
Io non parlavo di potenza, ma di modellazione della realtà. ;)
Puoi craccare gli attributi protected e private? Bene, ma è una forzatura, non è la norma per il linguaggio. Il linguaggio ti guida verso un altra strada.
OK, ma non è detto che sia quella giusta.
L'ereditarietà multipla porta,per chi non ha mai usato il paradigma object oriented, a mostruosi errori come schemi di ereditarietà a rombo .
Li consente, ma arrivarci è tutto un altro paio di maniche.
Si può fare benissimo a meno dell'ereditarietà multipla e didatticamente non è il massimo.
Didatticamente è più semplice e naturale imparare il concetto che una classe possa ereditare da più classi, piuttosto che possa ereditare da una sola classe ed eventualmente implementare una o più interfacce.
Poi, come hai detto, si può anche fare a meno dell'ereditarietà multipla (e io generalmente ne faccio a meno, ma in alcuni casi m'è tornata molto comoda e utile).
Le interfacce sono uno strumento fantastico in Java . Formalizzano in maniera chiara il comportamento di una classe permettendo di separare nettamente l'implementazione dal comportamento. Tutto a favore di leggibilità e apprendimento al contrario dell'"emulazione" (come già dice il nome) tramite ereditarietà multipla.
Emulazione è un modo di dire: con l'ereditarietà multipla posso modellare "quello che voglio", per cui anche il comportamento delle interfacce.
Utilizzare delle classi (con l'ereditarietà multipla) per definire un "comportamento" non è un'emulazione né tanto meno una loro "castrazione", ma una precisa scelta di design. ;)
Per quanto riguarda la sintassi ... beh, a me la sintassi di Python aborre :D . Ritengo Python un linguaggio dai tanti lati positivi, ma la sintassi per me non è uno di quelli. La sintassi è una questione di gusto comunque, ormai è provato da lunghe discussioni in questo stesso forum che non è un parametro di valutazione oggettivo valido.
Esatto, per cui non ho nulla da dire: de gustibus, appunto. :p
Per l'ultima parte ... beh,non sta scritto da nessuna parte, ma didatticamente a mio parere può confondere non definendo bene la strada da seguire per creare un buon progetto OO , portando magari a ragionamenti come : " adesso definisco la classe, dopo una volta istanziata la classe ci aggiungo attributi e metodi", che per me sono sbagliati . Un oggetto è un entità con delle sue proprietà ed è importante che uno impari a definirle fin da subito.
Saluti
Ed è una cosa che puoi fare (e, anzi, generalmente si fa) benissimo in Python: quando dichiari una classe definisci anche i suoi attribuiti e/o metodi esattamente come faresti con Java, C#, C++, Delphi o qualunque altro linguaggio OO "tradizionale".
IN PIU' hai la possibilità di cambiare il comportamento di singole istanze o di un'intera classe a runtime, se il modello del tuo progetto lo prevede oppure ti accorgi che lo semplifica (il modello).
Riassumendo il tutto: con Python non hai nulla di meno di quanto offrono linguaggi come Java in termini di modellazione di una soluzione tramite il concetto di oggetto. Anzi, hai una semplificazione (grazie anche al weak typing) ed eventualmente degli strumenti aggiuntivi. ;)
cdimauro
08-02-2008, 22:25
Ma la fisolofia della programmazione OO qual'è?
Che esistono solo oggetti che comunicano tra loro?
http://it.wikipedia.org/wiki/Programmazione_orientata_agli_oggetti
Che esistono solo oggetti che comunicano tra loro?
http://it.wikipedia.org/wiki/Programmazione_orientata_agli_oggetti
cdimauro
08-02-2008, 22:26
Ormai sei peggio di Criceto con Apple :asd:
:eek: Ma io non dico cose insensate o false!!! :cry:
:eek: Ma io non dico cose insensate o false!!! :cry:
fek
08-02-2008, 22:30
:eek: Ma io non dico cose insensate o false!!! :cry:
Ma sei quasi altrettanto zelota :D
Ma sei quasi altrettanto zelota :D
cdimauro
08-02-2008, 22:33
Solo io? http://www.hwupgrade.it/forum/showthread.php?t=1671120 :fiufiu: :p
k0nt3
08-02-2008, 22:54
Pensa che io pensavo fosse JSP/Servlet/Tomcat ...
CMQ mi ricodo che 8 anni fa cercavano programmatori Java con J2ee ed adesso cercano ancora quelli.
Come mai? Siamo sempre alla rincorsa di qualcosa?
in effetti è jsp/servlet/java beans ecc.. JEE non è altro che una specifica in realtà. poi i vari tomcat, jboss, glassfish implementano più o meno parti di questa specifica
CMQ mi ricodo che 8 anni fa cercavano programmatori Java con J2ee ed adesso cercano ancora quelli.
Come mai? Siamo sempre alla rincorsa di qualcosa?
in effetti è jsp/servlet/java beans ecc.. JEE non è altro che una specifica in realtà. poi i vari tomcat, jboss, glassfish implementano più o meno parti di questa specifica
fek
08-02-2008, 22:57
Solo io? http://www.hwupgrade.it/forum/showthread.php?t=1671120 :fiufiu: :p
Ma Gunnerson non e' uno zelota :D
Ma Gunnerson non e' uno zelota :D
k0nt3
08-02-2008, 22:57
Hai dimenticato SmallTalk. ;)
no per me non è un linguaggio adatto. forse perchè lo conosco molto poco, ma visto che sono in buona compagnia ci sarà un motivo :p
Ne abbiamo già discusso n volte, con n sufficientemente grande da non lasciar dubbi su com'è fatto Python e come funziona, ma vedo che puntualmente ritorni con lo stesso ritornello. :rolleyes:
Ripeti con me: in Python ogni elemento è un oggetto e ciò che si può fare (leggi: i paradigmi che si possono usare) dipende strettamente dal modo in cui li usi.
python è e sarà sempre multiparadigma
no per me non è un linguaggio adatto. forse perchè lo conosco molto poco, ma visto che sono in buona compagnia ci sarà un motivo :p
Ne abbiamo già discusso n volte, con n sufficientemente grande da non lasciar dubbi su com'è fatto Python e come funziona, ma vedo che puntualmente ritorni con lo stesso ritornello. :rolleyes:
Ripeti con me: in Python ogni elemento è un oggetto e ciò che si può fare (leggi: i paradigmi che si possono usare) dipende strettamente dal modo in cui li usi.
python è e sarà sempre multiparadigma
AnonimoVeneziano
08-02-2008, 23:02
Questo è niente: in genere sono decisamente più prolisso. :p
Ahimè ... lo so :asd:
Io non parlavo di potenza, ma di modellazione della realtà. ;)
E cos'è la potenza di un linguaggio se non la sua capacità di modellare la realtà? (del problema)
OK, ma non è detto che sia quella giusta.
Beh, per quanto mi riguarda il permettere di accedere certi attributi solo in maniera privata può essere molto utile.
Io faccio una classe che contiene e gestisce degli elementi. Inizialmente per implementare questo comportamento uso una lista (in python) come attributo, poi però l'implementatore della classe si accorge di non avere bisogno di una lista perchè la classe non deve modificare gli elementi, così decide di cambiare l'implementazione usando una tupla.
Con accesso libero ai membri niente vieta ad un cliente della classe di prendersi la lista e farci un "obj.attributo.append(x)" che , dopo il cambiamento da lista a tupla diventerà un espressione invalida. Definendo l'attributo come private e regolando l'accesso allo stesso attraverso dei metodi si sarebbe potuto evitare questo inconveniente.
Li consente, ma arrivarci è tutto un altro paio di maniche.
Beh, se li consente allora didatticamente è meglio un linguaggio che non li consente ;)
Didatticamente è più semplice e naturale imparare il concetto che una classe possa ereditare da più classi, piuttosto che possa ereditare da una sola classe ed eventualmente implementare una o più interfacce.
Poi, come hai detto, si può anche fare a meno dell'ereditarietà multipla (e io generalmente ne faccio a meno, ma in alcuni casi m'è tornata molto comoda e utile).
Sinceramente non ne vedo il motivo. Io sono contro all'ereditarietà multipla perchè può portare ad errori in generale, non perchè è facile o difficile da apprendere. La possibilità di design errato usando l'ereditarietà multipla è sicuramente maggiore rispetto a quando non la si usa. Chiaro che se uno ha acquisito dimestichezza col paradigma non succede, ma stiamo parlando di principianti, e per un principiante è facile :)
Emulazione è un modo di dire: con l'ereditarietà multipla posso modellare "quello che voglio", per cui anche il comportamento delle interfacce.
Non puoi negare che però è più chiaro in Java perchè c'è un elemento facente parte del linguaggio apposito per rappresentarle. Quando ho imparato il C++ (mio primo linguaggio OO) non ho capito immediatamente a che servissero le classi astratte. Dopo aver imparato il Java e averlo usato un po' in OO mi è stato subito chiaro.
Utilizzare delle classi (con l'ereditarietà multipla) per definire un "comportamento" non è un'emulazione né tanto meno una loro "castrazione", ma una precisa scelta di design. ;)
Precisa, ma per me è più caotica
Ed è una cosa che puoi fare (e, anzi, generalmente si fa) benissimo in Python: quando dichiari una classe definisci anche i suoi attribuiti e/o metodi esattamente come faresti con Java, C#, C++, Delphi o qualunque altro linguaggio OO "tradizionale".
IN PIU' hai la possibilità di cambiare il comportamento di singole istanze o di un'intera classe a runtime, se il modello del tuo progetto lo prevede oppure ti accorgi che lo semplifica (il modello).
Riassumendo il tutto: con Python non hai nulla di meno di quanto offrono linguaggi come Java in termini di modellazione di una soluzione tramite il concetto di oggetto. Anzi, hai una semplificazione (grazie anche al weak typing) ed eventualmente degli strumenti aggiuntivi. ;)
Non ho mai detto che con python hai qualcosa in meno (ritorniamo al discorso di potenza espressiva), sto solo dicendo che tutte queste possibilità (di definire gli attributi nella definizione della classe, dentro il costruttore, dentro i metodi, addirittura dopo l'instanziamento a runtime: praticamente ovunque si ha un reference alla istanza di classe) possono creare confusione al neo-programmatore OO.
Ciao
Ahimè ... lo so :asd:
Io non parlavo di potenza, ma di modellazione della realtà. ;)
E cos'è la potenza di un linguaggio se non la sua capacità di modellare la realtà? (del problema)
OK, ma non è detto che sia quella giusta.
Beh, per quanto mi riguarda il permettere di accedere certi attributi solo in maniera privata può essere molto utile.
Io faccio una classe che contiene e gestisce degli elementi. Inizialmente per implementare questo comportamento uso una lista (in python) come attributo, poi però l'implementatore della classe si accorge di non avere bisogno di una lista perchè la classe non deve modificare gli elementi, così decide di cambiare l'implementazione usando una tupla.
Con accesso libero ai membri niente vieta ad un cliente della classe di prendersi la lista e farci un "obj.attributo.append(x)" che , dopo il cambiamento da lista a tupla diventerà un espressione invalida. Definendo l'attributo come private e regolando l'accesso allo stesso attraverso dei metodi si sarebbe potuto evitare questo inconveniente.
Li consente, ma arrivarci è tutto un altro paio di maniche.
Beh, se li consente allora didatticamente è meglio un linguaggio che non li consente ;)
Didatticamente è più semplice e naturale imparare il concetto che una classe possa ereditare da più classi, piuttosto che possa ereditare da una sola classe ed eventualmente implementare una o più interfacce.
Poi, come hai detto, si può anche fare a meno dell'ereditarietà multipla (e io generalmente ne faccio a meno, ma in alcuni casi m'è tornata molto comoda e utile).
Sinceramente non ne vedo il motivo. Io sono contro all'ereditarietà multipla perchè può portare ad errori in generale, non perchè è facile o difficile da apprendere. La possibilità di design errato usando l'ereditarietà multipla è sicuramente maggiore rispetto a quando non la si usa. Chiaro che se uno ha acquisito dimestichezza col paradigma non succede, ma stiamo parlando di principianti, e per un principiante è facile :)
Emulazione è un modo di dire: con l'ereditarietà multipla posso modellare "quello che voglio", per cui anche il comportamento delle interfacce.
Non puoi negare che però è più chiaro in Java perchè c'è un elemento facente parte del linguaggio apposito per rappresentarle. Quando ho imparato il C++ (mio primo linguaggio OO) non ho capito immediatamente a che servissero le classi astratte. Dopo aver imparato il Java e averlo usato un po' in OO mi è stato subito chiaro.
Utilizzare delle classi (con l'ereditarietà multipla) per definire un "comportamento" non è un'emulazione né tanto meno una loro "castrazione", ma una precisa scelta di design. ;)
Precisa, ma per me è più caotica
Ed è una cosa che puoi fare (e, anzi, generalmente si fa) benissimo in Python: quando dichiari una classe definisci anche i suoi attribuiti e/o metodi esattamente come faresti con Java, C#, C++, Delphi o qualunque altro linguaggio OO "tradizionale".
IN PIU' hai la possibilità di cambiare il comportamento di singole istanze o di un'intera classe a runtime, se il modello del tuo progetto lo prevede oppure ti accorgi che lo semplifica (il modello).
Riassumendo il tutto: con Python non hai nulla di meno di quanto offrono linguaggi come Java in termini di modellazione di una soluzione tramite il concetto di oggetto. Anzi, hai una semplificazione (grazie anche al weak typing) ed eventualmente degli strumenti aggiuntivi. ;)
Non ho mai detto che con python hai qualcosa in meno (ritorniamo al discorso di potenza espressiva), sto solo dicendo che tutte queste possibilità (di definire gli attributi nella definizione della classe, dentro il costruttore, dentro i metodi, addirittura dopo l'instanziamento a runtime: praticamente ovunque si ha un reference alla istanza di classe) possono creare confusione al neo-programmatore OO.
Ciao
cdimauro
08-02-2008, 23:04
Ma Gunnerson non e' uno zelota :D
Ehm, veramente mi riferivo a te che tiri spesso in ballo Gunnerson, Fowler, (Santo. Subito!) Kent, ecc. :fiufiu:
Ehm, veramente mi riferivo a te che tiri spesso in ballo Gunnerson, Fowler, (Santo. Subito!) Kent, ecc. :fiufiu:
cdimauro
08-02-2008, 23:07
no per me non è un linguaggio adatto. forse perchè lo conosco molto poco, ma visto che sono in buona compagnia ci sarà un motivo :p
Il motivo per cui l'ho tirato in ballo è perché è semplice vedere in SmallTalk il concetto di passaggio dei messaggi fra le istanze, che sono la pietra miliare della programmazione OO.
python è e sarà sempre multiparadigma
Non hai ancora capito il perché, però...
Un po' come il linguaggio macchina: ci puoi fare tutto, anche la metaprogrammazione. Chissà perché...
Il motivo per cui l'ho tirato in ballo è perché è semplice vedere in SmallTalk il concetto di passaggio dei messaggi fra le istanze, che sono la pietra miliare della programmazione OO.
python è e sarà sempre multiparadigma
Non hai ancora capito il perché, però...
Un po' come il linguaggio macchina: ci puoi fare tutto, anche la metaprogrammazione. Chissà perché...
marco.r
08-02-2008, 23:12
PS = Ah, un altra cosa. Python permette letteralmente di aggiungere attributi e metodi dopo che la classe è stata instanziata ... anche questo non mi piace molto a livello di rigorosità del paradigma object oriented.
E in che modo questo va contro il paradigma object oriented ? :confused:
Tanto piu' che nel padre dei linguaggi OO (Smalltalk) e' una cosa assolutamente naturale.
Ammetto pero' di essere di parte, in quanto sono un amante del duck typing e riesco ad apprezzare vincoli piu' statici solo in linguaggi che implementano un sistema di tipi decente (il che ne esclude la maggior parte, C++, Java e C# compresi).
E in che modo questo va contro il paradigma object oriented ? :confused:
Tanto piu' che nel padre dei linguaggi OO (Smalltalk) e' una cosa assolutamente naturale.
Ammetto pero' di essere di parte, in quanto sono un amante del duck typing e riesco ad apprezzare vincoli piu' statici solo in linguaggi che implementano un sistema di tipi decente (il che ne esclude la maggior parte, C++, Java e C# compresi).
AnonimoVeneziano
08-02-2008, 23:17
E in che modo questo va contro il paradigma object oriented ? :confused:
Tanto piu' che nel padre dei linguaggi OO (Smalltalk) e' una cosa assolutamente naturale.
Mi sono espresso male.
Parlavo di "rigorosità" in senso didattico. A mio parere più un linguaggio è rigido e definisce bene ciò che vuole esprimere con le sue strutture sintattiche e più è adatto all'insegnamento , aldilà della capacità espressiva grezza del linguaggio stesso. Tanto per intenderci all'epoca il pascal era uno di quelli.
Ammetto pero' di essere di parte, in quanto sono un amante del duck typing e riesco ad apprezzare vincoli piu' statici solo in linguaggi che implementano un sistema di tipi decente (il che ne esclude la maggior parte, C++, Java e C# compresi).
Proprio perchè il duck typing è il sinonimo stesso di quella poca rigidità didattica di cui ho parlato poco sopra preferisco consigliare Java al nostro thread starter :D
Tanto piu' che nel padre dei linguaggi OO (Smalltalk) e' una cosa assolutamente naturale.
Mi sono espresso male.
Parlavo di "rigorosità" in senso didattico. A mio parere più un linguaggio è rigido e definisce bene ciò che vuole esprimere con le sue strutture sintattiche e più è adatto all'insegnamento , aldilà della capacità espressiva grezza del linguaggio stesso. Tanto per intenderci all'epoca il pascal era uno di quelli.
Ammetto pero' di essere di parte, in quanto sono un amante del duck typing e riesco ad apprezzare vincoli piu' statici solo in linguaggi che implementano un sistema di tipi decente (il che ne esclude la maggior parte, C++, Java e C# compresi).
Proprio perchè il duck typing è il sinonimo stesso di quella poca rigidità didattica di cui ho parlato poco sopra preferisco consigliare Java al nostro thread starter :D
cdimauro
08-02-2008, 23:22
Ahimè ... lo so :asd:
Ah. Sei fortunato che non sono in vena oggi. :D
E cos'è la potenza di un linguaggio se non la sua capacità di modellare la realtà? (del problema)
Se vuoi usare questa definizione mi sta bene, ma non era mia intenzione spostare la discussione sul concetto di "potenza", perché si tende a svilire i concetti di cui si parla.
Beh, per quanto mi riguarda il permettere di accedere certi attributi solo in maniera privata può essere molto utile.
Io faccio una classe che contiene e gestisce degli elementi. Inizialmente per implementare questo comportamento uso una lista (in python) come attributo, poi però l'implementatore della classe si accorge di non avere bisogno di una lista perchè la classe non deve modificare gli elementi, così decide di cambiare l'implementazione usando una tupla.
Con accesso libero ai membri niente vieta ad un cliente della classe di prendersi la lista e farci un "obj.attributo.append(x)" che , dopo il cambiamento da lista a tupla diventerà un espressione invalida. Definendo l'attributo come private e regolando l'accesso allo stesso attraverso dei metodi si sarebbe potuto evitare questo inconveniente.
Chiaro, ma se permetti trovo sia decisamente peggio che un errore di design del progettista della classe mi porti a non poterla sfruttare (e subclassare) per risolvere i miei problemi.
Purtroppo è una cosa che m'è capitata non poche volte. :muro:
Beh, se li consente allora didatticamente è meglio un linguaggio che non li consente ;)
Se parti subito con l'ereditarietà multipla, può succedere. Ma un principiante ha ben altro a cui pensare all'inizio. :p
Sinceramente non ne vedo il motivo. Io sono contro all'ereditarietà multipla perchè può portare ad errori in generale, non perchè è facile o difficile da apprendere. La possibilità di design errato usando l'ereditarietà multipla è sicuramente maggiore rispetto a quando non la si usa. Chiaro che se uno ha acquisito dimestichezza col paradigma non succede, ma stiamo parlando di principianti, e per un principiante è facile :)
Puoi essere contro l'ereditarietà multipla, e posso anche essere comprenderlo, ma è più facile apprendere "naturalmente" questo concetto piuttosto che quello di ereditarietà singola + interfacce.
Poi sui problemi di design sono d'accordo: non avendo maturato adeguatamente lo strumento potrebbero presentarsi più facilmente nel primo caso piuttosto che nel secondo (ma anche col secondo è facile farsi scappare la mano e tirare fuori interfacce per la qualunque, anche quando non ce ne sarebbe bisogno ;)).
Non puoi negare che però è più chiaro in Java perchè c'è un elemento facente parte del linguaggio apposito per rappresentarle.
Sì, non ho difficoltà ad ammetterlo. :)
Quando ho imparato il C++ (mio primo linguaggio OO) non ho capito immediatamente a che servissero le classi astratte. Dopo aver imparato il Java e averlo usato un po' in OO mi è stato subito chiaro.
:mbe: Ma le classi astratte non ci sono anche in Java? :confused:
Precisa, ma per me è più caotica
Solo se la usi male, ma non era questo il punto. ;)
Non ho mai detto che con python hai qualcosa in meno (ritorniamo al discorso di potenza espressiva), sto solo dicendo che tutte queste possibilità (di definire gli attributi nella definizione della classe, dentro il costruttore, dentro i metodi, addirittura dopo l'instanziamento a runtime: praticamente ovunque si ha un reference alla istanza di classe) possono creare confusione al neo-programmatore OO.
Ciao
Indubbiamente, ma si tratta di argomenti più avanzati, ed è bene che siano affrontati in un secondo momento. Un po' come le interfacce che si studiano dopo aver appreso il concetto di classe e di ereditarietà. ;)
Ciao. Anzi: notte. :D
Ah. Sei fortunato che non sono in vena oggi. :D
E cos'è la potenza di un linguaggio se non la sua capacità di modellare la realtà? (del problema)
Se vuoi usare questa definizione mi sta bene, ma non era mia intenzione spostare la discussione sul concetto di "potenza", perché si tende a svilire i concetti di cui si parla.
Beh, per quanto mi riguarda il permettere di accedere certi attributi solo in maniera privata può essere molto utile.
Io faccio una classe che contiene e gestisce degli elementi. Inizialmente per implementare questo comportamento uso una lista (in python) come attributo, poi però l'implementatore della classe si accorge di non avere bisogno di una lista perchè la classe non deve modificare gli elementi, così decide di cambiare l'implementazione usando una tupla.
Con accesso libero ai membri niente vieta ad un cliente della classe di prendersi la lista e farci un "obj.attributo.append(x)" che , dopo il cambiamento da lista a tupla diventerà un espressione invalida. Definendo l'attributo come private e regolando l'accesso allo stesso attraverso dei metodi si sarebbe potuto evitare questo inconveniente.
Chiaro, ma se permetti trovo sia decisamente peggio che un errore di design del progettista della classe mi porti a non poterla sfruttare (e subclassare) per risolvere i miei problemi.
Purtroppo è una cosa che m'è capitata non poche volte. :muro:
Beh, se li consente allora didatticamente è meglio un linguaggio che non li consente ;)
Se parti subito con l'ereditarietà multipla, può succedere. Ma un principiante ha ben altro a cui pensare all'inizio. :p
Sinceramente non ne vedo il motivo. Io sono contro all'ereditarietà multipla perchè può portare ad errori in generale, non perchè è facile o difficile da apprendere. La possibilità di design errato usando l'ereditarietà multipla è sicuramente maggiore rispetto a quando non la si usa. Chiaro che se uno ha acquisito dimestichezza col paradigma non succede, ma stiamo parlando di principianti, e per un principiante è facile :)
Puoi essere contro l'ereditarietà multipla, e posso anche essere comprenderlo, ma è più facile apprendere "naturalmente" questo concetto piuttosto che quello di ereditarietà singola + interfacce.
Poi sui problemi di design sono d'accordo: non avendo maturato adeguatamente lo strumento potrebbero presentarsi più facilmente nel primo caso piuttosto che nel secondo (ma anche col secondo è facile farsi scappare la mano e tirare fuori interfacce per la qualunque, anche quando non ce ne sarebbe bisogno ;)).
Non puoi negare che però è più chiaro in Java perchè c'è un elemento facente parte del linguaggio apposito per rappresentarle.
Sì, non ho difficoltà ad ammetterlo. :)
Quando ho imparato il C++ (mio primo linguaggio OO) non ho capito immediatamente a che servissero le classi astratte. Dopo aver imparato il Java e averlo usato un po' in OO mi è stato subito chiaro.
:mbe: Ma le classi astratte non ci sono anche in Java? :confused:
Precisa, ma per me è più caotica
Solo se la usi male, ma non era questo il punto. ;)
Non ho mai detto che con python hai qualcosa in meno (ritorniamo al discorso di potenza espressiva), sto solo dicendo che tutte queste possibilità (di definire gli attributi nella definizione della classe, dentro il costruttore, dentro i metodi, addirittura dopo l'instanziamento a runtime: praticamente ovunque si ha un reference alla istanza di classe) possono creare confusione al neo-programmatore OO.
Ciao
Indubbiamente, ma si tratta di argomenti più avanzati, ed è bene che siano affrontati in un secondo momento. Un po' come le interfacce che si studiano dopo aver appreso il concetto di classe e di ereditarietà. ;)
Ciao. Anzi: notte. :D
^TiGeRShArK^
08-02-2008, 23:39
Ormai sei peggio di Criceto con Apple :asd:
:rotfl:
:rotfl:
marco.r
08-02-2008, 23:48
Beh, per quanto mi riguarda il permettere di accedere certi attributi solo in maniera privata può essere molto utile.
Il comportamento di python non e' che mi piaccia molto in questo senso, ma non e' cosi' grave, soprattutto se si segue un certo criterio. In particolare e' prassi considerare privati tutti gli attributi di istanza che cominciano con un doppio underscore, tanto piu' che poi vengono visti con dei nomi particolari (ad esempio l'attributo __x della classe Foo viene visto dall'esterno come _Foo__x o giu' di li'). Andare a toccarli vuol dire andare scientemente in cerca di rogne.
Sinceramente non ne vedo il motivo. Io sono contro all'ereditarietà multipla perchè può portare ad errori in generale, non perchè è facile o difficile da apprendere. La possibilità di design errato usando l'ereditarietà multipla è sicuramente maggiore rispetto a quando non la si usa. Chiaro che se uno ha acquisito dimestichezza col paradigma non succede, ma stiamo parlando di principianti, e per un principiante è facile :)
Ci sono dei casi in cui torna comoda (potrei portare un paio di esempi), anche se tipicamente non serve poi molto in un linguaggio dinamico.
Non ho mai detto che con python hai qualcosa in meno (ritorniamo al discorso di potenza espressiva), sto solo dicendo che tutte queste possibilità (di definire gli attributi nella definizione della classe, dentro il costruttore, dentro i metodi, addirittura dopo l'instanziamento a runtime: praticamente ovunque si ha un reference alla istanza di classe) possono creare confusione al neo-programmatore OO.
Non direi. Dall'altra parte abbiamo classi ed interfacce, tipi, attributi e metodi privati piuttosto che pubblici etc... non mi sembra meno complicato.
E' anche una questione di punto di vista. In python puoi definire gli attributi quando vuoi, basta avere l'oggetto sottomano. Punto. Non mi sembra complicato, quelli che elenchi sono casi particolari (a parte il primo: non si possono definire attributi di istanza nella definizione della classe, e d'altra parte non si ha alcuna istanza sottomano per farlo...).
Il comportamento di python non e' che mi piaccia molto in questo senso, ma non e' cosi' grave, soprattutto se si segue un certo criterio. In particolare e' prassi considerare privati tutti gli attributi di istanza che cominciano con un doppio underscore, tanto piu' che poi vengono visti con dei nomi particolari (ad esempio l'attributo __x della classe Foo viene visto dall'esterno come _Foo__x o giu' di li'). Andare a toccarli vuol dire andare scientemente in cerca di rogne.
Sinceramente non ne vedo il motivo. Io sono contro all'ereditarietà multipla perchè può portare ad errori in generale, non perchè è facile o difficile da apprendere. La possibilità di design errato usando l'ereditarietà multipla è sicuramente maggiore rispetto a quando non la si usa. Chiaro che se uno ha acquisito dimestichezza col paradigma non succede, ma stiamo parlando di principianti, e per un principiante è facile :)
Ci sono dei casi in cui torna comoda (potrei portare un paio di esempi), anche se tipicamente non serve poi molto in un linguaggio dinamico.
Non ho mai detto che con python hai qualcosa in meno (ritorniamo al discorso di potenza espressiva), sto solo dicendo che tutte queste possibilità (di definire gli attributi nella definizione della classe, dentro il costruttore, dentro i metodi, addirittura dopo l'instanziamento a runtime: praticamente ovunque si ha un reference alla istanza di classe) possono creare confusione al neo-programmatore OO.
Non direi. Dall'altra parte abbiamo classi ed interfacce, tipi, attributi e metodi privati piuttosto che pubblici etc... non mi sembra meno complicato.
E' anche una questione di punto di vista. In python puoi definire gli attributi quando vuoi, basta avere l'oggetto sottomano. Punto. Non mi sembra complicato, quelli che elenchi sono casi particolari (a parte il primo: non si possono definire attributi di istanza nella definizione della classe, e d'altra parte non si ha alcuna istanza sottomano per farlo...).
AnonimoVeneziano
08-02-2008, 23:57
Ah. Sei fortunato che non sono in vena oggi. :D
:D
Se vuoi usare questa definizione mi sta bene, ma non era mia intenzione spostare la discussione sul concetto di "potenza", perché si tende a svilire i concetti di cui si parla.
Beh, "potenza" è una parola che se usata nella sezione "Console e giochi per console" , magari con un PS3 e Xbox360 inserite nel contesto, può dare luogo ad un conflitto mondiale :D
In questo contesto speravo fosse un po' meno equivocabile, ma per me va bene continuare ad usare il termine "capacità espressiva" o al max "potere espressivo" :)
Chiaro, ma se permetti trovo sia decisamente peggio che un errore di design del progettista della classe mi porti a non poterla sfruttare (e subclassare) per risolvere i miei problemi.
Beh, gli errori di design possono capitare. Il vantaggio è che con la visibilità puoi comunque permettere ai clienti di accedere agli attributi private (basta creare dei metodi getter e setter), ma nel contempo gli permetti di farlo solo in modo sicuro. Cambia l'implementazione interna dell'attributo? Cambi anche implementazione di getter e setter di conseguenza. L'interfaccia all'oggetto non cambia e il codice rimane compatibile. Con la visibilità permetti all'utilizzatore di vedere solo il comportamento della classe e non quello che ci sta sotto il cofano (che può cambiare quanto vuoi, basta che il comportamento della classe attraverso i metodi sia lo stesso )
Se parti subito con l'ereditarietà multipla, può succedere. Ma un principiante ha ben altro a cui pensare all'inizio. :p
Appunto, lasciamoglielo per quando imparerà il python :asd:
Puoi essere contro l'ereditarietà multipla, e posso anche essere comprenderlo, ma è più facile apprendere "naturalmente" questo concetto piuttosto che quello di ereditarietà singola + interfacce.
Mah, non ne sono così convinto...
Comunque per me non è una questione di naturalezza o meno nell'apprendimento. Converrai con me che una volta capito cos'è l'ereditarietà , che è la parte difficile, l'apprendere l'ereditarietà singola o multipla non è difficile. All'inizio è solo una regola : "Non puoi ereditare da più di una classe" . Il significato viene da se dopo ;)
Poi sui problemi di design sono d'accordo: non avendo maturato adeguatamente lo strumento potrebbero presentarsi più facilmente nel primo caso piuttosto che nel secondo (ma anche col secondo è facile farsi scappare la mano e tirare fuori interfacce per la qualunque, anche quando non ce ne sarebbe bisogno ;)).
Beh, sono d'accordo. Si possono fare pasticci con tutto :)
:mbe: Ma le classi astratte non ci sono anche in Java? :confused:
Beh, stavamo parlando di interfacce e visto che in C++ non esistono come concetto l'unico modo per "emularle" è l'uso di classi astratte con solo metodi virtual puri ;)
Indubbiamente, ma si tratta di argomenti più avanzati, ed è bene che siano affrontati in un secondo momento. Un po' come le interfacce che si studiano dopo aver appreso il concetto di classe e di ereditarietà. ;)
Si, ma il fatto che sia possibile già per me significa che non c'è la rigidità tipica che aiuta tanto nell'apprendimento.
Python è un linguaggio che mi piace, lo ammetto. Odio di esso solo la sintassi e certe scelte , come ad esempio quella di permettere certi costrutti che se usati impropriamente possono veramente rendere un programma illeggibile e vietare scritture come "+=" , "*=", ... etc usando come scusa che diminuiscono la leggibilità :doh:
Ciao. Anzi: notte. :D
Notte :)
:D
Se vuoi usare questa definizione mi sta bene, ma non era mia intenzione spostare la discussione sul concetto di "potenza", perché si tende a svilire i concetti di cui si parla.
Beh, "potenza" è una parola che se usata nella sezione "Console e giochi per console" , magari con un PS3 e Xbox360 inserite nel contesto, può dare luogo ad un conflitto mondiale :D
In questo contesto speravo fosse un po' meno equivocabile, ma per me va bene continuare ad usare il termine "capacità espressiva" o al max "potere espressivo" :)
Chiaro, ma se permetti trovo sia decisamente peggio che un errore di design del progettista della classe mi porti a non poterla sfruttare (e subclassare) per risolvere i miei problemi.
Beh, gli errori di design possono capitare. Il vantaggio è che con la visibilità puoi comunque permettere ai clienti di accedere agli attributi private (basta creare dei metodi getter e setter), ma nel contempo gli permetti di farlo solo in modo sicuro. Cambia l'implementazione interna dell'attributo? Cambi anche implementazione di getter e setter di conseguenza. L'interfaccia all'oggetto non cambia e il codice rimane compatibile. Con la visibilità permetti all'utilizzatore di vedere solo il comportamento della classe e non quello che ci sta sotto il cofano (che può cambiare quanto vuoi, basta che il comportamento della classe attraverso i metodi sia lo stesso )
Se parti subito con l'ereditarietà multipla, può succedere. Ma un principiante ha ben altro a cui pensare all'inizio. :p
Appunto, lasciamoglielo per quando imparerà il python :asd:
Puoi essere contro l'ereditarietà multipla, e posso anche essere comprenderlo, ma è più facile apprendere "naturalmente" questo concetto piuttosto che quello di ereditarietà singola + interfacce.
Mah, non ne sono così convinto...
Comunque per me non è una questione di naturalezza o meno nell'apprendimento. Converrai con me che una volta capito cos'è l'ereditarietà , che è la parte difficile, l'apprendere l'ereditarietà singola o multipla non è difficile. All'inizio è solo una regola : "Non puoi ereditare da più di una classe" . Il significato viene da se dopo ;)
Poi sui problemi di design sono d'accordo: non avendo maturato adeguatamente lo strumento potrebbero presentarsi più facilmente nel primo caso piuttosto che nel secondo (ma anche col secondo è facile farsi scappare la mano e tirare fuori interfacce per la qualunque, anche quando non ce ne sarebbe bisogno ;)).
Beh, sono d'accordo. Si possono fare pasticci con tutto :)
:mbe: Ma le classi astratte non ci sono anche in Java? :confused:
Beh, stavamo parlando di interfacce e visto che in C++ non esistono come concetto l'unico modo per "emularle" è l'uso di classi astratte con solo metodi virtual puri ;)
Indubbiamente, ma si tratta di argomenti più avanzati, ed è bene che siano affrontati in un secondo momento. Un po' come le interfacce che si studiano dopo aver appreso il concetto di classe e di ereditarietà. ;)
Si, ma il fatto che sia possibile già per me significa che non c'è la rigidità tipica che aiuta tanto nell'apprendimento.
Python è un linguaggio che mi piace, lo ammetto. Odio di esso solo la sintassi e certe scelte , come ad esempio quella di permettere certi costrutti che se usati impropriamente possono veramente rendere un programma illeggibile e vietare scritture come "+=" , "*=", ... etc usando come scusa che diminuiscono la leggibilità :doh:
Ciao. Anzi: notte. :D
Notte :)
AnonimoVeneziano
09-02-2008, 00:13
Il comportamento di python non e' che mi piaccia molto in questo senso, ma non e' cosi' grave, soprattutto se si segue un certo criterio. In particolare e' prassi considerare privati tutti gli attributi di istanza che cominciano con un doppio underscore, tanto piu' che poi vengono visti con dei nomi particolari (ad esempio l'attributo __x della classe Foo viene visto dall'esterno come _Foo__x o giu' di li'). Andare a toccarli vuol dire andare scientemente in cerca di rogne.
Tralasciando il fatto che ABBBBBBBBBBBBORRRRRRRO ( con B e R a piacere :asd: ) tutto ciò che in python è scritto con doppio underscore (ed è uno dei motivi che mi fa odiare la sintassi python ), concordo con te che è un comportamento "non critico" se si segue una certa convenzione...
Certo, a mio parere le costrizioni sono meglio delle convenzioni, anche se in parte ti limitano la libertà (basta che siano a fin di bene), ma è ancora più vero se tutto ciò è a fini didattici. Visto che il thread starter voleva un linguaggio con cui imparare l'OO credo che un po' di "costrizioni buone" possano fargli solo bene.
Ci sono dei casi in cui torna comoda (potrei portare un paio di esempi), anche se tipicamente non serve poi molto in un linguaggio dinamico.
Non ne dubito, comunque è sempre rimpiazzabile.
Non direi. Dall'altra parte abbiamo classi ed interfacce, tipi, attributi e metodi privati piuttosto che pubblici etc... non mi sembra meno complicato.
E' anche una questione di punto di vista. In python puoi definire gli attributi quando vuoi, basta avere l'oggetto sottomano. Punto. Non mi sembra complicato, quelli che elenchi sono casi particolari (a parte il primo: non si possono definire attributi di istanza nella definizione della classe, e d'altra parte non si ha alcuna istanza sottomano per farlo...).
Non è una questione di complicato o meno nell'imparare un linguaggio. Imparare un linguaggio in genere è piuttosto semplice (per uno che ha già programmato), il problema è acquisire la forma mentis del programmatore OO. Anche se il Java (forse) nella sintassi è un po' più complicato, vuoi perchè deriva dal C, vuoi perchè è un linguaggio più "classico" mentre Python è un linguaggio di scripting dove in genere la semplicità , la velocità di scrittura del codice e la compattezza sono componenti fondamentali ... etc non vuol dire che sia più facile imparare il paradigma OO col Python che col Java. Io ritengo personalmente che sia il contrario, perchè il Java ti guida di più nell'apprendimento. Inoltre Matrixbob viene dal C. Imparare la sintassi di Java e la tipizzazione forte per lui non dovrebbe proprio essere un problema (anzi, potrebbe di più esserlo l'apprendimento della tipizzazione dinamica del python). Inoltre voleva trovare un posto di lavoro e sicuramente qua Java la fa da padrone su tutti.
EDIT: Ah, scusa, mi sono dimenticato una cosa ...
a parte il primo: non si possono definire attributi di istanza nella definizione della classe, e d'altra parte non si ha alcuna istanza sottomano per farlo..
io intendo questo
class classe2:
a = [1,2]
def __init__(self):
return
>>> b = classe2()
>>> b.a
[1, 2]
Ciao
Tralasciando il fatto che ABBBBBBBBBBBBORRRRRRRO ( con B e R a piacere :asd: ) tutto ciò che in python è scritto con doppio underscore (ed è uno dei motivi che mi fa odiare la sintassi python ), concordo con te che è un comportamento "non critico" se si segue una certa convenzione...
Certo, a mio parere le costrizioni sono meglio delle convenzioni, anche se in parte ti limitano la libertà (basta che siano a fin di bene), ma è ancora più vero se tutto ciò è a fini didattici. Visto che il thread starter voleva un linguaggio con cui imparare l'OO credo che un po' di "costrizioni buone" possano fargli solo bene.
Ci sono dei casi in cui torna comoda (potrei portare un paio di esempi), anche se tipicamente non serve poi molto in un linguaggio dinamico.
Non ne dubito, comunque è sempre rimpiazzabile.
Non direi. Dall'altra parte abbiamo classi ed interfacce, tipi, attributi e metodi privati piuttosto che pubblici etc... non mi sembra meno complicato.
E' anche una questione di punto di vista. In python puoi definire gli attributi quando vuoi, basta avere l'oggetto sottomano. Punto. Non mi sembra complicato, quelli che elenchi sono casi particolari (a parte il primo: non si possono definire attributi di istanza nella definizione della classe, e d'altra parte non si ha alcuna istanza sottomano per farlo...).
Non è una questione di complicato o meno nell'imparare un linguaggio. Imparare un linguaggio in genere è piuttosto semplice (per uno che ha già programmato), il problema è acquisire la forma mentis del programmatore OO. Anche se il Java (forse) nella sintassi è un po' più complicato, vuoi perchè deriva dal C, vuoi perchè è un linguaggio più "classico" mentre Python è un linguaggio di scripting dove in genere la semplicità , la velocità di scrittura del codice e la compattezza sono componenti fondamentali ... etc non vuol dire che sia più facile imparare il paradigma OO col Python che col Java. Io ritengo personalmente che sia il contrario, perchè il Java ti guida di più nell'apprendimento. Inoltre Matrixbob viene dal C. Imparare la sintassi di Java e la tipizzazione forte per lui non dovrebbe proprio essere un problema (anzi, potrebbe di più esserlo l'apprendimento della tipizzazione dinamica del python). Inoltre voleva trovare un posto di lavoro e sicuramente qua Java la fa da padrone su tutti.
EDIT: Ah, scusa, mi sono dimenticato una cosa ...
a parte il primo: non si possono definire attributi di istanza nella definizione della classe, e d'altra parte non si ha alcuna istanza sottomano per farlo..
io intendo questo
class classe2:
a = [1,2]
def __init__(self):
return
>>> b = classe2()
>>> b.a
[1, 2]
Ciao
cdimauro
09-02-2008, 07:03
Beh, "potenza" è una parola che se usata nella sezione "Console e giochi per console" , magari con un PS3 e Xbox360 inserite nel contesto, può dare luogo ad un conflitto mondiale :D
Non mi tentare... :asd:
In questo contesto speravo fosse un po' meno equivocabile, ma per me va bene continuare ad usare il termine "capacità espressiva" o al max "potere espressivo" :)
OK :)
Beh, gli errori di design possono capitare. Il vantaggio è che con la visibilità puoi comunque permettere ai clienti di accedere agli attributi private (basta creare dei metodi getter e setter), ma nel contempo gli permetti di farlo solo in modo sicuro. Cambia l'implementazione interna dell'attributo? Cambi anche implementazione di getter e setter di conseguenza. L'interfaccia all'oggetto non cambia e il codice rimane compatibile. Con la visibilità permetti all'utilizzatore di vedere solo il comportamento della classe e non quello che ci sta sotto il cofano (che può cambiare quanto vuoi, basta che il comportamento della classe attraverso i metodi sia lo stesso )
Il problema (che m'è capitato, diverse volte) è quando anche coi getter e setter non riesci a modificare delle proprietà perché il designer le ha "nascoste" ed è impossibile riuscire a metterci mano (soltanto giocando veramente molto sporco, ma mi sono sempre rifiutato), per cui ho dovuto desistere (o crearmi un componente ex-novo che lavorasse come volevo). :muro:
Appunto, lasciamoglielo per quando imparerà il python :asd:
No no: Python lo impara da subito, ma questa cosa soltanto dopo aver maturato abbastanza il linguaggio. :)
Mah, non ne sono così convinto...
Comunque per me non è una questione di naturalezza o meno nell'apprendimento. Converrai con me che una volta capito cos'è l'ereditarietà , che è la parte difficile, l'apprendere l'ereditarietà singola o multipla non è difficile. All'inizio è solo una regola : "Non puoi ereditare da più di una classe" . Il significato viene da se dopo ;)
Sì ma stai mettendo sul piatto più cose: il concetto di interfaccia (che è diverso da quello di classe), il fatto che un oggetto possa discendere da una sola classe, e infine quello che può opzionalmente implementare più interfacce.
L'ereditarietà multipla è "naturalmente semplice" da apprendere perché si ferma a una sola regola: una classe può ereditare da una o più classi.
E facendo l'esempietto del gatto che è un felino ed è pure un mammifero, oppure del carro armato che è composto da un carro e da un cannone, se ne esce fuori abbastanza agevolmente (sono due esempi del kaiser, ma a chi è digiuno di programmazione servono cose terra-terra per comprendere velocemente concetti come questo :p).
Beh, sono d'accordo. Si possono fare pasticci con tutto :)
Specialmente in PERL & derivati. :asd:
Beh, stavamo parlando di interfacce e visto che in C++ non esistono come concetto l'unico modo per "emularle" è l'uso di classi astratte con solo metodi virtual puri ;)
Ah, ok, non avevo afferrato l'esempio prima.
Si, ma il fatto che sia possibile già per me significa che non c'è la rigidità tipica che aiuta tanto nell'apprendimento.
Punti di vista: tante volte la rigidità è un limite e un problema per l'apprendimento.
Ad esempio se prendiamo i numeri interi, linguaggi come Java hanno dei tipi base limitati, mentre noi esseri umani siamo abituati a pensare e trattare numeri "virtualmente illimitati".
Con Python quando usi un interi non ti preoccupi di quanto spazio e fino a quale numero puoi rappresentare: li usi e basta. :D
Con Java, dopo esserti sorbito il concetto di dimensione di byte, short, long, poi ti viene detto che se ti serve rappresentare numeri più grandi devi ricorrere a BigInt (o BigInteger, adesso non ricordo): quindi per lavorare con gli interi "a 360°" hai bisogno di conoscere 4 cose.
Python è un linguaggio che mi piace, lo ammetto. Odio di esso solo la sintassi e certe scelte , come ad esempio quella di permettere certi costrutti che se usati impropriamente possono veramente rendere un programma illeggibile
Sono pochi, e comunque cose come le list comprehension sono "naturali" per chi ha un'infarinatura di matematica. :)
e vietare scritture come "+=" , "*=", ... etc usando come scusa che diminuiscono la leggibilità :doh:
Notte :)
Veramente quegli operatori Python li ha. :p Sono stati aggiunti relativamente tardi nel linguaggio, ma ci sono e li puoi usare tranquillamente anche nelle tue classi (con l'overloading degli operatori). ;)
Personalmente tendo a usarli poco perché sono troppo C-like, e IMHO abbassano troppo la leggibilità del codice.
A questo
Count += 1
preferisco decisamente questo:
Count = Count + 1
:)
Non mi tentare... :asd:
In questo contesto speravo fosse un po' meno equivocabile, ma per me va bene continuare ad usare il termine "capacità espressiva" o al max "potere espressivo" :)
OK :)
Beh, gli errori di design possono capitare. Il vantaggio è che con la visibilità puoi comunque permettere ai clienti di accedere agli attributi private (basta creare dei metodi getter e setter), ma nel contempo gli permetti di farlo solo in modo sicuro. Cambia l'implementazione interna dell'attributo? Cambi anche implementazione di getter e setter di conseguenza. L'interfaccia all'oggetto non cambia e il codice rimane compatibile. Con la visibilità permetti all'utilizzatore di vedere solo il comportamento della classe e non quello che ci sta sotto il cofano (che può cambiare quanto vuoi, basta che il comportamento della classe attraverso i metodi sia lo stesso )
Il problema (che m'è capitato, diverse volte) è quando anche coi getter e setter non riesci a modificare delle proprietà perché il designer le ha "nascoste" ed è impossibile riuscire a metterci mano (soltanto giocando veramente molto sporco, ma mi sono sempre rifiutato), per cui ho dovuto desistere (o crearmi un componente ex-novo che lavorasse come volevo). :muro:
Appunto, lasciamoglielo per quando imparerà il python :asd:
No no: Python lo impara da subito, ma questa cosa soltanto dopo aver maturato abbastanza il linguaggio. :)
Mah, non ne sono così convinto...
Comunque per me non è una questione di naturalezza o meno nell'apprendimento. Converrai con me che una volta capito cos'è l'ereditarietà , che è la parte difficile, l'apprendere l'ereditarietà singola o multipla non è difficile. All'inizio è solo una regola : "Non puoi ereditare da più di una classe" . Il significato viene da se dopo ;)
Sì ma stai mettendo sul piatto più cose: il concetto di interfaccia (che è diverso da quello di classe), il fatto che un oggetto possa discendere da una sola classe, e infine quello che può opzionalmente implementare più interfacce.
L'ereditarietà multipla è "naturalmente semplice" da apprendere perché si ferma a una sola regola: una classe può ereditare da una o più classi.
E facendo l'esempietto del gatto che è un felino ed è pure un mammifero, oppure del carro armato che è composto da un carro e da un cannone, se ne esce fuori abbastanza agevolmente (sono due esempi del kaiser, ma a chi è digiuno di programmazione servono cose terra-terra per comprendere velocemente concetti come questo :p).
Beh, sono d'accordo. Si possono fare pasticci con tutto :)
Specialmente in PERL & derivati. :asd:
Beh, stavamo parlando di interfacce e visto che in C++ non esistono come concetto l'unico modo per "emularle" è l'uso di classi astratte con solo metodi virtual puri ;)
Ah, ok, non avevo afferrato l'esempio prima.
Si, ma il fatto che sia possibile già per me significa che non c'è la rigidità tipica che aiuta tanto nell'apprendimento.
Punti di vista: tante volte la rigidità è un limite e un problema per l'apprendimento.
Ad esempio se prendiamo i numeri interi, linguaggi come Java hanno dei tipi base limitati, mentre noi esseri umani siamo abituati a pensare e trattare numeri "virtualmente illimitati".
Con Python quando usi un interi non ti preoccupi di quanto spazio e fino a quale numero puoi rappresentare: li usi e basta. :D
Con Java, dopo esserti sorbito il concetto di dimensione di byte, short, long, poi ti viene detto che se ti serve rappresentare numeri più grandi devi ricorrere a BigInt (o BigInteger, adesso non ricordo): quindi per lavorare con gli interi "a 360°" hai bisogno di conoscere 4 cose.
Python è un linguaggio che mi piace, lo ammetto. Odio di esso solo la sintassi e certe scelte , come ad esempio quella di permettere certi costrutti che se usati impropriamente possono veramente rendere un programma illeggibile
Sono pochi, e comunque cose come le list comprehension sono "naturali" per chi ha un'infarinatura di matematica. :)
e vietare scritture come "+=" , "*=", ... etc usando come scusa che diminuiscono la leggibilità :doh:
Notte :)
Veramente quegli operatori Python li ha. :p Sono stati aggiunti relativamente tardi nel linguaggio, ma ci sono e li puoi usare tranquillamente anche nelle tue classi (con l'overloading degli operatori). ;)
Personalmente tendo a usarli poco perché sono troppo C-like, e IMHO abbassano troppo la leggibilità del codice.
A questo
Count += 1
preferisco decisamente questo:
Count = Count + 1
:)
cdimauro
09-02-2008, 07:12
Tralasciando il fatto che ABBBBBBBBBBBBORRRRRRRO ( con B e R a piacere :asd: ) tutto ciò che in python è scritto con doppio underscore (ed è uno dei motivi che mi fa odiare la sintassi python ), concordo con te che è un comportamento "non critico" se si segue una certa convenzione...
C'è un motivo per cui esiste la convezione dei doppi underscore. Se presenti soltanto davanti è per il name mangling, come ha detto Marco, ma se presenti come prefisso e suffisso è per marcare particolari metodi (costruttori, "inizializzatori", operatori come +, >, ecc.).
Il fatto che abbiano un nome, cioé siano definiti come funzioni/metodi è estremamente comodo perché permette, appunto, di trattarli come tali, e quindi di poterci fare tanti bei giochetti. :D
Certo, a mio parere le costrizioni sono meglio delle convenzioni, anche se in parte ti limitano la libertà (basta che siano a fin di bene), ma è ancora più vero se tutto ciò è a fini didattici. Visto che il thread starter voleva un linguaggio con cui imparare l'OO credo che un po' di "costrizioni buone" possano fargli solo bene.
Da una parte può essere vero, ma dall'altra... ti limitano troppo, come ho detto. :muro:
Non ne dubito, comunque è sempre rimpiazzabile.
Bisogna vedere a quale prezzo. ;)
Non è una questione di complicato o meno nell'imparare un linguaggio. Imparare un linguaggio in genere è piuttosto semplice (per uno che ha già programmato), il problema è acquisire la forma mentis del programmatore OO. Anche se il Java (forse) nella sintassi è un po' più complicato, vuoi perchè deriva dal C, vuoi perchè è un linguaggio più "classico" mentre Python è un linguaggio di scripting dove in genere la semplicità , la velocità di scrittura del codice e la compattezza sono componenti fondamentali ... etc non vuol dire che sia più facile imparare il paradigma OO col Python che col Java. Io ritengo personalmente che sia il contrario, perchè il Java ti guida di più nell'apprendimento.
Per me è l'esatto contrario: proprio perché ci sono meno vincoli, è molto più facile apprendere il paradigma OO.
Il problema che citi è dovuto essenzialmente alla POSSIBILITA' di tirare fuori dei cattivi design, ma questo lo si può fare con qualunque linguaggio, anche se con Python potrebbe essere più facile (per l'ereditarietà multipla e il fatto che tutti gli attribuiti/metodi di una classe sono pubblici).
Inoltre Matrixbob viene dal C. Imparare la sintassi di Java e la tipizzazione forte per lui non dovrebbe proprio essere un problema (anzi, potrebbe di più esserlo l'apprendimento della tipizzazione dinamica del python).
Python è un linguaggio con tipizzazione dinamica, ma forte. Ad esempio non puoi sommare un numero e una stringa, perché viene sollevata un'eccezione. ;)
Inoltre voleva trovare un posto di lavoro e sicuramente qua Java la fa da padrone su tutti.
Indubbiamente, per adesso domina, ma speriamo che Golia cada presto. :D
EDIT: Ah, scusa, mi sono dimenticato una cosa ...
io intendo questo
class classe2:
a = [1,2]
def __init__(self):
return
>>> b = classe2()
>>> b.a
[1, 2]
Ciao
Quello che riporti è un esempio di variabili di classe, che... esistono anche in Java :p (e la sintassi per definirli non è che sia delle migliori. :().
C'è un motivo per cui esiste la convezione dei doppi underscore. Se presenti soltanto davanti è per il name mangling, come ha detto Marco, ma se presenti come prefisso e suffisso è per marcare particolari metodi (costruttori, "inizializzatori", operatori come +, >, ecc.).
Il fatto che abbiano un nome, cioé siano definiti come funzioni/metodi è estremamente comodo perché permette, appunto, di trattarli come tali, e quindi di poterci fare tanti bei giochetti. :D
Certo, a mio parere le costrizioni sono meglio delle convenzioni, anche se in parte ti limitano la libertà (basta che siano a fin di bene), ma è ancora più vero se tutto ciò è a fini didattici. Visto che il thread starter voleva un linguaggio con cui imparare l'OO credo che un po' di "costrizioni buone" possano fargli solo bene.
Da una parte può essere vero, ma dall'altra... ti limitano troppo, come ho detto. :muro:
Non ne dubito, comunque è sempre rimpiazzabile.
Bisogna vedere a quale prezzo. ;)
Non è una questione di complicato o meno nell'imparare un linguaggio. Imparare un linguaggio in genere è piuttosto semplice (per uno che ha già programmato), il problema è acquisire la forma mentis del programmatore OO. Anche se il Java (forse) nella sintassi è un po' più complicato, vuoi perchè deriva dal C, vuoi perchè è un linguaggio più "classico" mentre Python è un linguaggio di scripting dove in genere la semplicità , la velocità di scrittura del codice e la compattezza sono componenti fondamentali ... etc non vuol dire che sia più facile imparare il paradigma OO col Python che col Java. Io ritengo personalmente che sia il contrario, perchè il Java ti guida di più nell'apprendimento.
Per me è l'esatto contrario: proprio perché ci sono meno vincoli, è molto più facile apprendere il paradigma OO.
Il problema che citi è dovuto essenzialmente alla POSSIBILITA' di tirare fuori dei cattivi design, ma questo lo si può fare con qualunque linguaggio, anche se con Python potrebbe essere più facile (per l'ereditarietà multipla e il fatto che tutti gli attribuiti/metodi di una classe sono pubblici).
Inoltre Matrixbob viene dal C. Imparare la sintassi di Java e la tipizzazione forte per lui non dovrebbe proprio essere un problema (anzi, potrebbe di più esserlo l'apprendimento della tipizzazione dinamica del python).
Python è un linguaggio con tipizzazione dinamica, ma forte. Ad esempio non puoi sommare un numero e una stringa, perché viene sollevata un'eccezione. ;)
Inoltre voleva trovare un posto di lavoro e sicuramente qua Java la fa da padrone su tutti.
Indubbiamente, per adesso domina, ma speriamo che Golia cada presto. :D
EDIT: Ah, scusa, mi sono dimenticato una cosa ...
io intendo questo
class classe2:
a = [1,2]
def __init__(self):
return
>>> b = classe2()
>>> b.a
[1, 2]
Ciao
Quello che riporti è un esempio di variabili di classe, che... esistono anche in Java :p (e la sintassi per definirli non è che sia delle migliori. :().
AnonimoVeneziano
09-02-2008, 10:07
Non mi tentare... :asd:
So già che ne uscirò sfiancato :D
Il problema (che m'è capitato, diverse volte) è quando anche coi getter e setter non riesci a modificare delle proprietà perché il designer le ha "nascoste" ed è impossibile riuscire a metterci mano (soltanto giocando veramente molto sporco, ma mi sono sempre rifiutato), per cui ho dovuto desistere (o crearmi un componente ex-novo che lavorasse come volevo). :muro:
Beh, in un modello rigido semplicemente significa che quell'oggetto non faceva al caso tuo. Si hanno due obbiettivi diversi. In un caso si da pieno potere al programmatore (col rischio che però poi succeda un casino :D ) , nel secondo si limita la libertà cercando di forzare un determinato comportamento . E' chiaro che se si lavora tra colleghi (magari anche ad uno stesso progetto dove uno fa una classe e l'altro fa un' altra classe che usa la prima per fare il suo lavoro) allora la visibilità non è strettamente necessaria, ma ad esempio per quanto riguarda la produzione di librerie multi-progetto la mancanza della possibilità di privatizzare alcuni attributi è essa stessa un limite alla libertà del programmatore della libreria di correggere eventuali errori di implementazione senza rompere la compatibilità coi sorgenti preesistenti.
No no: Python lo impara da subito, ma questa cosa soltanto dopo aver maturato abbastanza il linguaggio. :)
:asd:
Sì ma stai mettendo sul piatto più cose: il concetto di interfaccia (che è diverso da quello di classe), il fatto che un oggetto possa discendere da una sola classe, e infine quello che può opzionalmente implementare più interfacce.
L'ereditarietà multipla è "naturalmente semplice" da apprendere perché si ferma a una sola regola: una classe può ereditare da una o più classi.
E facendo l'esempietto del gatto che è un felino ed è pure un mammifero, oppure del carro armato che è composto da un carro e da un cannone, se ne esce fuori abbastanza agevolmente (sono due esempi del kaiser, ma a chi è digiuno di programmazione servono cose terra-terra per comprendere velocemente concetti come questo :p).
Beh, si può fare anche l'esempietto "i felini sono mammiferi, i gatti sono felini, quindi i gatti sono mammiferi" :p . Quello del carro armato mi sa più di composizione che di ereditarietà :p. Comunque io dubito che questo sia una difficoltà all'apprendimento. Non mi sembra niente di difficile, perlomeno quando io ho imparato Java non mi ha lasciato per niente perplesso. All'inizio l'ho presa come una regola sintattica, poi ho capito perchè di questa scelta di design senza troppi problemi.
Punti di vista: tante volte la rigidità è un limite e un problema per l'apprendimento.
Beh, in genere gli studenti si cerca di inquadrarli in uno schema, altrimenti si rischia che non riescano a capire da dove iniziare a concentrare le proprie forze cognitive. Dare troppe libertà all'autodidatta può confondere. Magari non capisce qual'è il modo migliore di fare le cose , visto che si può fare in tanti modi . In Python non è chiaro quale sia la norma e quale sono eventuali espressioni usate poco , ma utili in certi frangenti come "trucchetti" per semplificarsi la vita .
Java è poco ambiguo da questo punto di vista e segna subito la strada da seguire.
Ad esempio se prendiamo i numeri interi, linguaggi come Java hanno dei tipi base limitati, mentre noi esseri umani siamo abituati a pensare e trattare numeri "virtualmente illimitati".
Con Python quando usi un interi non ti preoccupi di quanto spazio e fino a quale numero puoi rappresentare: li usi e basta. :D
Con Java, dopo esserti sorbito il concetto di dimensione di byte, short, long, poi ti viene detto che se ti serve rappresentare numeri più grandi devi ricorrere a BigInt (o BigInteger, adesso non ricordo): quindi per lavorare con gli interi "a 360°" hai bisogno di conoscere 4 cose.
In quanto linguaggio di scripting il python mette a disposizione questi strumenti (anche se non tutti lo fanno :p). Sicuramente non è un problema per un programmatore C vivere con queste limitazioni. I tipi base sono pochi , lavorare con interi grossi è spesso non necessario (per lo meno in fase di apprendimento, ma spesso anche dopo) e in caso lo sia c'è BigInt. Non mi sembra un grande vantaggio all'apprendimento per uno che viene dal C ...
Sono pochi, e comunque cose come le list comprehension sono "naturali" per chi ha un'infarinatura di matematica. :)
Infatti io adoro le list comprehension :D
Veramente quegli operatori Python li ha. :p Sono stati aggiunti relativamente tardi nel linguaggio, ma ci sono e li puoi usare tranquillamente anche nelle tue classi (con l'overloading degli operatori). ;)
Personalmente tendo a usarli poco perché sono troppo C-like, e IMHO abbassano troppo la leggibilità del codice.
A questo
Count += 1
preferisco decisamente questo:
Count = Count + 1
:)
Maddai! E' vero :D Ti giuro che non lo sapevo :p Avevo letto da qualche parte che non si potevano usare (se non sbaglio l'aveva detto anche il mio prof di Info 3) e così non ci ho mai provato :asd: però in effetti non da errore di sintassi e fa quello che deve fare :D
So già che ne uscirò sfiancato :D
Il problema (che m'è capitato, diverse volte) è quando anche coi getter e setter non riesci a modificare delle proprietà perché il designer le ha "nascoste" ed è impossibile riuscire a metterci mano (soltanto giocando veramente molto sporco, ma mi sono sempre rifiutato), per cui ho dovuto desistere (o crearmi un componente ex-novo che lavorasse come volevo). :muro:
Beh, in un modello rigido semplicemente significa che quell'oggetto non faceva al caso tuo. Si hanno due obbiettivi diversi. In un caso si da pieno potere al programmatore (col rischio che però poi succeda un casino :D ) , nel secondo si limita la libertà cercando di forzare un determinato comportamento . E' chiaro che se si lavora tra colleghi (magari anche ad uno stesso progetto dove uno fa una classe e l'altro fa un' altra classe che usa la prima per fare il suo lavoro) allora la visibilità non è strettamente necessaria, ma ad esempio per quanto riguarda la produzione di librerie multi-progetto la mancanza della possibilità di privatizzare alcuni attributi è essa stessa un limite alla libertà del programmatore della libreria di correggere eventuali errori di implementazione senza rompere la compatibilità coi sorgenti preesistenti.
No no: Python lo impara da subito, ma questa cosa soltanto dopo aver maturato abbastanza il linguaggio. :)
:asd:
Sì ma stai mettendo sul piatto più cose: il concetto di interfaccia (che è diverso da quello di classe), il fatto che un oggetto possa discendere da una sola classe, e infine quello che può opzionalmente implementare più interfacce.
L'ereditarietà multipla è "naturalmente semplice" da apprendere perché si ferma a una sola regola: una classe può ereditare da una o più classi.
E facendo l'esempietto del gatto che è un felino ed è pure un mammifero, oppure del carro armato che è composto da un carro e da un cannone, se ne esce fuori abbastanza agevolmente (sono due esempi del kaiser, ma a chi è digiuno di programmazione servono cose terra-terra per comprendere velocemente concetti come questo :p).
Beh, si può fare anche l'esempietto "i felini sono mammiferi, i gatti sono felini, quindi i gatti sono mammiferi" :p . Quello del carro armato mi sa più di composizione che di ereditarietà :p. Comunque io dubito che questo sia una difficoltà all'apprendimento. Non mi sembra niente di difficile, perlomeno quando io ho imparato Java non mi ha lasciato per niente perplesso. All'inizio l'ho presa come una regola sintattica, poi ho capito perchè di questa scelta di design senza troppi problemi.
Punti di vista: tante volte la rigidità è un limite e un problema per l'apprendimento.
Beh, in genere gli studenti si cerca di inquadrarli in uno schema, altrimenti si rischia che non riescano a capire da dove iniziare a concentrare le proprie forze cognitive. Dare troppe libertà all'autodidatta può confondere. Magari non capisce qual'è il modo migliore di fare le cose , visto che si può fare in tanti modi . In Python non è chiaro quale sia la norma e quale sono eventuali espressioni usate poco , ma utili in certi frangenti come "trucchetti" per semplificarsi la vita .
Java è poco ambiguo da questo punto di vista e segna subito la strada da seguire.
Ad esempio se prendiamo i numeri interi, linguaggi come Java hanno dei tipi base limitati, mentre noi esseri umani siamo abituati a pensare e trattare numeri "virtualmente illimitati".
Con Python quando usi un interi non ti preoccupi di quanto spazio e fino a quale numero puoi rappresentare: li usi e basta. :D
Con Java, dopo esserti sorbito il concetto di dimensione di byte, short, long, poi ti viene detto che se ti serve rappresentare numeri più grandi devi ricorrere a BigInt (o BigInteger, adesso non ricordo): quindi per lavorare con gli interi "a 360°" hai bisogno di conoscere 4 cose.
In quanto linguaggio di scripting il python mette a disposizione questi strumenti (anche se non tutti lo fanno :p). Sicuramente non è un problema per un programmatore C vivere con queste limitazioni. I tipi base sono pochi , lavorare con interi grossi è spesso non necessario (per lo meno in fase di apprendimento, ma spesso anche dopo) e in caso lo sia c'è BigInt. Non mi sembra un grande vantaggio all'apprendimento per uno che viene dal C ...
Sono pochi, e comunque cose come le list comprehension sono "naturali" per chi ha un'infarinatura di matematica. :)
Infatti io adoro le list comprehension :D
Veramente quegli operatori Python li ha. :p Sono stati aggiunti relativamente tardi nel linguaggio, ma ci sono e li puoi usare tranquillamente anche nelle tue classi (con l'overloading degli operatori). ;)
Personalmente tendo a usarli poco perché sono troppo C-like, e IMHO abbassano troppo la leggibilità del codice.
A questo
Count += 1
preferisco decisamente questo:
Count = Count + 1
:)
Maddai! E' vero :D Ti giuro che non lo sapevo :p Avevo letto da qualche parte che non si potevano usare (se non sbaglio l'aveva detto anche il mio prof di Info 3) e così non ci ho mai provato :asd: però in effetti non da errore di sintassi e fa quello che deve fare :D
AnonimoVeneziano
09-02-2008, 10:28
C'è un motivo per cui esiste la convezione dei doppi underscore. Se presenti soltanto davanti è per il name mangling, come ha detto Marco, ma se presenti come prefisso e suffisso è per marcare particolari metodi (costruttori, "inizializzatori", operatori come +, >, ecc.).
Il fatto che abbiano un nome, cioé siano definiti come funzioni/metodi è estremamente comodo perché permette, appunto, di trattarli come tali, e quindi di poterci fare tanti bei giochetti. :D
Sti giochetti in python sono ovunque :asd: Comunque è innegabile che a vedersi siano equivalenti ad un cavatappi dritto nella pupilla :D
Da una parte può essere vero, ma dall'altra... ti limitano troppo, come ho detto. :muro:
Beh, è solo perchè non puoi farci i giochetti :asd:
Bisogna vedere a quale prezzo. ;)
Se po' fà , se po fà :asd:
Per me è l'esatto contrario: proprio perché ci sono meno vincoli, è molto più facile apprendere il paradigma OO.
Il problema che citi è dovuto essenzialmente alla POSSIBILITA' di tirare fuori dei cattivi design, ma questo lo si può fare con qualunque linguaggio, anche se con Python potrebbe essere più facile (per l'ereditarietà multipla e il fatto che tutti gli attribuiti/metodi di una classe sono pubblici).
Appunto perchè è più facile tirare fuori design cattivi più facilmente in Python che consiglio Java ;) . Un principiante che impara l'OO da zero dovrebbe cercare prima di tutto di concentrarsi su come progettare un buon design, non sulla semplicità del linguaggio. Lui è già programmatore e non ha problemi in questo senso.
Con Java viene inculcata una forma mentis più "corretta" a mio parere. Il python essendo meno rigido forse è più facile da comprendere al primo contatto (perchè le costrizioni per il cervello sono sempre innaturali ) , ma poi tutto questo "potere" nelle mani del novizio può confonderlo. La potenza è nulla senza controllo :asd:
Python è un linguaggio con tipizzazione dinamica, ma forte. Ad esempio non puoi sommare un numero e una stringa, perché viene sollevata un'eccezione. ;)
Beh, è proprio il concetto di dinamicità della tipizzazione la cosa difficile da capire per un programmatore C. Dopotutto in C la tipizzazione è statica, ma debole :D
Indubbiamente, per adesso domina, ma speriamo che Golia cada presto. :D
La tua speranza è legittima , per quanto mi riguarda preferisco Java anche se non disdegno python :D
Quello che riporti è un esempio di variabili di classe, che... esistono anche in Java :p (e la sintassi per definirli non è che sia delle migliori. :().
Si, infatti era proprio quello che intendevo :)
Il fatto che abbiano un nome, cioé siano definiti come funzioni/metodi è estremamente comodo perché permette, appunto, di trattarli come tali, e quindi di poterci fare tanti bei giochetti. :D
Sti giochetti in python sono ovunque :asd: Comunque è innegabile che a vedersi siano equivalenti ad un cavatappi dritto nella pupilla :D
Da una parte può essere vero, ma dall'altra... ti limitano troppo, come ho detto. :muro:
Beh, è solo perchè non puoi farci i giochetti :asd:
Bisogna vedere a quale prezzo. ;)
Se po' fà , se po fà :asd:
Per me è l'esatto contrario: proprio perché ci sono meno vincoli, è molto più facile apprendere il paradigma OO.
Il problema che citi è dovuto essenzialmente alla POSSIBILITA' di tirare fuori dei cattivi design, ma questo lo si può fare con qualunque linguaggio, anche se con Python potrebbe essere più facile (per l'ereditarietà multipla e il fatto che tutti gli attribuiti/metodi di una classe sono pubblici).
Appunto perchè è più facile tirare fuori design cattivi più facilmente in Python che consiglio Java ;) . Un principiante che impara l'OO da zero dovrebbe cercare prima di tutto di concentrarsi su come progettare un buon design, non sulla semplicità del linguaggio. Lui è già programmatore e non ha problemi in questo senso.
Con Java viene inculcata una forma mentis più "corretta" a mio parere. Il python essendo meno rigido forse è più facile da comprendere al primo contatto (perchè le costrizioni per il cervello sono sempre innaturali ) , ma poi tutto questo "potere" nelle mani del novizio può confonderlo. La potenza è nulla senza controllo :asd:
Python è un linguaggio con tipizzazione dinamica, ma forte. Ad esempio non puoi sommare un numero e una stringa, perché viene sollevata un'eccezione. ;)
Beh, è proprio il concetto di dinamicità della tipizzazione la cosa difficile da capire per un programmatore C. Dopotutto in C la tipizzazione è statica, ma debole :D
Indubbiamente, per adesso domina, ma speriamo che Golia cada presto. :D
La tua speranza è legittima , per quanto mi riguarda preferisco Java anche se non disdegno python :D
Quello che riporti è un esempio di variabili di classe, che... esistono anche in Java :p (e la sintassi per definirli non è che sia delle migliori. :().
Si, infatti era proprio quello che intendevo :)
k0nt3
09-02-2008, 10:30
ma ragazzi.. c'è poco da discutere :D se uno mi chiede: "quale linguaggio per entrare nella mentalità OO?"
l'ultimo che mi viene in mente è python
ma ormai è il prezzemolo della situazione -_-
l'ultimo che mi viene in mente è python
ma ormai è il prezzemolo della situazione -_-
marco.r
09-02-2008, 10:40
Ma porc... non c'e' il mio post di stanotte... :confused: :muro: :fagiano:
Rispondo solo a questo per ora...
EDIT: Ah, scusa, mi sono dimenticato una cosa ...
io intendo questo
class classe2:
a = [1,2]
def __init__(self):
return
>>> b = classe2()
>>> b.a
[1, 2]
Ciao
E' una variabile di classe.
>>> c = classe2()
>>> b.a.append(3)
>>> c.a
[1,2,3]
>>> classe2.a
[1,2,3]
Rispondo solo a questo per ora...
EDIT: Ah, scusa, mi sono dimenticato una cosa ...
io intendo questo
class classe2:
a = [1,2]
def __init__(self):
return
>>> b = classe2()
>>> b.a
[1, 2]
Ciao
E' una variabile di classe.
>>> c = classe2()
>>> b.a.append(3)
>>> c.a
[1,2,3]
>>> classe2.a
[1,2,3]
AnonimoVeneziano
09-02-2008, 10:49
Ma porc... non c'e' il mio post di stanotte... :confused: :muro: :fagiano:
Rispondo solo a questo per ora...
Così impari a scrivere i messaggi durante i backup notturni del server :p (l'ho imparato anch'io a mie spese tempo fa :muro:)
E' una variabile di classe.
>>> c = classe2()
>>> b.a.append(3)
>>> c.a
[1,2,3]
>>> classe2.a
[1,2,3]
E' esattamente quello che intendevo. Il senso del discorso era che in python puoi aggiungere attributi alle classe in qualsiasi momento. A partire dalla definizione della stessa , passando per il costruttore, ai metodi della classe stessa e persino fuori a runtime, basta che si abbia un reference alla classe stessa.
Ciao
Rispondo solo a questo per ora...
Così impari a scrivere i messaggi durante i backup notturni del server :p (l'ho imparato anch'io a mie spese tempo fa :muro:)
E' una variabile di classe.
>>> c = classe2()
>>> b.a.append(3)
>>> c.a
[1,2,3]
>>> classe2.a
[1,2,3]
E' esattamente quello che intendevo. Il senso del discorso era che in python puoi aggiungere attributi alle classe in qualsiasi momento. A partire dalla definizione della stessa , passando per il costruttore, ai metodi della classe stessa e persino fuori a runtime, basta che si abbia un reference alla classe stessa.
Ciao
^TiGeRShArK^
09-02-2008, 10:57
Tralasciando il fatto che ABBBBBBBBBBBBORRRRRRRO ( con B e R a piacere :asd: ) tutto ciò che in python è scritto con doppio underscore (ed è uno dei motivi che mi fa odiare la sintassi python ),
pure io :asd:
pure io :asd:
Matrixbob
09-02-2008, 12:00
Vedete, basta vedere su Monster cosa richiedono, J2EE non JEE.
Di questi annunci ne escono più a settimana!
http://img206.imageshack.us/img206/7613/immaginesq9.jpg
Di questi annunci ne escono più a settimana!
http://img206.imageshack.us/img206/7613/immaginesq9.jpg
^TiGeRShArK^
09-02-2008, 12:03
Vedete, basta vedere su Monster cosa richiedono, J2EE non JEEE.
Di questi annunci ne escono più a settimana!
http://img206.imageshack.us/img206/7613/immaginesq9.jpg
molto probabilmente ancora non sanno la differenza tra JEE e J2EE...
o addirittura ignorano che sia uscita la versione nuova di Java Enterprise Edition :asd:
..o + semplicemetne ancora sviluppano con J2EE e con il bagno di sangue derivato dagli xml che ne consegue :asd:
Di questi annunci ne escono più a settimana!
http://img206.imageshack.us/img206/7613/immaginesq9.jpg
molto probabilmente ancora non sanno la differenza tra JEE e J2EE...
o addirittura ignorano che sia uscita la versione nuova di Java Enterprise Edition :asd:
..o + semplicemetne ancora sviluppano con J2EE e con il bagno di sangue derivato dagli xml che ne consegue :asd:
Matrixbob
09-02-2008, 12:06
molto probabilmente ancora non sanno la differenza tra JEE e J2EE...
o addirittura ignorano che sia uscita la versione nuova di Java Enterprise Edition :asd:
..o + semplicemetne ancora sviluppano con J2EE e con il bagno di sangue derivato dagli xml che ne consegue :asd:
A parte che nemmeno io ne so le differeze, qualcuno può riassumere?
o addirittura ignorano che sia uscita la versione nuova di Java Enterprise Edition :asd:
..o + semplicemetne ancora sviluppano con J2EE e con il bagno di sangue derivato dagli xml che ne consegue :asd:
A parte che nemmeno io ne so le differeze, qualcuno può riassumere?
^TiGeRShArK^
09-02-2008, 12:09
A parte che nemmeno io ne so le differeze, qualcuno può riassumere?
beh..
Per me la + sostanziale è quella introdotta dagli EJB 3 (praticamente l'equivalente di Hibernate 3) con tutto quello che ne consegue.
Diciamo che quella + immediata è che mi ha lasciato + felice è stato l'abbandono di quei maledetti file di xml di configurazione in favore delle annotations.
E tieni conto che in progetti piuttosto complessi a volte arrivavi ad avere una quantità di xml di configurazione che era paragonabile alla quantità di codice vero e proprio :fagiano:
beh..
Per me la + sostanziale è quella introdotta dagli EJB 3 (praticamente l'equivalente di Hibernate 3) con tutto quello che ne consegue.
Diciamo che quella + immediata è che mi ha lasciato + felice è stato l'abbandono di quei maledetti file di xml di configurazione in favore delle annotations.
E tieni conto che in progetti piuttosto complessi a volte arrivavi ad avere una quantità di xml di configurazione che era paragonabile alla quantità di codice vero e proprio :fagiano:
fek
09-02-2008, 12:10
pure io :asd:
Anch'io. L'underscore in un linguaggio e' da veri niubbi :(
Anch'io. L'underscore in un linguaggio e' da veri niubbi :(
Matrixbob
09-02-2008, 12:15
Diciamo che quella + immediata è che mi ha lasciato + felice è stato l'abbandono di quei maledetti file di xml di configurazione in favore delle annotations.
E tieni conto che in progetti piuttosto complessi a volte arrivavi ad avere una quantità di xml di configurazione che era paragonabile alla quantità di codice vero e proprio :fagiano:
:eek:
Ah cacchio me li ricordo, quando anche per far girare le servlet su tomcat dovevo configurare quel web-ap.xml o un file del genere.
Che palle!
E tieni conto che in progetti piuttosto complessi a volte arrivavi ad avere una quantità di xml di configurazione che era paragonabile alla quantità di codice vero e proprio :fagiano:
:eek:
Ah cacchio me li ricordo, quando anche per far girare le servlet su tomcat dovevo configurare quel web-ap.xml o un file del genere.
Che palle!
marco.r
09-02-2008, 12:38
Anch'io. L'underscore in un linguaggio e' da veri niubbi :(
Definirlo da niubbi mi sembra una sparata ingiustificata. Puo' piacere o meno, ma non lo vedo tanto peggiore del caps fest.
Il separatore piu' carino resta il - del lisp, peccato porti delle implicazioni radicali sulla sintassi usabile :p
Definirlo da niubbi mi sembra una sparata ingiustificata. Puo' piacere o meno, ma non lo vedo tanto peggiore del caps fest.
Il separatore piu' carino resta il - del lisp, peccato porti delle implicazioni radicali sulla sintassi usabile :p
cionci
09-02-2008, 12:41
ma ragazzi.. c'è poco da discutere :D se uno mi chiede: "quale linguaggio per entrare nella mentalità OO?"
l'ultimo che mi viene in mente è python
ma ormai è il prezzemolo della situazione -_-
Concordo :mano:
Ed il primo è Java imho.
l'ultimo che mi viene in mente è python
ma ormai è il prezzemolo della situazione -_-
Concordo :mano:
Ed il primo è Java imho.
marco.r
09-02-2008, 13:05
Così impari a scrivere i messaggi durante i backup notturni del server :p (l'ho imparato anch'io a mie spese tempo fa :muro:)
Si', ma qualcuno avvisi i piani alti che dopo il backup non ci va sempre il restore... :D
E' esattamente quello che intendevo. Il senso del discorso era che in python puoi aggiungere attributi alle classe in qualsiasi momento. A partire dalla definizione della stessa , passando per il costruttore, ai metodi della classe stessa e persino fuori a runtime, basta che si abbia un reference alla classe stessa.
Ciao
Ok, ma continuo a non vederci il problema. Tu la vedi come tanti casi particolari, io come un'unica regola semplice da ricordare: quando hai sottomano un oggetto puoi modificarne gli attributi a piacere.
Per inciso questo comportamento spiega la presenza di quel self. che fek tanto odia. Se cosi' non fosse, potendo aggiungere o togliere attributi a piacere, quando definisco un metodo non avrei modo di sapere se una variabile che definisco fa riferimento a un attributo o a una variabile nello scope della definizione.
Supponi per un attimo che non sia necessario (questa e' piu' una risposta a fek che a te:p):
a = 2
class Foo:
def boo(self):
print a
x = Foo()
x.boo()
# viene stampato 2
x.a = 3
x.boo()
# che deve stampare ? 2 o 3 ?
La presenza del self risolve in modo molto chiaro questa ambiguita.
(nota per fek. Se self ti sta antipatico puoi sempre usare un nome diverso come x :D :p )
Si', ma qualcuno avvisi i piani alti che dopo il backup non ci va sempre il restore... :D
E' esattamente quello che intendevo. Il senso del discorso era che in python puoi aggiungere attributi alle classe in qualsiasi momento. A partire dalla definizione della stessa , passando per il costruttore, ai metodi della classe stessa e persino fuori a runtime, basta che si abbia un reference alla classe stessa.
Ciao
Ok, ma continuo a non vederci il problema. Tu la vedi come tanti casi particolari, io come un'unica regola semplice da ricordare: quando hai sottomano un oggetto puoi modificarne gli attributi a piacere.
Per inciso questo comportamento spiega la presenza di quel self. che fek tanto odia. Se cosi' non fosse, potendo aggiungere o togliere attributi a piacere, quando definisco un metodo non avrei modo di sapere se una variabile che definisco fa riferimento a un attributo o a una variabile nello scope della definizione.
Supponi per un attimo che non sia necessario (questa e' piu' una risposta a fek che a te:p):
a = 2
class Foo:
def boo(self):
print a
x = Foo()
x.boo()
# viene stampato 2
x.a = 3
x.boo()
# che deve stampare ? 2 o 3 ?
La presenza del self risolve in modo molto chiaro questa ambiguita.
(nota per fek. Se self ti sta antipatico puoi sempre usare un nome diverso come x :D :p )
AnonimoVeneziano
09-02-2008, 13:25
Ok, ma continuo a non vederci il problema. Tu la vedi come tanti casi particolari, io come un'unica regola semplice da ricordare: quando hai sottomano un oggetto puoi modificarne gli attributi a piacere.
Per inciso questo comportamento spiega la presenza di quel self. che fek tanto odia. Se cosi' non fosse, potendo aggiungere o togliere attributi a piacere, quando definisco un metodo non avrei modo di sapere se una variabile che definisco fa riferimento a un attributo o a una variabile nello scope della definizione.
Supponi per un attimo che non sia necessario (questa e' piu' una risposta a fek che a te:p):
a = 2
class Foo:
def boo(self):
print a
x = Foo()
x.boo()
# viene stampato 2
x.a = 3
x.boo()
# che deve stampare ? 2 o 3 ?
La presenza del self risolve in modo molto chiaro questa ambiguita.
(nota per fek. Se self ti sta antipatico puoi sempre usare un nome diverso come x :D :p )
Ma diamine, io non sto dicendo che è male in generale :p
Questo comportamento può essere utile, soprattutto per fare i vari giochetti che hai programmatori Python hardcore piacciono tanto :D . Solo che uno che si avvicina per la prima volta alla programmazione ad oggetti si può chiedere "Ok, gli attributi posso definirli così, così , così , così , così.... etc . Ma come caXXo è supposto che li debba definire di norma? :D"
Di norma per me si devono definire nella definizione della classe, perchè gli attributi (e i metodi) sono i componenti che definiscono il comportamento stesso della classe (e per cosa è stata fatta). Questa dinamicità nell'aggiunta delle componenti alle classi la vedo come una scorciatoia utile ad esempio nei casi che ha già citato Cesare (ad esempio aggiungere un metodo read() per far comportare la classe come uno stream al volo) per non subclassare. E' una caratteristica tipica dei linguaggi di scripting. Aggiungono un sacco di funzionalità simili a queste per velocizzare al massimo la scrittura del codice che è lo scopo stesso del linguaggio a volte trascurando però la formalizzazione dei concetti .
Queste scorciatoie a livello didattico per me sono controproducenti.
Ciao
Per inciso questo comportamento spiega la presenza di quel self. che fek tanto odia. Se cosi' non fosse, potendo aggiungere o togliere attributi a piacere, quando definisco un metodo non avrei modo di sapere se una variabile che definisco fa riferimento a un attributo o a una variabile nello scope della definizione.
Supponi per un attimo che non sia necessario (questa e' piu' una risposta a fek che a te:p):
a = 2
class Foo:
def boo(self):
print a
x = Foo()
x.boo()
# viene stampato 2
x.a = 3
x.boo()
# che deve stampare ? 2 o 3 ?
La presenza del self risolve in modo molto chiaro questa ambiguita.
(nota per fek. Se self ti sta antipatico puoi sempre usare un nome diverso come x :D :p )
Ma diamine, io non sto dicendo che è male in generale :p
Questo comportamento può essere utile, soprattutto per fare i vari giochetti che hai programmatori Python hardcore piacciono tanto :D . Solo che uno che si avvicina per la prima volta alla programmazione ad oggetti si può chiedere "Ok, gli attributi posso definirli così, così , così , così , così.... etc . Ma come caXXo è supposto che li debba definire di norma? :D"
Di norma per me si devono definire nella definizione della classe, perchè gli attributi (e i metodi) sono i componenti che definiscono il comportamento stesso della classe (e per cosa è stata fatta). Questa dinamicità nell'aggiunta delle componenti alle classi la vedo come una scorciatoia utile ad esempio nei casi che ha già citato Cesare (ad esempio aggiungere un metodo read() per far comportare la classe come uno stream al volo) per non subclassare. E' una caratteristica tipica dei linguaggi di scripting. Aggiungono un sacco di funzionalità simili a queste per velocizzare al massimo la scrittura del codice che è lo scopo stesso del linguaggio a volte trascurando però la formalizzazione dei concetti .
Queste scorciatoie a livello didattico per me sono controproducenti.
Ciao
cionci
09-02-2008, 13:31
Queste scorciatoie a livello didattico per me sono controproducenti.
Senza dubbio...imho Java è un linguaggio molto lineare ed adatto all'apprendimento della OOP. Senza comportamenti astrusi o fuori da ogni logica, anche se magari utili.
Senza dubbio...imho Java è un linguaggio molto lineare ed adatto all'apprendimento della OOP. Senza comportamenti astrusi o fuori da ogni logica, anche se magari utili.
k0nt3
09-02-2008, 13:33
Senza dubbio...imho Java è un linguaggio molto lineare ed adatto all'apprendimento della OOP. Senza comportamenti astrusi o fuori da ogni logica, anche se magari utili.
aspetta a parlare che adesso qualcuno tira fuori i generics ;) quanto sono prevedibili queste discussioni :p
aspetta a parlare che adesso qualcuno tira fuori i generics ;) quanto sono prevedibili queste discussioni :p
marco.r
09-02-2008, 13:36
Appunto perchè è più facile tirare fuori design cattivi più facilmente in Python che consiglio Java ;) .
Cosa tutta da dimostrare. Un principiante non usera' attributi privati perche' glieli offre Java. Semplicemente mettera' gli attributi come pubblici e vi accedera' direttamente.
Non attuera' una corretta gestione delle eccezioni perche' Java ti obbliga a raccogliere le eccezioni che non dichiari. Mettera' un bel catch globale nel main.
Tutte cose che ho visto fare regolarmente.
Cosa tutta da dimostrare. Un principiante non usera' attributi privati perche' glieli offre Java. Semplicemente mettera' gli attributi come pubblici e vi accedera' direttamente.
Non attuera' una corretta gestione delle eccezioni perche' Java ti obbliga a raccogliere le eccezioni che non dichiari. Mettera' un bel catch globale nel main.
Tutte cose che ho visto fare regolarmente.
cionci
09-02-2008, 13:37
aspetta a parlare che adesso qualcuno tira fuori i generics ;) quanto sono prevedibili queste discussioni :p
Già :D Però i generics sono un comportamento avanzato del linguaggio e sono effettivamente confusionari solo se utilizzati in modo avanzato, conoscere i vari modi per definire i metodi di una classe è la base di un linguaggio.
Già :D Però i generics sono un comportamento avanzato del linguaggio e sono effettivamente confusionari solo se utilizzati in modo avanzato, conoscere i vari modi per definire i metodi di una classe è la base di un linguaggio.
cionci
09-02-2008, 13:40
Tutte cose che ho visto fare regolarmente.
Tutte cose che puoi far male anche negli altri linguaggi.
Però ad esempio in Java non potrai mai mescolare programmazione procedurale e ad oggetti (nonostante che molti ci provino con i metodi statici nella classe principale).
Tutte cose che puoi far male anche negli altri linguaggi.
Però ad esempio in Java non potrai mai mescolare programmazione procedurale e ad oggetti (nonostante che molti ci provino con i metodi statici nella classe principale).
k0nt3
09-02-2008, 13:40
Cosa tutta da dimostrare. Un principiante non usera' attributi privati perche' glieli offre Java. Semplicemente mettera' gli attributi come pubblici e vi accedera' direttamente.
Non attuera' una corretta gestione delle eccezioni perche' Java ti obbliga a raccogliere le eccezioni che non dichiari. Mettera' un bel catch globale nel main.
Tutte cose che ho visto fare regolarmente.
si suppone che uno che programma in java sappia programmare a oggetti o eventualmente stia imparando, perciò non ha senso questo discorso.
tra tutti i linguaggi OO java è quello che permette meno porcherie, per questo lo consiglio come linguaggio per imparare la mentalità OO. è ovvio che uno non si deve limitare a imparare il linguaggio, ma deve anche imparare la programmazione OO nei suoi aspetti più generali. java è soltanto lo strumento
Non attuera' una corretta gestione delle eccezioni perche' Java ti obbliga a raccogliere le eccezioni che non dichiari. Mettera' un bel catch globale nel main.
Tutte cose che ho visto fare regolarmente.
si suppone che uno che programma in java sappia programmare a oggetti o eventualmente stia imparando, perciò non ha senso questo discorso.
tra tutti i linguaggi OO java è quello che permette meno porcherie, per questo lo consiglio come linguaggio per imparare la mentalità OO. è ovvio che uno non si deve limitare a imparare il linguaggio, ma deve anche imparare la programmazione OO nei suoi aspetti più generali. java è soltanto lo strumento
marco.r
09-02-2008, 14:16
Questo comportamento può essere utile, soprattutto per fare i vari giochetti che hai programmatori Python hardcore piacciono tanto :D.
Non sono giochetti, sono strumenti che un programmatore serio dovrebbe imparare
Solo che uno che si avvicina per la prima volta alla programmazione ad oggetti si può chiedere "Ok, gli attributi posso definirli così, così , così , così , così.... etc . Ma come caXXo è supposto che li debba definire di norma? :D"
x.a = y
dove x e' una istanza, a il nome di un attributo e y il valore che gli vuoi assegnare.
Ad un principiante e' l'unico modo che occorre spiegare, piu' due eccezioni, le variabili globali e le variabili di classe.
In questo modo copri tutti i "cosi', cosi'", di cui parli sopra. Non mi sembra un concetto difficile.
Appurato che per le istanze il come e' uno unico, al piu' resta da spiegare il quando, e la risposta e' "quando serve".
Di norma per me si devono definire nella definizione della classe, perchè gli attributi (e i metodi) sono i componenti che definiscono il comportamento stesso della classe (e per cosa è stata fatta).
Questa dinamicità nell'aggiunta delle componenti alle classi la vedo come una scorciatoia utile ad esempio nei casi che ha già citato Cesare (ad esempio aggiungere un metodo read() per far comportare la classe come uno stream al volo) per non subclassare.
Ripeto, non e' una scorciatoia (non piu' di quanto il GC sia una scorciatoia per non gestire manualmente la memoria) e tra l'altro non sempre basta subclassare.
Se ad esempio ti arriva una classe via rete gia' istanziata da remoto, la devi wrappare con un altro oggetto che implementi l'interfaccia richiesta. A te sembra piu' pulito che non semplicemente aggiungere il metodo mancante, a me no.
Tra l'altro c'e' una differenza sostanziale (se definisco il metodo poi posso riutilizzare direttamente l'istanza in altri casi, se uso un wrapper devo wrapparlo ogni volta).
Aggiungono un sacco di funzionalità simili a queste per velocizzare al massimo la scrittura del codice che è lo scopo stesso del linguaggio a volte trascurando però la formalizzazione dei concetti .
Queste scorciatoie a livello didattico per me sono controproducenti.
A questo punto chiariamo precisamente qual sono i concetti da formalizzare, perche' mi sembra che si tenda a farli coincidere con le caratteristiche di un dato linguaggio.
Il fatto che in Java si programmi meglio comportandosi in un certo modo non vuol dire che sia il modo corretto di fare programmazione ad oggetti.
Tra Java e un linguaggio dinamico tipo Python o Ruby, e' proprio il punto di vista che cambia. Tornando all'esempio di sopra, quello di Java e' "Mi e' arrivato un oggetto x di tipo X, me ne serve uno che implementi l'interfaccia Y, per cui scrivo un wrapper per x che implementi l'interfaccia corretta". Nel caso di un linguaggio dinamico e' "Mi e' arrivato un oggetto x che non ha i metodi che mi servono. Definisco su questa istanza i metodi che mi servono".
Il primo e' orientato ai tipi e alle classi. Il secondo agli oggetti e ai messaggi che questi si scambiano.
Dire che il primo modo e' piu' corretto di fare programmazione OO implica secondo me una concezione limitata della stessa (e dei linguaggi di programmazione in generale).
Non sono giochetti, sono strumenti che un programmatore serio dovrebbe imparare
Solo che uno che si avvicina per la prima volta alla programmazione ad oggetti si può chiedere "Ok, gli attributi posso definirli così, così , così , così , così.... etc . Ma come caXXo è supposto che li debba definire di norma? :D"
x.a = y
dove x e' una istanza, a il nome di un attributo e y il valore che gli vuoi assegnare.
Ad un principiante e' l'unico modo che occorre spiegare, piu' due eccezioni, le variabili globali e le variabili di classe.
In questo modo copri tutti i "cosi', cosi'", di cui parli sopra. Non mi sembra un concetto difficile.
Appurato che per le istanze il come e' uno unico, al piu' resta da spiegare il quando, e la risposta e' "quando serve".
Di norma per me si devono definire nella definizione della classe, perchè gli attributi (e i metodi) sono i componenti che definiscono il comportamento stesso della classe (e per cosa è stata fatta).
Questa dinamicità nell'aggiunta delle componenti alle classi la vedo come una scorciatoia utile ad esempio nei casi che ha già citato Cesare (ad esempio aggiungere un metodo read() per far comportare la classe come uno stream al volo) per non subclassare.
Ripeto, non e' una scorciatoia (non piu' di quanto il GC sia una scorciatoia per non gestire manualmente la memoria) e tra l'altro non sempre basta subclassare.
Se ad esempio ti arriva una classe via rete gia' istanziata da remoto, la devi wrappare con un altro oggetto che implementi l'interfaccia richiesta. A te sembra piu' pulito che non semplicemente aggiungere il metodo mancante, a me no.
Tra l'altro c'e' una differenza sostanziale (se definisco il metodo poi posso riutilizzare direttamente l'istanza in altri casi, se uso un wrapper devo wrapparlo ogni volta).
Aggiungono un sacco di funzionalità simili a queste per velocizzare al massimo la scrittura del codice che è lo scopo stesso del linguaggio a volte trascurando però la formalizzazione dei concetti .
Queste scorciatoie a livello didattico per me sono controproducenti.
A questo punto chiariamo precisamente qual sono i concetti da formalizzare, perche' mi sembra che si tenda a farli coincidere con le caratteristiche di un dato linguaggio.
Il fatto che in Java si programmi meglio comportandosi in un certo modo non vuol dire che sia il modo corretto di fare programmazione ad oggetti.
Tra Java e un linguaggio dinamico tipo Python o Ruby, e' proprio il punto di vista che cambia. Tornando all'esempio di sopra, quello di Java e' "Mi e' arrivato un oggetto x di tipo X, me ne serve uno che implementi l'interfaccia Y, per cui scrivo un wrapper per x che implementi l'interfaccia corretta". Nel caso di un linguaggio dinamico e' "Mi e' arrivato un oggetto x che non ha i metodi che mi servono. Definisco su questa istanza i metodi che mi servono".
Il primo e' orientato ai tipi e alle classi. Il secondo agli oggetti e ai messaggi che questi si scambiano.
Dire che il primo modo e' piu' corretto di fare programmazione OO implica secondo me una concezione limitata della stessa (e dei linguaggi di programmazione in generale).
fek
09-02-2008, 14:20
Dire che il primo modo e' piu' corretto di fare programmazione OO implica secondo me una concezione limitata della stessa (e dei linguaggi di programmazione in generale).
Io non adoro i linguaggi dinamici, ma questo e' assolutamente vero: per altro e' lo schema di funzionamento di Smalltalk, col quale e' nata l'OOP.
Io non adoro i linguaggi dinamici, ma questo e' assolutamente vero: per altro e' lo schema di funzionamento di Smalltalk, col quale e' nata l'OOP.
cionci
09-02-2008, 14:22
Dire che il primo modo e' piu' corretto di fare programmazione OO implica secondo me una concezione limitata della stessa (e dei linguaggi di programmazione in generale).
Però imho è possibile dire che c'è più rigidità nell'impostazione di Java e la rigidità implica formalismi di più facile comprensione sia per chi devi imparare che per chi deve leggere il codice.
Però imho è possibile dire che c'è più rigidità nell'impostazione di Java e la rigidità implica formalismi di più facile comprensione sia per chi devi imparare che per chi deve leggere il codice.
marco.r
09-02-2008, 14:24
Tutte cose che puoi far male anche negli altri linguaggi.
Però ad esempio in Java non potrai mai mescolare programmazione procedurale e ad oggetti (nonostante che molti ci provino con i metodi statici nella classe principale).
Infatti, tutte cose che puoi fare male in qualsiasi linguaggio. Java compreso. Certe caratteristiche del linguaggio possono aiutare contro gli errori e i bug, ma riescono a guidare il principiante verso la corretta programmazione solo se andarci contro e' piu' difficile che non assecondarle. Nei due esempi che ho riportato e' molto piu' semplice mettere attributi pubblici o raccogliere le eccezioni a caso purche' il codice compili.
Però ad esempio in Java non potrai mai mescolare programmazione procedurale e ad oggetti (nonostante che molti ci provino con i metodi statici nella classe principale).
Infatti, tutte cose che puoi fare male in qualsiasi linguaggio. Java compreso. Certe caratteristiche del linguaggio possono aiutare contro gli errori e i bug, ma riescono a guidare il principiante verso la corretta programmazione solo se andarci contro e' piu' difficile che non assecondarle. Nei due esempi che ho riportato e' molto piu' semplice mettere attributi pubblici o raccogliere le eccezioni a caso purche' il codice compili.
fek
09-02-2008, 14:28
Però imho è possibile dire che c'è più rigidità nell'impostazione di Java e la rigidità implica formalismi di più facile comprensione sia per chi devi imparare che per chi deve leggere il codice.
Sono d'accordo con te, ma e' anche vero che un linguaggio dinamico e' piu' "naturale" da imparare per un principiante. Io e te capiamo il motivo per il quale si deve dichiarare un campo in una classe o una variabile prima di usarli, ma per chi vede un programma per la prima volta no. E' piu' semplice pensare "mi serve questa variabile, la uso". Poi siamo d'accordo che sia piu' facile sbagliare cosi', infatti io non adoro, di nuovo, i linguaggi dinamici.
Secondo me e' sbagliato rivendicare la supremazia di un approccio sull'altro, perche' va molto a gusti e molto a necessita' pratiche e tipo di problema da risolvere, nonche' gli strumenti a disposizione per risolverlo...
Detto questo, Python e' utterly crap, chi lo ha inventato dovrebbe morire fra atroci sofferenze, in python non esistono le stringhe, siete tutti niubbi e bastardi. (Chi indiovina chi sto parafrasando vince due righe di codice autografate :asd:)
Sono d'accordo con te, ma e' anche vero che un linguaggio dinamico e' piu' "naturale" da imparare per un principiante. Io e te capiamo il motivo per il quale si deve dichiarare un campo in una classe o una variabile prima di usarli, ma per chi vede un programma per la prima volta no. E' piu' semplice pensare "mi serve questa variabile, la uso". Poi siamo d'accordo che sia piu' facile sbagliare cosi', infatti io non adoro, di nuovo, i linguaggi dinamici.
Secondo me e' sbagliato rivendicare la supremazia di un approccio sull'altro, perche' va molto a gusti e molto a necessita' pratiche e tipo di problema da risolvere, nonche' gli strumenti a disposizione per risolverlo...
Detto questo, Python e' utterly crap, chi lo ha inventato dovrebbe morire fra atroci sofferenze, in python non esistono le stringhe, siete tutti niubbi e bastardi. (Chi indiovina chi sto parafrasando vince due righe di codice autografate :asd:)
cionci
09-02-2008, 14:30
Io non adoro i linguaggi dinamici, ma questo e' assolutamente vero: per altro e' lo schema di funzionamento di Smalltalk, col quale e' nata l'OOP.
Non a caso SmallTalk non è fra i linguaggi più semplici...anzi...
Detto questo, Python e' utterly crap, chi lo ha inventato dovrebbe morire fra atroci sofferenze,
:asd:
Non a caso SmallTalk non è fra i linguaggi più semplici...anzi...
Detto questo, Python e' utterly crap, chi lo ha inventato dovrebbe morire fra atroci sofferenze,
:asd:
marco.r
09-02-2008, 14:42
Io non adoro i linguaggi dinamici, ma questo e' assolutamente vero: per altro e' lo schema di funzionamento di Smalltalk, col quale e' nata l'OOP.
Per inciso... non sto dicendo il contrario, cioe' che siano piu' orientati agli oggetti linguaggi come Python, Ruby e compagnia. Solo che quando vedo parlare di Java come se fosse il linguaggio per la OOP parto in quarta alla cdimauro :D, piu' che altro ha per me delle carenze che non mi vanno giu'. L'ideale sarebbe provare entrambe le alternative e poi decidere... se Matrixbob promette che non si fermera' li', anche partire con Java va bene :p.
Per inciso... non sto dicendo il contrario, cioe' che siano piu' orientati agli oggetti linguaggi come Python, Ruby e compagnia. Solo che quando vedo parlare di Java come se fosse il linguaggio per la OOP parto in quarta alla cdimauro :D, piu' che altro ha per me delle carenze che non mi vanno giu'. L'ideale sarebbe provare entrambe le alternative e poi decidere... se Matrixbob promette che non si fermera' li', anche partire con Java va bene :p.
AnonimoVeneziano
09-02-2008, 14:44
Vabbè, io mi sono rotto e mi chiamo fuori, devo anche studiare :asd:
Io continuo a consigliare Java per i motivi che ho già elencato.
Ma ci tengo a precisare una cosa :
Non ho mai espresso nessun giudizio su quale sia il metodo migliore per fare OO, ho solo espresso giudizi sul tema didattico. Per tutti i motivi sopra elencati ritengo Java un linguaggio didatticamente migliore del Python per iniziare a programmare in OO , se poi volete trasformare per forza la discussione in un flame su quale sia il migliore linguaggio OO in assoluto allora avete sbagliato persona, perchè non sono assolutamente in grado di formulare alcun giudizio del genere.
Ciao
Io continuo a consigliare Java per i motivi che ho già elencato.
Ma ci tengo a precisare una cosa :
Non ho mai espresso nessun giudizio su quale sia il metodo migliore per fare OO, ho solo espresso giudizi sul tema didattico. Per tutti i motivi sopra elencati ritengo Java un linguaggio didatticamente migliore del Python per iniziare a programmare in OO , se poi volete trasformare per forza la discussione in un flame su quale sia il migliore linguaggio OO in assoluto allora avete sbagliato persona, perchè non sono assolutamente in grado di formulare alcun giudizio del genere.
Ciao
AnonimoVeneziano
09-02-2008, 14:53
Sono d'accordo con te, ma e' anche vero che un linguaggio dinamico e' piu' "naturale" da imparare per un principiante.
Non è un principiante. Conosce già il C .
Non è un principiante. Conosce già il C .
marco.r
09-02-2008, 14:56
Detto questo, Python e' utterly crap, chi lo ha inventato dovrebbe morire fra atroci sofferenze, in python non esistono le stringhe, siete tutti niubbi e bastardi. (Chi indiovina chi sto parafrasando vince due righe di codice autografate :asd:)
Oddio... ce ne sono cose che non vanno in python anche secondo me. Un problema ad esempio e' che non solo le stringhe esistono, ma pure i singoli caratteri sono stringhe :stordita: La sintassi puo' non piacere, ma ci si fa la mano e rispetto ad altri linguaggi simili ha un parco di librerie decisamente piu' ampio (con l'eccezione di Perl, che pero' trovo decisamente piu' caotico), per ottenere risultati pratici in breve tempo va piu' che bene.
Oddio... ce ne sono cose che non vanno in python anche secondo me. Un problema ad esempio e' che non solo le stringhe esistono, ma pure i singoli caratteri sono stringhe :stordita: La sintassi puo' non piacere, ma ci si fa la mano e rispetto ad altri linguaggi simili ha un parco di librerie decisamente piu' ampio (con l'eccezione di Perl, che pero' trovo decisamente piu' caotico), per ottenere risultati pratici in breve tempo va piu' che bene.
fek
09-02-2008, 15:12
Per inciso... non sto dicendo il contrario, cioe' che siano piu' orientati agli oggetti linguaggi come Python, Ruby e compagnia. Solo che quando vedo parlare di Java come se fosse il linguaggio per la OOP parto in quarta alla cdimauro :D, piu' che altro ha per me delle carenze che non mi vanno giu'. L'ideale sarebbe provare entrambe le alternative e poi decidere... se Matrixbob promette che non si fermera' li', anche partire con Java va bene :p.
Sono perfettamente in sintonia nonostante la mia avversione istintiva a Python :)
Sono perfettamente in sintonia nonostante la mia avversione istintiva a Python :)
marco.r
09-02-2008, 15:50
Detto questo, Python e' utterly crap, chi lo ha inventato dovrebbe morire fra atroci sofferenze, in python non esistono le stringhe, siete tutti niubbi e bastardi. (Chi indiovina chi sto parafrasando vince due righe di codice autografate :asd:)
Dovro' far a meno dell'autografo... si fosse trattato di qualcuno "brutto e stupido" forse avrei indovinato :p
Dovro' far a meno dell'autografo... si fosse trattato di qualcuno "brutto e stupido" forse avrei indovinato :p
wisher
09-02-2008, 16:08
Detto questo, Python e' utterly crap, chi lo ha inventato dovrebbe morire fra atroci sofferenze, in python non esistono le stringhe, siete tutti niubbi e bastardi. (Chi indiovina chi sto parafrasando vince due righe di codice autografate :asd:)
Un certo finlandese?
Un certo finlandese?
Dott.Wisem
09-02-2008, 17:12
Io non adoro i linguaggi dinamici,I linguaggi dinamicamente tipati sono sicuramente più leggibili, manutenibili e semplici da usare rispetto a quelli staticamente tipati. Di contro, i programmi scritti in linguaggi dinamicamente tipati sono maggiormente soggetti ad errori subdoli che invece in un linguaggio staticamente tipato sarebbero stati segnalati dal compilatore quantomeno come warning. Nel programma dinamicamente tipato, ci si accorge dell'errore solo a run-time.
cdimauro
11-02-2008, 08:16
So già che ne uscirò sfiancato :D
Non c'è motivo. Poi vedo adesso che siamo arrivati praticamente a un punto morto, avendo ognuno espresso piuttosto chiaramente la propria opinione. Visto che sono intervenuti anche altri, mi limiterò a chiarire qualche punto, senza approfondire troppo.
Beh, in un modello rigido semplicemente significa che quell'oggetto non faceva al caso tuo. Si hanno due obbiettivi diversi. In un caso si da pieno potere al programmatore (col rischio che però poi succeda un casino :D ) , nel secondo si limita la libertà cercando di forzare un determinato comportamento . E' chiaro che se si lavora tra colleghi (magari anche ad uno stesso progetto dove uno fa una classe e l'altro fa un' altra classe che usa la prima per fare il suo lavoro) allora la visibilità non è strettamente necessaria, ma ad esempio per quanto riguarda la produzione di librerie multi-progetto la mancanza della possibilità di privatizzare alcuni attributi è essa stessa un limite alla libertà del programmatore della libreria di correggere eventuali errori di implementazione senza rompere la compatibilità coi sorgenti preesistenti.
Si ritorna, però, allo stesso problema che ho citato: e se per un errore di design non potessi accedere ad attributi a me utili? Con gli altri linguaggi sarei fisicamente impossibilitato, quindi andrebbe a danno della mia produttività.
Chi sviluppa librerie multiprogetto non è comunque limitato nella sua azione, perché usando il name mangling di Python può indicare in che modo vanno usati gli oggetti che ha realizzato, "marcandoli" come "privati" (usando il singolo underscore davanti); chi li andrà a usare in maniera impropria è avvertito che, in caso di modifiche, il suo codice potrà non funzionare e non potrà lamentarsene.
Beh, si può fare anche l'esempietto "i felini sono mammiferi, i gatti sono felini, quindi i gatti sono mammiferi" :p . Quello del carro armato mi sa più di composizione che di ereditarietà :p. Comunque io dubito che questo sia una difficoltà all'apprendimento. Non mi sembra niente di difficile, perlomeno quando io ho imparato Java non mi ha lasciato per niente perplesso. All'inizio l'ho presa come una regola sintattica, poi ho capito perchè di questa scelta di design senza troppi problemi.
Non lo metto in dubbio. :)
Sull'esempio del carroarmato, ci può stare benissimo la composizione (anzi, a livello di design, è la soluzione da preferire).
Beh, in genere gli studenti si cerca di inquadrarli in uno schema, altrimenti si rischia che non riescano a capire da dove iniziare a concentrare le proprie forze cognitive. Dare troppe libertà all'autodidatta può confondere. Magari non capisce qual'è il modo migliore di fare le cose , visto che si può fare in tanti modi . In Python non è chiaro quale sia la norma e quale sono eventuali espressioni usate poco , ma utili in certi frangenti come "trucchetti" per semplificarsi la vita .
Java è poco ambiguo da questo punto di vista e segna subito la strada da seguire.
Guarda, come diceva anche Marco, non è che Python è poco chiaro e/o apre la via a "trucchetti" anche deprecabili.
Il concetto fondamentale è che la DEFINIZIONE di moduli, funzioni, classi e metodi porta alla creazione di oggetti (in Python, ripeto, ogni cosa è un oggetto)... modificabili.
Posso aggiungere, togliere e modificare attribuiti in qualsiasi momento.
Imparato ciò, questa enorme flessibilità la si può utilizzare per imparare velocemente oppure per realizzare "cose carine" per chi è più "scafato". Tutto qui. :)
In quanto linguaggio di scripting il python mette a disposizione questi strumenti (anche se non tutti lo fanno :p). Sicuramente non è un problema per un programmatore C vivere con queste limitazioni. I tipi base sono pochi , lavorare con interi grossi è spesso non necessario (per lo meno in fase di apprendimento, ma spesso anche dopo) e in caso lo sia c'è BigInt. Non mi sembra un grande vantaggio all'apprendimento per uno che viene dal C ...
Chiaro. Io partivo dal presupposto che uno dovesse iniziare da zero a programmare. :)
Infatti io adoro le list comprehension :D
Riccardo le odia. :D
Maddai! E' vero :D Ti giuro che non lo sapevo :p Avevo letto da qualche parte che non si potevano usare (se non sbaglio l'aveva detto anche il mio prof di Info 3) e così non ci ho mai provato :asd: però in effetti non da errore di sintassi e fa quello che deve fare :D
Yup. Il tuo prof. mi sa che si dovrà aggiornare. :D Anche se comunque è notevole che conosca e insegni Python agli studenti.
Purtroppo tanti insegnanti imparano 4 cose in croce e sono restii ai cambiamenti / miglioramenti...
Comunque è innegabile che a vedersi siano equivalenti ad un cavatappi dritto nella pupilla :D
Certamente, e va bene così: DEVONO essere molto più visibili rispetto agli altri metodi.
Una cosa che non sopporto è la definizione dei costruttori e distruttori in linguaggi come il C++: troppo poco evidenti (preferisco nettamente le keyword constructor e destructor usate in Delphi).
Beh, è proprio il concetto di dinamicità della tipizzazione la cosa difficile da capire per un programmatore C. Dopotutto in C la tipizzazione è statica, ma debole :D
In python è dinamica, ma forte. Provenendo dal Pascal, ho sempre preferito una tipizzazione forte: voglio che il compilatore (o il runtime) mi spezzi violentemente le ditine se provo a mischiare capre e cavoli.
Per questo letteralmente aborro linguaggi come PHP, PERL :Puke: e Ruby, che sono di manica troppo larga da questo punto di vista.
Vabbè, io mi sono rotto e mi chiamo fuori, devo anche studiare :asd:
Io continuo a consigliare Java per i motivi che ho già elencato.
Ma ci tengo a precisare una cosa :
Non ho mai espresso nessun giudizio su quale sia il metodo migliore per fare OO, ho solo espresso giudizi sul tema didattico. Per tutti i motivi sopra elencati ritengo Java un linguaggio didatticamente migliore del Python per iniziare a programmare in OO , se poi volete trasformare per forza la discussione in un flame su quale sia il migliore linguaggio OO in assoluto allora avete sbagliato persona, perchè non sono assolutamente in grado di formulare alcun giudizio del genere.
Ciao
Non c'è bisogno di arrabbiarsi, dai. Qui ognuno ha, appunto, espresso la propria opinione in base alle proprie esperienze e al background che ha sviluppato negli anni. Facciamo pace. :flower:
Non c'è motivo. Poi vedo adesso che siamo arrivati praticamente a un punto morto, avendo ognuno espresso piuttosto chiaramente la propria opinione. Visto che sono intervenuti anche altri, mi limiterò a chiarire qualche punto, senza approfondire troppo.
Beh, in un modello rigido semplicemente significa che quell'oggetto non faceva al caso tuo. Si hanno due obbiettivi diversi. In un caso si da pieno potere al programmatore (col rischio che però poi succeda un casino :D ) , nel secondo si limita la libertà cercando di forzare un determinato comportamento . E' chiaro che se si lavora tra colleghi (magari anche ad uno stesso progetto dove uno fa una classe e l'altro fa un' altra classe che usa la prima per fare il suo lavoro) allora la visibilità non è strettamente necessaria, ma ad esempio per quanto riguarda la produzione di librerie multi-progetto la mancanza della possibilità di privatizzare alcuni attributi è essa stessa un limite alla libertà del programmatore della libreria di correggere eventuali errori di implementazione senza rompere la compatibilità coi sorgenti preesistenti.
Si ritorna, però, allo stesso problema che ho citato: e se per un errore di design non potessi accedere ad attributi a me utili? Con gli altri linguaggi sarei fisicamente impossibilitato, quindi andrebbe a danno della mia produttività.
Chi sviluppa librerie multiprogetto non è comunque limitato nella sua azione, perché usando il name mangling di Python può indicare in che modo vanno usati gli oggetti che ha realizzato, "marcandoli" come "privati" (usando il singolo underscore davanti); chi li andrà a usare in maniera impropria è avvertito che, in caso di modifiche, il suo codice potrà non funzionare e non potrà lamentarsene.
Beh, si può fare anche l'esempietto "i felini sono mammiferi, i gatti sono felini, quindi i gatti sono mammiferi" :p . Quello del carro armato mi sa più di composizione che di ereditarietà :p. Comunque io dubito che questo sia una difficoltà all'apprendimento. Non mi sembra niente di difficile, perlomeno quando io ho imparato Java non mi ha lasciato per niente perplesso. All'inizio l'ho presa come una regola sintattica, poi ho capito perchè di questa scelta di design senza troppi problemi.
Non lo metto in dubbio. :)
Sull'esempio del carroarmato, ci può stare benissimo la composizione (anzi, a livello di design, è la soluzione da preferire).
Beh, in genere gli studenti si cerca di inquadrarli in uno schema, altrimenti si rischia che non riescano a capire da dove iniziare a concentrare le proprie forze cognitive. Dare troppe libertà all'autodidatta può confondere. Magari non capisce qual'è il modo migliore di fare le cose , visto che si può fare in tanti modi . In Python non è chiaro quale sia la norma e quale sono eventuali espressioni usate poco , ma utili in certi frangenti come "trucchetti" per semplificarsi la vita .
Java è poco ambiguo da questo punto di vista e segna subito la strada da seguire.
Guarda, come diceva anche Marco, non è che Python è poco chiaro e/o apre la via a "trucchetti" anche deprecabili.
Il concetto fondamentale è che la DEFINIZIONE di moduli, funzioni, classi e metodi porta alla creazione di oggetti (in Python, ripeto, ogni cosa è un oggetto)... modificabili.
Posso aggiungere, togliere e modificare attribuiti in qualsiasi momento.
Imparato ciò, questa enorme flessibilità la si può utilizzare per imparare velocemente oppure per realizzare "cose carine" per chi è più "scafato". Tutto qui. :)
In quanto linguaggio di scripting il python mette a disposizione questi strumenti (anche se non tutti lo fanno :p). Sicuramente non è un problema per un programmatore C vivere con queste limitazioni. I tipi base sono pochi , lavorare con interi grossi è spesso non necessario (per lo meno in fase di apprendimento, ma spesso anche dopo) e in caso lo sia c'è BigInt. Non mi sembra un grande vantaggio all'apprendimento per uno che viene dal C ...
Chiaro. Io partivo dal presupposto che uno dovesse iniziare da zero a programmare. :)
Infatti io adoro le list comprehension :D
Riccardo le odia. :D
Maddai! E' vero :D Ti giuro che non lo sapevo :p Avevo letto da qualche parte che non si potevano usare (se non sbaglio l'aveva detto anche il mio prof di Info 3) e così non ci ho mai provato :asd: però in effetti non da errore di sintassi e fa quello che deve fare :D
Yup. Il tuo prof. mi sa che si dovrà aggiornare. :D Anche se comunque è notevole che conosca e insegni Python agli studenti.
Purtroppo tanti insegnanti imparano 4 cose in croce e sono restii ai cambiamenti / miglioramenti...
Comunque è innegabile che a vedersi siano equivalenti ad un cavatappi dritto nella pupilla :D
Certamente, e va bene così: DEVONO essere molto più visibili rispetto agli altri metodi.
Una cosa che non sopporto è la definizione dei costruttori e distruttori in linguaggi come il C++: troppo poco evidenti (preferisco nettamente le keyword constructor e destructor usate in Delphi).
Beh, è proprio il concetto di dinamicità della tipizzazione la cosa difficile da capire per un programmatore C. Dopotutto in C la tipizzazione è statica, ma debole :D
In python è dinamica, ma forte. Provenendo dal Pascal, ho sempre preferito una tipizzazione forte: voglio che il compilatore (o il runtime) mi spezzi violentemente le ditine se provo a mischiare capre e cavoli.
Per questo letteralmente aborro linguaggi come PHP, PERL :Puke: e Ruby, che sono di manica troppo larga da questo punto di vista.
Vabbè, io mi sono rotto e mi chiamo fuori, devo anche studiare :asd:
Io continuo a consigliare Java per i motivi che ho già elencato.
Ma ci tengo a precisare una cosa :
Non ho mai espresso nessun giudizio su quale sia il metodo migliore per fare OO, ho solo espresso giudizi sul tema didattico. Per tutti i motivi sopra elencati ritengo Java un linguaggio didatticamente migliore del Python per iniziare a programmare in OO , se poi volete trasformare per forza la discussione in un flame su quale sia il migliore linguaggio OO in assoluto allora avete sbagliato persona, perchè non sono assolutamente in grado di formulare alcun giudizio del genere.
Ciao
Non c'è bisogno di arrabbiarsi, dai. Qui ognuno ha, appunto, espresso la propria opinione in base alle proprie esperienze e al background che ha sviluppato negli anni. Facciamo pace. :flower:
cdimauro
11-02-2008, 08:40
ma ragazzi.. c'è poco da discutere :D se uno mi chiede: "quale linguaggio per entrare nella mentalità OO?"
l'ultimo che mi viene in mente è python
ma ormai è il prezzemolo della situazione -_-
Permettimi: visto che può fare praticamente di tutto (e in maniera anche molto semplice), non vedo perché non dovrei citarlo.
Se dobbiamo fare le crociate ideologiche, vorrà dire che la prossima volta a quella precisa domanda che hai riportato risponderò: SmallTalk. :rolleyes:
Anch'io. L'underscore in un linguaggio e' da veri niubbi :(
E usare la maiuscola iniziale per definire una classe o costante, e la minuscola per tutto il resto, non è una forzatura ben peggiore, visto che almeno il doppio underscore è limitato alla definizione dei soli metodi "riservati"? ;)
Per lo meno in Python per qualunque identificatore definisca posso usare il case che voglio. :read: :Prrr:
Senza dubbio...imho Java è un linguaggio molto lineare ed adatto all'apprendimento della OOP. Senza comportamenti astrusi o fuori da ogni logica, anche se magari utili.
Ti stai riferendo a linguaggi come PERL, vero? Perché il modello della definizione degli oggetti Python è semplice, lineare e perfettamente logico. :)
aspetta a parlare che adesso qualcuno tira fuori i generics ;) quanto sono prevedibili queste discussioni :p
Mi hai preceduto. :D
In passato (recente) quando si parlava di leggibilità ho tirato fuori un esempietto in cui Java sfoggiava un brillante uso dei generic che si commentava da sé. ;)
Tutte cose che puoi far male anche negli altri linguaggi.
Però ad esempio in Java non potrai mai mescolare programmazione procedurale e ad oggetti (nonostante che molti ci provino con i metodi statici nella classe principale).
Lo si fa, lo si fa, e anche a livello professionale (quando si è costretti a fare i conti con certi limiti precisi e troppo restrittivi di piattaforma :muro:).
si suppone che uno che programma in java sappia programmare a oggetti o eventualmente stia imparando, perciò non ha senso questo discorso.
tra tutti i linguaggi OO java è quello che permette meno porcherie, per questo lo consiglio come linguaggio per imparare la mentalità OO. è ovvio che uno non si deve limitare a imparare il linguaggio, ma deve anche imparare la programmazione OO nei suoi aspetti più generali. java è soltanto lo strumento
Più che altro è soltanto UNO strumento. ;)
Detto questo, Python e' utterly crap, chi lo ha inventato dovrebbe morire fra atroci sofferenze, in python non esistono le stringhe, siete tutti niubbi e bastardi. (Chi indiovina chi sto parafrasando vince due righe di codice autografate :asd:)
Questo è un colpo basso, Fran! Lo sai che il fine settimana sono impegnato a farmi tortur, ehm, a giocare amorevolmente coi miei figli. :p Non m'hai dato nemmeno la possibilità di competere... :cry:
Sono perfettamente in sintonia nonostante la mia avversione istintiva a Python :)
Certo, certo, dicono tutti così, ma poi... chi disprezza compra. :p
Why I Love Python - Bruce Eckel (http://www.mindviewinc.com/downloads/pub/eckel/LovePython.zip) :fiufiu:
I linguaggi dinamicamente tipati sono sicuramente più leggibili, manutenibili e semplici da usare rispetto a quelli staticamente tipati. Di contro, i programmi scritti in linguaggi dinamicamente tipati sono maggiormente soggetti ad errori subdoli che invece in un linguaggio staticamente tipato sarebbero stati segnalati dal compilatore quantomeno come warning. Nel programma dinamicamente tipato, ci si accorge dell'errore solo a run-time.
Ma a runtime ci si arriva MOLTO PRIMA, e si può testare l'applicazione con dati reali (o quasi) e metterci una pezza molto più velocemente.
Poi esistono anche le unit test, e in Python esiste un apposito modulo integrato nella libreria STANDARD. :read:
l'ultimo che mi viene in mente è python
ma ormai è il prezzemolo della situazione -_-
Permettimi: visto che può fare praticamente di tutto (e in maniera anche molto semplice), non vedo perché non dovrei citarlo.
Se dobbiamo fare le crociate ideologiche, vorrà dire che la prossima volta a quella precisa domanda che hai riportato risponderò: SmallTalk. :rolleyes:
Anch'io. L'underscore in un linguaggio e' da veri niubbi :(
E usare la maiuscola iniziale per definire una classe o costante, e la minuscola per tutto il resto, non è una forzatura ben peggiore, visto che almeno il doppio underscore è limitato alla definizione dei soli metodi "riservati"? ;)
Per lo meno in Python per qualunque identificatore definisca posso usare il case che voglio. :read: :Prrr:
Senza dubbio...imho Java è un linguaggio molto lineare ed adatto all'apprendimento della OOP. Senza comportamenti astrusi o fuori da ogni logica, anche se magari utili.
Ti stai riferendo a linguaggi come PERL, vero? Perché il modello della definizione degli oggetti Python è semplice, lineare e perfettamente logico. :)
aspetta a parlare che adesso qualcuno tira fuori i generics ;) quanto sono prevedibili queste discussioni :p
Mi hai preceduto. :D
In passato (recente) quando si parlava di leggibilità ho tirato fuori un esempietto in cui Java sfoggiava un brillante uso dei generic che si commentava da sé. ;)
Tutte cose che puoi far male anche negli altri linguaggi.
Però ad esempio in Java non potrai mai mescolare programmazione procedurale e ad oggetti (nonostante che molti ci provino con i metodi statici nella classe principale).
Lo si fa, lo si fa, e anche a livello professionale (quando si è costretti a fare i conti con certi limiti precisi e troppo restrittivi di piattaforma :muro:).
si suppone che uno che programma in java sappia programmare a oggetti o eventualmente stia imparando, perciò non ha senso questo discorso.
tra tutti i linguaggi OO java è quello che permette meno porcherie, per questo lo consiglio come linguaggio per imparare la mentalità OO. è ovvio che uno non si deve limitare a imparare il linguaggio, ma deve anche imparare la programmazione OO nei suoi aspetti più generali. java è soltanto lo strumento
Più che altro è soltanto UNO strumento. ;)
Detto questo, Python e' utterly crap, chi lo ha inventato dovrebbe morire fra atroci sofferenze, in python non esistono le stringhe, siete tutti niubbi e bastardi. (Chi indiovina chi sto parafrasando vince due righe di codice autografate :asd:)
Questo è un colpo basso, Fran! Lo sai che il fine settimana sono impegnato a farmi tortur, ehm, a giocare amorevolmente coi miei figli. :p Non m'hai dato nemmeno la possibilità di competere... :cry:
Sono perfettamente in sintonia nonostante la mia avversione istintiva a Python :)
Certo, certo, dicono tutti così, ma poi... chi disprezza compra. :p
Why I Love Python - Bruce Eckel (http://www.mindviewinc.com/downloads/pub/eckel/LovePython.zip) :fiufiu:
I linguaggi dinamicamente tipati sono sicuramente più leggibili, manutenibili e semplici da usare rispetto a quelli staticamente tipati. Di contro, i programmi scritti in linguaggi dinamicamente tipati sono maggiormente soggetti ad errori subdoli che invece in un linguaggio staticamente tipato sarebbero stati segnalati dal compilatore quantomeno come warning. Nel programma dinamicamente tipato, ci si accorge dell'errore solo a run-time.
Ma a runtime ci si arriva MOLTO PRIMA, e si può testare l'applicazione con dati reali (o quasi) e metterci una pezza molto più velocemente.
Poi esistono anche le unit test, e in Python esiste un apposito modulo integrato nella libreria STANDARD. :read:
AnonimoVeneziano
11-02-2008, 10:15
Non c'è bisogno di arrabbiarsi, dai. Qui ognuno ha, appunto, espresso la propria opinione in base alle proprie esperienze e al background che ha sviluppato negli anni. Facciamo pace. :flower:
Non rispondo punto per punto perchè sono essenzialmente d'accordo con quello che hai scritto.
Comunque non mi ero arrabbiato :D Mi ero però leggermente dispiaciuto nel constatare che i miei messaggi venivano quotati come se stessi facendo delle critiche a python che io in realtà non ho fatto perchè ho concentrato il mio discorso sulla didattica. Ho solo detto che , a mio modestissimo e opinabile parere, Java è meglio di Python per imparare le basi dell' OO.
Quindi non è mai stata mia intenzione sminuire le varie caratteristiche di questo linguaggio, non ne sono neanche in grado visto che Python lo conosco, ma non ci ho fatto niente di semi-serio e finchè uno strumento non lo usi sono sicuro che non si possano fare commenti obiettivi. Però posso commentare il percorso di apprendimento del python, perchè quello l'ho attraversato ed è stato più confusionario rispetto a quello Java. Volevo esprimere questa mia idea che però alcuni hanno interpretato come critica al linguaggio Python stesso. Mi piacerebbe chiarire il fatto che non era mia intenzione farne alcuna :)
Ciao
Non rispondo punto per punto perchè sono essenzialmente d'accordo con quello che hai scritto.
Comunque non mi ero arrabbiato :D Mi ero però leggermente dispiaciuto nel constatare che i miei messaggi venivano quotati come se stessi facendo delle critiche a python che io in realtà non ho fatto perchè ho concentrato il mio discorso sulla didattica. Ho solo detto che , a mio modestissimo e opinabile parere, Java è meglio di Python per imparare le basi dell' OO.
Quindi non è mai stata mia intenzione sminuire le varie caratteristiche di questo linguaggio, non ne sono neanche in grado visto che Python lo conosco, ma non ci ho fatto niente di semi-serio e finchè uno strumento non lo usi sono sicuro che non si possano fare commenti obiettivi. Però posso commentare il percorso di apprendimento del python, perchè quello l'ho attraversato ed è stato più confusionario rispetto a quello Java. Volevo esprimere questa mia idea che però alcuni hanno interpretato come critica al linguaggio Python stesso. Mi piacerebbe chiarire il fatto che non era mia intenzione farne alcuna :)
Ciao
fek
11-02-2008, 10:23
E usare la maiuscola iniziale per definire una classe o costante, e la minuscola per tutto il resto, non è una forzatura ben peggiore, visto che almeno il doppio underscore è limitato alla definizione dei soli metodi "riservati"? ;)
No, e' un coding standard non imposto dalla grammatica del linguaggio, ma libero da adottare da un team di sviluppo ;)
C'e' chi inizia le classi con C, ad esempio.
No, e' un coding standard non imposto dalla grammatica del linguaggio, ma libero da adottare da un team di sviluppo ;)
C'e' chi inizia le classi con C, ad esempio.
cdimauro
11-02-2008, 10:27
Non rispondo punto per punto perchè sono essenzialmente d'accordo con quello che hai scritto.
Comunque non mi ero arrabbiato :D Mi ero però leggermente dispiaciuto nel constatare che i miei messaggi venivano quotati come se stessi facendo delle critiche a python che io in realtà non ho fatto perchè ho concentrato il mio discorso sulla didattica. Ho solo detto che , a mio modestissimo e opinabile parere, Java è meglio di Python per imparare le basi dell' OO.
Quindi non è mai stata mia intenzione sminuire le varie caratteristiche di questo linguaggio, non ne sono neanche in grado visto che Python lo conosco, ma non ci ho fatto niente di semi-serio e finchè uno strumento non lo usi sono sicuro che non si possano fare commenti obiettivi. Però posso commentare il percorso di apprendimento del python, perchè quello l'ho attraversato ed è stato più confusionario rispetto a quello Java. Volevo esprimere questa mia idea che però alcuni hanno interpretato come critica al linguaggio Python stesso. Mi piacerebbe chiarire il fatto che non era mia intenzione farne alcuna :)
Ciao
Per me è chiaro, non c'è problema. ;)
Mi spiace soltanto per il percorso "accidentato", ma spero che in futuro potrai approfondire l'esperienza con Python. :)
Comunque non mi ero arrabbiato :D Mi ero però leggermente dispiaciuto nel constatare che i miei messaggi venivano quotati come se stessi facendo delle critiche a python che io in realtà non ho fatto perchè ho concentrato il mio discorso sulla didattica. Ho solo detto che , a mio modestissimo e opinabile parere, Java è meglio di Python per imparare le basi dell' OO.
Quindi non è mai stata mia intenzione sminuire le varie caratteristiche di questo linguaggio, non ne sono neanche in grado visto che Python lo conosco, ma non ci ho fatto niente di semi-serio e finchè uno strumento non lo usi sono sicuro che non si possano fare commenti obiettivi. Però posso commentare il percorso di apprendimento del python, perchè quello l'ho attraversato ed è stato più confusionario rispetto a quello Java. Volevo esprimere questa mia idea che però alcuni hanno interpretato come critica al linguaggio Python stesso. Mi piacerebbe chiarire il fatto che non era mia intenzione farne alcuna :)
Ciao
Per me è chiaro, non c'è problema. ;)
Mi spiace soltanto per il percorso "accidentato", ma spero che in futuro potrai approfondire l'esperienza con Python. :)
cdimauro
11-02-2008, 10:39
No, e' un coding standard non imposto dalla grammatica del linguaggio, ma libero da adottare da un team di sviluppo ;)
C'e' chi inizia le classi con C, ad esempio.
Ricordavo che fosse una restrizione della grammatica. Ricordavo male allora. :p
C'e' chi inizia le classi con C, ad esempio.
Ricordavo che fosse una restrizione della grammatica. Ricordavo male allora. :p
Dott.Wisem
11-02-2008, 12:07
Ma a runtime ci si arriva MOLTO PRIMA, e si può testare l'applicazione con dati reali (o quasi) e metterci una pezza molto più velocemente.
Poi esistono anche le unit test, e in Python esiste un apposito modulo integrato nella libreria STANDARD. :read:Infatti anche in Suneido esiste un framework integrato nella libreria standard per le unit test. Il problema è che le unit test non ti obbliga nessuno a crearle, e quindi, se sei pigro (come il 90% dei programmatori), non le crei... :D
P.S.: comunque io adoro i linguaggi dinamicamente tipati... Un codice scritto in un linguaggio dinamicamente tipato è almeno 10 volte più leggibile (e quindi più facilmente manutenibile) di uno scritto con un linguaggio staticamente tipato. Ma per applicazioni mission-critical, dove un bug a runtime può costare molto caro, probabilmente quelli staticamente tipati sono da preferire. Meglio ancora, quei linguaggi che consentono di adottare metodologie di Design By Contract.
Poi esistono anche le unit test, e in Python esiste un apposito modulo integrato nella libreria STANDARD. :read:Infatti anche in Suneido esiste un framework integrato nella libreria standard per le unit test. Il problema è che le unit test non ti obbliga nessuno a crearle, e quindi, se sei pigro (come il 90% dei programmatori), non le crei... :D
P.S.: comunque io adoro i linguaggi dinamicamente tipati... Un codice scritto in un linguaggio dinamicamente tipato è almeno 10 volte più leggibile (e quindi più facilmente manutenibile) di uno scritto con un linguaggio staticamente tipato. Ma per applicazioni mission-critical, dove un bug a runtime può costare molto caro, probabilmente quelli staticamente tipati sono da preferire. Meglio ancora, quei linguaggi che consentono di adottare metodologie di Design By Contract.
Matrixbob
11-02-2008, 12:56
5 pagine ormai, devo trovare il tempo di spulciarlo tutto. Azz.
gugoXX
11-02-2008, 13:12
PS = Ah, un altra cosa. Python permette letteralmente di aggiungere attributi e metodi dopo che la classe è stata instanziata ... anche questo non mi piace molto a livello di rigorosità del paradigma object oriented.
Questa e' stata aggiunta anche dal C#, nel 3.0
E non rompe il paradigma ad oggetti, perche' si puo' accedere alle sole variabili/metodi pubblici della classe stessa.
In pratica sarebbe come ereditare una nuova classe, aggiungendo ad essa il metodo che ti serve.
L'uso di tale feature non e' sempre sinonimo di cattiva progettazione della classe base. Semplicemente la classe potrebbe non essere stata scritta da te, oppure potresti non avere proprio i sorgenti...
Esempio, mi piacerebbe estendere la classe int, con il metodo
public string ScriviloInItaliano();
in modo da poter scrivere codice come
int pippo=5;
Console.WriteLine(pippo.ScriviloInItaliano());
Il C#3.0 e' stato costretto ad aggiungere tale feature per altri motivi.
Il motivo principale e' che ora alcune classi possono essere create al volo dal precomplilatore. Tali classi non vengono quindi dichiarate nel modo classico, (possono addiruttura non avere alcun nome), ma possono comunque essere estese dal programmatore con altre proprieta' o metodi.
PS: Se non sbaglio si puo' anche estendere object con un nuovo metodo.
A quel punto tutti gli oggetti, derivando da object, avrebbero tale metodo a disposizione.
Questa e' stata aggiunta anche dal C#, nel 3.0
E non rompe il paradigma ad oggetti, perche' si puo' accedere alle sole variabili/metodi pubblici della classe stessa.
In pratica sarebbe come ereditare una nuova classe, aggiungendo ad essa il metodo che ti serve.
L'uso di tale feature non e' sempre sinonimo di cattiva progettazione della classe base. Semplicemente la classe potrebbe non essere stata scritta da te, oppure potresti non avere proprio i sorgenti...
Esempio, mi piacerebbe estendere la classe int, con il metodo
public string ScriviloInItaliano();
in modo da poter scrivere codice come
int pippo=5;
Console.WriteLine(pippo.ScriviloInItaliano());
Il C#3.0 e' stato costretto ad aggiungere tale feature per altri motivi.
Il motivo principale e' che ora alcune classi possono essere create al volo dal precomplilatore. Tali classi non vengono quindi dichiarate nel modo classico, (possono addiruttura non avere alcun nome), ma possono comunque essere estese dal programmatore con altre proprieta' o metodi.
PS: Se non sbaglio si puo' anche estendere object con un nuovo metodo.
A quel punto tutti gli oggetti, derivando da object, avrebbero tale metodo a disposizione.
Dott.Wisem
11-02-2008, 13:16
5 pagine ormai, devo trovare il tempo di spulciarlo tutto. Azz.Comunque, tornando alla tua domanda iniziale, ovvero, se devi cambiare modo di pensare per passare da linguaggi tradizionali a quelli object-oriented, la risposta è certamente SI. Con i linguaggi object-oriented sei maggiormente portato ad ingegnerizzare il problema, ovvero a progettare, prima di buttarti a capofitto sul codice. E questo è sempre un bene.
^TiGeRShArK^
11-02-2008, 13:23
Il C#3.0 e' stato costretto ad aggiungere tale feature per altri motivi.
Linq?
Linq?
tomminno
11-02-2008, 13:23
Concordo :mano:
Ed il primo è Java imho.
A rigor di logica a me come primo viene in mente C#, visto che in questo linguaggio qualunque cosa è una classe derivata da Object.
Ed il primo è Java imho.
A rigor di logica a me come primo viene in mente C#, visto che in questo linguaggio qualunque cosa è una classe derivata da Object.
cdimauro
11-02-2008, 13:28
Infatti anche in Suneido esiste un framework integrato nella libreria standard per le unit test. Il problema è che le unit test non ti obbliga nessuno a crearle, e quindi, se sei pigro (come il 90% dei programmatori), non le crei... :D
Nel mio caso non si tratta di pigrizia, ma di mancanza di tempo (per crearmi l'ambiente).
Io lo unit test me lo sogno la notte (mi risolverebbe parecchi problemi). :muro:
P.S.: comunque io adoro i linguaggi dinamicamente tipati... Un codice scritto in un linguaggio dinamicamente tipato è almeno 10 volte più leggibile (e quindi più facilmente manutenibile) di uno scritto con un linguaggio staticamente tipato.
Concordo: è per questo che adoro Python. :D
Ma per applicazioni mission-critical, dove un bug a runtime può costare molto caro, probabilmente quelli staticamente tipati sono da preferire. Meglio ancora, quei linguaggi che consentono di adottare metodologie di Design By Contract.
Qualche tempo fa ricordo di aver letto un'intervista a Bertrand Meyer in cui gli si chiedeva cosa ne pensasse del TDD (test driven development); rispose che col DbC di linguaggi come Eiffel era inutile.
A mio avviso sbaglia per due motivi.
Il primo è che col DbC si può controllare il comportamento di una classe e/o dei suoi metodi, ma non l'interazione fra più oggetti (e, eventualmente, dell'intera applicazione); correggetemi se sbaglio, perché non mi pare di aver visto costrutti sintattici allo scopo (ma è passato tempo e posso anche ricordare male).
Il secondo è che il DbC richiede un NOTEVOLE sforzo computazionale IN FASE DI ESECUZIONE.
Ecco perché preferisco nettamente la strada del TDD: sicuramente risulta meno "esaustiva" del DbC (i test, se non scritti correttamente, possono non effettuare i controlli necessari; col DbC, invece, tutte le condizioni vengono SEMPRE controllate durante la normale esecuzione del codice di produzione), ma meno "invasiva" (tutti i controlli vengono eseguiti una sola volta, in fase di esecuzione dei test; nel codice di produzione non c'è, in linea teorica, traccia del codice di test e quindi dei controlli effettuati).
Con la TDD anche linguaggi di scripting come Python, Ruby, ecc. si ha la possibilità di produrre codice "controllato", senza per questo perdere l'enorme flessibilità che la loro struttura di linguaggi dinamici permette loro. ;)
5 pagine ormai, devo trovare il tempo di spulciarlo tutto. Azz.
Non ti preoccupare, te lo riassumo io: usa Python e vai tranquillo. :D
Nel mio caso non si tratta di pigrizia, ma di mancanza di tempo (per crearmi l'ambiente).
Io lo unit test me lo sogno la notte (mi risolverebbe parecchi problemi). :muro:
P.S.: comunque io adoro i linguaggi dinamicamente tipati... Un codice scritto in un linguaggio dinamicamente tipato è almeno 10 volte più leggibile (e quindi più facilmente manutenibile) di uno scritto con un linguaggio staticamente tipato.
Concordo: è per questo che adoro Python. :D
Ma per applicazioni mission-critical, dove un bug a runtime può costare molto caro, probabilmente quelli staticamente tipati sono da preferire. Meglio ancora, quei linguaggi che consentono di adottare metodologie di Design By Contract.
Qualche tempo fa ricordo di aver letto un'intervista a Bertrand Meyer in cui gli si chiedeva cosa ne pensasse del TDD (test driven development); rispose che col DbC di linguaggi come Eiffel era inutile.
A mio avviso sbaglia per due motivi.
Il primo è che col DbC si può controllare il comportamento di una classe e/o dei suoi metodi, ma non l'interazione fra più oggetti (e, eventualmente, dell'intera applicazione); correggetemi se sbaglio, perché non mi pare di aver visto costrutti sintattici allo scopo (ma è passato tempo e posso anche ricordare male).
Il secondo è che il DbC richiede un NOTEVOLE sforzo computazionale IN FASE DI ESECUZIONE.
Ecco perché preferisco nettamente la strada del TDD: sicuramente risulta meno "esaustiva" del DbC (i test, se non scritti correttamente, possono non effettuare i controlli necessari; col DbC, invece, tutte le condizioni vengono SEMPRE controllate durante la normale esecuzione del codice di produzione), ma meno "invasiva" (tutti i controlli vengono eseguiti una sola volta, in fase di esecuzione dei test; nel codice di produzione non c'è, in linea teorica, traccia del codice di test e quindi dei controlli effettuati).
Con la TDD anche linguaggi di scripting come Python, Ruby, ecc. si ha la possibilità di produrre codice "controllato", senza per questo perdere l'enorme flessibilità che la loro struttura di linguaggi dinamici permette loro. ;)
5 pagine ormai, devo trovare il tempo di spulciarlo tutto. Azz.
Non ti preoccupare, te lo riassumo io: usa Python e vai tranquillo. :D
gugoXX
11-02-2008, 13:34
Linq?
Esatto.
Esatto.
marco.r
11-02-2008, 13:36
[QUOTE=Dott.Wisem;21027598]
P.S.: comunque io adoro i linguaggi dinamicamente tipati... Un codice scritto in un linguaggio dinamicamente tipato è almeno 10 volte più leggibile (e quindi più facilmente manutenibile) di uno scritto con un linguaggio staticamente tipato.
[/quoto]
Sono d'accordo con te su questo. Un buon compromesso è l'uso di inferenza automatica del tipo da parte del compilatore. Meno caratteri da scrivere e da "filtrare" quando si legge. Il problema è che non sempre è facile farlo a posteriori su di un linguaggio, ed infatti in C# il risultato non è splendido (anche se meglio di niente).
P.S.: comunque io adoro i linguaggi dinamicamente tipati... Un codice scritto in un linguaggio dinamicamente tipato è almeno 10 volte più leggibile (e quindi più facilmente manutenibile) di uno scritto con un linguaggio staticamente tipato.
[/quoto]
Sono d'accordo con te su questo. Un buon compromesso è l'uso di inferenza automatica del tipo da parte del compilatore. Meno caratteri da scrivere e da "filtrare" quando si legge. Il problema è che non sempre è facile farlo a posteriori su di un linguaggio, ed infatti in C# il risultato non è splendido (anche se meglio di niente).
marco.r
11-02-2008, 13:40
No, e' un coding standard non imposto dalla grammatica del linguaggio, ma libero da adottare da un team di sviluppo ;)
C'e' chi inizia le classi con C, ad esempio.
Ah, ti riferivi al linguaggio in sè, non al coding style. Capisco la critica ora :p.
Se ti può consolare altri linguaggi fanno pure peggio... in Haskell ad esempio tutti i tipi sono maiuscoli e tutti gli identificatori minuscoli, e non ci si scappa.
C'e' chi inizia le classi con C, ad esempio.
Ah, ti riferivi al linguaggio in sè, non al coding style. Capisco la critica ora :p.
Se ti può consolare altri linguaggi fanno pure peggio... in Haskell ad esempio tutti i tipi sono maiuscoli e tutti gli identificatori minuscoli, e non ci si scappa.
cdimauro
11-02-2008, 13:41
AAAAAARRRRRGGGGGGHHHHHHHH! :cry: :cry: :cry:
DioBrando
11-02-2008, 13:54
Detto questo, Python e' utterly crap, chi lo ha inventato dovrebbe morire fra atroci sofferenze, in python non esistono le stringhe, siete tutti niubbi e bastardi. (Chi indiovina chi sto parafrasando vince due righe di codice autografate :asd:)
A occhio direi Torvalds in merito all'articolo recente su MacOSX e Vista che è peggio del primo e sono entrambi peggio di Linux (rotfl).
Però si espresse in questi termini anche sulla diatriba solita C-C++:
C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.
Ho vinto la bambolina? :D
A occhio direi Torvalds in merito all'articolo recente su MacOSX e Vista che è peggio del primo e sono entrambi peggio di Linux (rotfl).
Però si espresse in questi termini anche sulla diatriba solita C-C++:
C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.
Ho vinto la bambolina? :D
DioBrando
11-02-2008, 13:59
aspetta a parlare che adesso qualcuno tira fuori i generics ;) quanto sono prevedibili queste discussioni :p
I generics sn esattamente uno dei motivi per cui + di qualcuno ha criticato (fra cui il sottoscritto) l'evoluzione di Java (linguaggio e piattaforma) che invece di procedere attraverso un re-design, si espande tramite nuove collezioni di librerie principalmente (principalmente per preservare la compatibilità a differenza di altri linguaggi).
Tanto per riallacciarsi a una discussione di qualche tempo fa' :D
Sul thread, senza essere fondamentalisti credo che i linguaggi + recenti vadano tutti + o - al di là delle preferenze sintattiche, sia che siano dynamically-typed o meno.
Sconsiglierei solo di seguire il percorso C--->C++ che invece è adottato abbastanza frequentemente alle Università.
I generics sn esattamente uno dei motivi per cui + di qualcuno ha criticato (fra cui il sottoscritto) l'evoluzione di Java (linguaggio e piattaforma) che invece di procedere attraverso un re-design, si espande tramite nuove collezioni di librerie principalmente (principalmente per preservare la compatibilità a differenza di altri linguaggi).
Tanto per riallacciarsi a una discussione di qualche tempo fa' :D
Sul thread, senza essere fondamentalisti credo che i linguaggi + recenti vadano tutti + o - al di là delle preferenze sintattiche, sia che siano dynamically-typed o meno.
Sconsiglierei solo di seguire il percorso C--->C++ che invece è adottato abbastanza frequentemente alle Università.
Dott.Wisem
11-02-2008, 16:00
C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.Non ne ho capito bene il senso: il C++ farebbe schifo perché è usato da tanti programmatori incompetenti? Io credo che lui volesse dire: programmare BENE in C++ è una cosa complicata. Tanti programmatori, per pigrizia e/o cattive abitudini, usano il C++ come fosse un C con classi e basta, e alla fine i loro programmi finiscono per essere decisamente poco object-oriented. Quindi, in un progetto open-source che supervisiona, lui preferisce avere tutto codice C, piuttosto che codice C++ 'vero' mischiato a pezzi di codice C travestiti da C++. E poi, riorganizzare tutto il codice di Linux in un linguaggio object-oriented, senza rompere la compatibilità verso il basso, sarebbe un qualcosa di immane... Chi sarebbe disposto a farlo? Torvalds certamente no... :D
cdimauro
11-02-2008, 16:10
Per forza che non ne hai capito bene il senso: NON HA SENSO! :p
http://warp.povusers.org/OpenLetters/ResponseToTorvalds.html :fiufiu: :asd:
http://warp.povusers.org/OpenLetters/ResponseToTorvalds.html :fiufiu: :asd:
Dott.Wisem
11-02-2008, 17:00
Per forza che non ne hai capito bene il senso: NON HA SENSO! :p
http://warp.povusers.org/OpenLetters/ResponseToTorvalds.html :fiufiu: :asd:Mi trovo perfettamente d'accordo con l'articolo linkato. Linus Torvalds soffre dalla sindrome dell'hackerite da C. :D
http://warp.povusers.org/OpenLetters/ResponseToTorvalds.html :fiufiu: :asd:Mi trovo perfettamente d'accordo con l'articolo linkato. Linus Torvalds soffre dalla sindrome dell'hackerite da C. :D
fek
11-02-2008, 17:56
Non ne ho capito bene il senso: il C++
Neppure lui.
Chi sarebbe disposto a farlo? Torvalds certamente no... :D
Anche perche' non sa programmare in C++ :)
Neppure lui.
Chi sarebbe disposto a farlo? Torvalds certamente no... :D
Anche perche' non sa programmare in C++ :)
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.