cionci
17-09-2007, 12:22
in questi casi lo switch (o case che dir si voglia) diventa un'alternativa decisamente piu' ragionevole
Anche più leggibile e manutenibile...
Anche più leggibile e manutenibile...
View Full Version : Torvalds e C++
The3DProgrammer
17-09-2007, 12:38
comunque sia la probabilità di commettere errori non cambia, cambia solo il modo in cui è spalmata nel modulo
comunque nel mio caso aggiungo un blocco else if uguale agli altri appena sopra, mentre nel caso di diamonds devo creare una nuova classe che implementa MenuAction e poi istanziarla in MenuItem
eh no aspetta nn è così facile :p
Ogni menu ha voci diverse, quindi mi vengono in mente 2 possibilità (se me ne sfugge qualcuna segnalamela :fagiano: ):
1) Rendere il gestore dei menu classe base (con il metodo che si occupa di gestire i menuItems astratto) e creare una sottoclasse per ogni menu, implementando la catena di if per ogni gestore
2) Mettere tutte le condizioni in un unica classe manager per tutti i menu :muro:
Nel primo caso dovresti andare a modificare tutte le classi per mettere lo stesso codice in ogni catena di if, mentre nel secondo avresti da fare una sola modifica, ma a che prezzo...
Con un codice scritto sfruttando il principio open/closed, invece, non avresti altro da fare che creare una classe (in cui è presente un solo metodo) per il nuovo menuItem e andare ad aggiungerlo a tutti i menu con qualcosa di simile ad un gestoreMenuK.add(nuovoItem), senza modificare il codice esistente. Il vantaggio è evidente, non solo in fase di estensione del comportamento del menu ma anche in caso di eventuale debug: supponiamo che il codice che hai scritto per il nuovo menuItem invece di espletare la funzione di "exit" dall'applicazione ti riavvii il pc (:sofico:): Nel caso della catena di if dovrai andare a correggere tutte le porzioni di codice inserite, mentre nell'altra situazione dovrai andare a modificare solo il metodo relativo nella sottoclasse creata appositamente.
non metto in dubbio che il mapping ha la sua utilità. il fatto è che qui si sta mettendo in dubbio che lo switch (o chi ne fa le veci) ha anche lui la sua utilità
ma no, non intendo mica questo: Per porzione di codice brevi e difficilmente soggette a modifiche future non mi vado certo ad imbarcare in un mapping xD
ciao
comunque nel mio caso aggiungo un blocco else if uguale agli altri appena sopra, mentre nel caso di diamonds devo creare una nuova classe che implementa MenuAction e poi istanziarla in MenuItem
eh no aspetta nn è così facile :p
Ogni menu ha voci diverse, quindi mi vengono in mente 2 possibilità (se me ne sfugge qualcuna segnalamela :fagiano: ):
1) Rendere il gestore dei menu classe base (con il metodo che si occupa di gestire i menuItems astratto) e creare una sottoclasse per ogni menu, implementando la catena di if per ogni gestore
2) Mettere tutte le condizioni in un unica classe manager per tutti i menu :muro:
Nel primo caso dovresti andare a modificare tutte le classi per mettere lo stesso codice in ogni catena di if, mentre nel secondo avresti da fare una sola modifica, ma a che prezzo...
Con un codice scritto sfruttando il principio open/closed, invece, non avresti altro da fare che creare una classe (in cui è presente un solo metodo) per il nuovo menuItem e andare ad aggiungerlo a tutti i menu con qualcosa di simile ad un gestoreMenuK.add(nuovoItem), senza modificare il codice esistente. Il vantaggio è evidente, non solo in fase di estensione del comportamento del menu ma anche in caso di eventuale debug: supponiamo che il codice che hai scritto per il nuovo menuItem invece di espletare la funzione di "exit" dall'applicazione ti riavvii il pc (:sofico:): Nel caso della catena di if dovrai andare a correggere tutte le porzioni di codice inserite, mentre nell'altra situazione dovrai andare a modificare solo il metodo relativo nella sottoclasse creata appositamente.
non metto in dubbio che il mapping ha la sua utilità. il fatto è che qui si sta mettendo in dubbio che lo switch (o chi ne fa le veci) ha anche lui la sua utilità
ma no, non intendo mica questo: Per porzione di codice brevi e difficilmente soggette a modifiche future non mi vado certo ad imbarcare in un mapping xD
ciao
fek
17-09-2007, 12:43
ma lol, non è che qui si vuole contestare te o le tue scelte, ognuno fa come meglio crede...il problema è che noi ti stiamo dando delle motivazioni precise e rilevanti sul perchè la catena di if, SOPRATTUTTO nel contesto prima descritto (cioè un modulo software che deve realizzare una funzionalità ad alta suscettibilità di modifiche future quali un menu) non è adatta. Un principio "abbastanza" importante violato da quel codice è stato già descritto, se vuoi possono citartene almeno un altro (il principio di singola responsabilità: andando a inserire tutto il codice di gestione dei menu items in quella catena di if tu dai al gestore del menu + responsabilità, quindi + possibilità di fare errori in quel modulo, quindi + possibilità di doverlo modificare per compiti che non gli spettano).
Infatti esistono diverse ricerche di HP e IBM che dimostrano come il defect rate di una catena di if (o sequenza di switch/case) sia almeno un ordine di grandezza piu' alto della stessa funzionalita' implementata mediante interfaccia e virtual dispatching, e il costo di manutenzione della seconda soluzione sia piu' basso.
Inoltre una catena di if ha complessita ciclomatica totale e per metodo piu' alta di un'implementazione mediante virtual dispatching, ed e' anche qui dimostrato sperimentalmente come il defect rate e i costi di manutenzione di un software crescano proporzionalmente al crescere della complessita' ciclomatica (sia totale sia media per metodo).
In sintesi: la probabilita' di commettere errori e' piu' alta usando catene di if o switch:
http://www.ibm.com/developerworks/java/library/j-cq03316/
In fact, various studies over the years have determined that methods having a cyclomatic complexity (or CC) greater than 10 have a higher risk of defects.
Infatti esistono diverse ricerche di HP e IBM che dimostrano come il defect rate di una catena di if (o sequenza di switch/case) sia almeno un ordine di grandezza piu' alto della stessa funzionalita' implementata mediante interfaccia e virtual dispatching, e il costo di manutenzione della seconda soluzione sia piu' basso.
Inoltre una catena di if ha complessita ciclomatica totale e per metodo piu' alta di un'implementazione mediante virtual dispatching, ed e' anche qui dimostrato sperimentalmente come il defect rate e i costi di manutenzione di un software crescano proporzionalmente al crescere della complessita' ciclomatica (sia totale sia media per metodo).
In sintesi: la probabilita' di commettere errori e' piu' alta usando catene di if o switch:
http://www.ibm.com/developerworks/java/library/j-cq03316/
In fact, various studies over the years have determined that methods having a cyclomatic complexity (or CC) greater than 10 have a higher risk of defects.
Dott.Wisem
17-09-2007, 12:45
[...]Poi onestamente di come funzionano le cose con gli altri linguaggi m'interessa ben poco: quando programmo con un preciso linguaggio non voglio e non devo farmi condizionare dagli schemi mentali a cui ero abituato.Ok, questo vale se tendi ad usare sempre quel linguaggio. Ma se ne usi diversi, incomincia a diventare complicato doversi adattare, di volta in volta, a diversi schemi mentali.
La prima, nettamente: ho già immediatamente visibile ciò che otterò, e a seguire COME lo otterò (che è meno interessante).Immaginavo che avresti preferito la prima, ma è una tua preferenza personale. La maggior parte dei programmatori lì fuori non la pensa così, essendo abituati ad una sintassi più tradizionale, relativamente alle istruzioni di controllo di flusso... :) E riallacciandomi a quanto detto prima, essere costretto ad usare differenti schemi mentali per fare le stesse operazioni (ma in linguaggi differenti) mi pare una cosa masochistica. Io, generalmente, sono per la semplicità e la chiarezza espressiva, anche a costo di perdere in sinteticità.
In questo caso in effetti ho sbagliato perché ho mischiato un esempio d'uso di una mappa al posto di uno switch, con un costrutto più leggibile.
Avrei dovuto usare questo:
Resolver = {
'PDU:' : lambda URI, Parameters: URI,
'http:' : httpResolver,
'https:' : httpsResolver,
'db:' : lambda URI, Parameters: GetData(DBUtils.SQLGet, URI, Parameters)
}
def ResolveURI(URI, Parameters):
if URI:
Index = URI.find(':', 0, 10)
if Index >= 0:
Index = Index + 1
Prefix = URI[ : Index]
URI = URI[Index : ]
URI = Resolver[Prefix](URI, Parameters) # Qui si esegue la scelta, tramite map in questo caso, o tramite catena di if-else
return URI
return ''
In questo caso la decisione viene presa in un punto ben preciso del codice (quello che precede return URI), e il significato mi sembra chiaro e leggibile (Resolver è un dizionario / mappa che restituisce una funzione da chiamare). Vabbé, ho capito che ti piace molto il Python, ma non è che devi usarlo ogni volta che devi esprimere un concetto (anche perché un esempio simile mi pare fosse stato già fatto in questo thread, ma in Java, se non erro)... :D
Ad ogni modo, nel caso particolare del tuo esempio, io trovo più leggibile uno switch/case, poiché posso vedere subito quello che accade in base alle diverse condizioni. Poi ognuno ha le sue opinioni... ;)
Certo che se uno prevede di dover aggiungere in futuro tanti elementi nello switch, allora il mapping è una soluzione migliore.
La prima, nettamente: ho già immediatamente visibile ciò che otterò, e a seguire COME lo otterò (che è meno interessante).Immaginavo che avresti preferito la prima, ma è una tua preferenza personale. La maggior parte dei programmatori lì fuori non la pensa così, essendo abituati ad una sintassi più tradizionale, relativamente alle istruzioni di controllo di flusso... :) E riallacciandomi a quanto detto prima, essere costretto ad usare differenti schemi mentali per fare le stesse operazioni (ma in linguaggi differenti) mi pare una cosa masochistica. Io, generalmente, sono per la semplicità e la chiarezza espressiva, anche a costo di perdere in sinteticità.
In questo caso in effetti ho sbagliato perché ho mischiato un esempio d'uso di una mappa al posto di uno switch, con un costrutto più leggibile.
Avrei dovuto usare questo:
Resolver = {
'PDU:' : lambda URI, Parameters: URI,
'http:' : httpResolver,
'https:' : httpsResolver,
'db:' : lambda URI, Parameters: GetData(DBUtils.SQLGet, URI, Parameters)
}
def ResolveURI(URI, Parameters):
if URI:
Index = URI.find(':', 0, 10)
if Index >= 0:
Index = Index + 1
Prefix = URI[ : Index]
URI = URI[Index : ]
URI = Resolver[Prefix](URI, Parameters) # Qui si esegue la scelta, tramite map in questo caso, o tramite catena di if-else
return URI
return ''
In questo caso la decisione viene presa in un punto ben preciso del codice (quello che precede return URI), e il significato mi sembra chiaro e leggibile (Resolver è un dizionario / mappa che restituisce una funzione da chiamare). Vabbé, ho capito che ti piace molto il Python, ma non è che devi usarlo ogni volta che devi esprimere un concetto (anche perché un esempio simile mi pare fosse stato già fatto in questo thread, ma in Java, se non erro)... :D
Ad ogni modo, nel caso particolare del tuo esempio, io trovo più leggibile uno switch/case, poiché posso vedere subito quello che accade in base alle diverse condizioni. Poi ognuno ha le sue opinioni... ;)
Certo che se uno prevede di dover aggiungere in futuro tanti elementi nello switch, allora il mapping è una soluzione migliore.
k0nt3
17-09-2007, 12:54
eh no aspetta nn è così facile :p
Ogni menu ha voci diverse, quindi mi vengono in mente 2 possibilità (se me ne sfugge qualcuna segnalamela :fagiano: ):
1) Rendere il gestore dei menu classe base (con il metodo che si occupa di gestire i menuItems astratto) e creare una sottoclasse per ogni menu, implementando la catena di if per ogni gestore
2) Mettere tutte le condizioni in un unica classe manager per tutti i menu :muro:
non lo so.. io avrei pensato a solo due classi: MainMenu e MenuItem
MainMenu si preoccupa di gestire i MenuItems e l'unica cosa che devi fare nel caso vuoi aggiungere una nuova voce sarebbe aggiungere un else if nella catena
ma per me rimane una questione di scelta, non di religione
ma no, non intendo mica questo: Per porzione di codice brevi e difficilmente soggette a modifiche future non mi vado certo ad imbarcare in un mapping xD
ciao
non intendevo te ;)
Ogni menu ha voci diverse, quindi mi vengono in mente 2 possibilità (se me ne sfugge qualcuna segnalamela :fagiano: ):
1) Rendere il gestore dei menu classe base (con il metodo che si occupa di gestire i menuItems astratto) e creare una sottoclasse per ogni menu, implementando la catena di if per ogni gestore
2) Mettere tutte le condizioni in un unica classe manager per tutti i menu :muro:
non lo so.. io avrei pensato a solo due classi: MainMenu e MenuItem
MainMenu si preoccupa di gestire i MenuItems e l'unica cosa che devi fare nel caso vuoi aggiungere una nuova voce sarebbe aggiungere un else if nella catena
ma per me rimane una questione di scelta, non di religione
ma no, non intendo mica questo: Per porzione di codice brevi e difficilmente soggette a modifiche future non mi vado certo ad imbarcare in un mapping xD
ciao
non intendevo te ;)
cdimauro
17-09-2007, 13:14
Ok, questo vale se tendi ad usare sempre quel linguaggio. Ma se ne usi diversi, incomincia a diventare complicato doversi adattare, di volta in volta, a diversi schemi mentali.
Non conosco programmatori che abitualmente programmano in una dozzina di linguaggi di programmazione diversi. :D
In genere se ne usa uno, magari due per periodi di tempo più o meno lunghi.
Per cui mi sembra più che naturale abituarsi a programmare in un certo modo. ;)
Immaginavo che avresti preferito la prima, ma è una tua preferenza personale.
La domanda l'hai fatta a me: è il minimo che ti riportassi la mia opinione. :p
La maggior parte dei programmatori lì fuori non la pensa così, essendo abituati ad una sintassi più tradizionale, relativamente alle istruzioni di controllo di flusso... :)
Vedi, lo dici anche tu: sono ABITUATI in un certo modo. E comunque la frequenza non è certo indice di validità. ;)
E riallacciandomi a quanto detto prima, essere costretto ad usare differenti schemi mentali per fare le stesse operazioni (ma in linguaggi differenti) mi pare una cosa masochistica.
Vedi sopra: se non lo fai tutti i giorni non vedo la difficoltà nell'adattarsi. L'uomo è riuscito a sopravvivere grazie alle sue formidabilità capacità di adattamento. ;)
Io, generalmente, sono per la semplicità e la chiarezza espressiva, anche a costo di perdere in sinteticità.
Dipende da quello che vuoi fare, dal ruolo che hai nel progetto, se lavori in team e dal livello di skill del team.
Certamente da uno che deve leggere il mio codice come minimo mi aspetto che conosca bene Python come linguaggio.
Vabbé, ho capito che ti piace molto il Python, ma non è che devi usarlo ogni volta che devi esprimere un concetto (anche perché un esempio simile mi pare fosse stato già fatto in questo thread, ma in Java, se non erro)... :D
Non me lo ricordo. :|
Ad ogni modo, nel caso particolare del tuo esempio, io trovo più leggibile uno switch/case, poiché posso vedere subito quello che accade in base alle diverse condizioni. Poi ognuno ha le sue opinioni... ;)
A me interessa che venga elaborato un protocollo. Il COME ciò avvenga, e QUANTI & QUALI ce ne siano non m'importa (tranne quando devo aggiungerne qualcuno, il che non avviene tutti i giorni :D).
Certo che se uno prevede di dover aggiungere in futuro tanti elementi nello switch, allora il mapping è una soluzione migliore.
Anche per questo ho usato il mapping: era già previsto che in futuro dovessi gestire diversi protocolli (uno l'ho aggiunto qualche tempo fa), a seconda delle esigenze della nostra piattaforma.
In questo modo lo posso fare in maniera "indolore", senza andare a toccare minimamente tutto il codice già scritto, funzionate e testato.
Comunque qui mi pare che nessuno abbia scritto di evitare del tutto switch e/o catene di if/else: ci sono casi in cui ciò non è oggettivamente possibile, ad esempio.
Non conosco programmatori che abitualmente programmano in una dozzina di linguaggi di programmazione diversi. :D
In genere se ne usa uno, magari due per periodi di tempo più o meno lunghi.
Per cui mi sembra più che naturale abituarsi a programmare in un certo modo. ;)
Immaginavo che avresti preferito la prima, ma è una tua preferenza personale.
La domanda l'hai fatta a me: è il minimo che ti riportassi la mia opinione. :p
La maggior parte dei programmatori lì fuori non la pensa così, essendo abituati ad una sintassi più tradizionale, relativamente alle istruzioni di controllo di flusso... :)
Vedi, lo dici anche tu: sono ABITUATI in un certo modo. E comunque la frequenza non è certo indice di validità. ;)
E riallacciandomi a quanto detto prima, essere costretto ad usare differenti schemi mentali per fare le stesse operazioni (ma in linguaggi differenti) mi pare una cosa masochistica.
Vedi sopra: se non lo fai tutti i giorni non vedo la difficoltà nell'adattarsi. L'uomo è riuscito a sopravvivere grazie alle sue formidabilità capacità di adattamento. ;)
Io, generalmente, sono per la semplicità e la chiarezza espressiva, anche a costo di perdere in sinteticità.
Dipende da quello che vuoi fare, dal ruolo che hai nel progetto, se lavori in team e dal livello di skill del team.
Certamente da uno che deve leggere il mio codice come minimo mi aspetto che conosca bene Python come linguaggio.
Vabbé, ho capito che ti piace molto il Python, ma non è che devi usarlo ogni volta che devi esprimere un concetto (anche perché un esempio simile mi pare fosse stato già fatto in questo thread, ma in Java, se non erro)... :D
Non me lo ricordo. :|
Ad ogni modo, nel caso particolare del tuo esempio, io trovo più leggibile uno switch/case, poiché posso vedere subito quello che accade in base alle diverse condizioni. Poi ognuno ha le sue opinioni... ;)
A me interessa che venga elaborato un protocollo. Il COME ciò avvenga, e QUANTI & QUALI ce ne siano non m'importa (tranne quando devo aggiungerne qualcuno, il che non avviene tutti i giorni :D).
Certo che se uno prevede di dover aggiungere in futuro tanti elementi nello switch, allora il mapping è una soluzione migliore.
Anche per questo ho usato il mapping: era già previsto che in futuro dovessi gestire diversi protocolli (uno l'ho aggiunto qualche tempo fa), a seconda delle esigenze della nostra piattaforma.
In questo modo lo posso fare in maniera "indolore", senza andare a toccare minimamente tutto il codice già scritto, funzionate e testato.
Comunque qui mi pare che nessuno abbia scritto di evitare del tutto switch e/o catene di if/else: ci sono casi in cui ciò non è oggettivamente possibile, ad esempio.
^TiGeRShArK^
17-09-2007, 13:49
va bene, però effettivamente non so come si sarebbe potuto fare a meno di quella modifica
sarebbe bastato caricare al runtime tutte le classi di tipo MenuItem tramite reflection e specificare all'interno delle classi stesse il loro ordine all'interno del menu (o anche usare una mappa per la gestione dell'ordine..alla fine dipende dalla scelta).
Nè + nè meno di quando ho usato la reflection nell'implementazione del parser precedentemente discusso.
In questo modo è sufficiente inserire una nuova classe e, eventualmente se non va alla fine del menu, specificare l'ordine con uno dei meccanismi precedentemente citati.
E sinceramente per la manutenibilità del codice mi pare molto + semplice creare una nuova classe (che eventualmente può anke essere generata al runtime sempre tramite reflection tramite una funzione che accetta i parametri necessari al corretto funzionamento dell'oggetto e senza necessità di scrivere sul file una nuova classe se siamo troppo pigri ;)) piuttosto che modificare una lunghissima catena di switch, modificando magari anke l'ordine per rispettare l'ordine di inserimento nel menu :p
sarebbe bastato caricare al runtime tutte le classi di tipo MenuItem tramite reflection e specificare all'interno delle classi stesse il loro ordine all'interno del menu (o anche usare una mappa per la gestione dell'ordine..alla fine dipende dalla scelta).
Nè + nè meno di quando ho usato la reflection nell'implementazione del parser precedentemente discusso.
In questo modo è sufficiente inserire una nuova classe e, eventualmente se non va alla fine del menu, specificare l'ordine con uno dei meccanismi precedentemente citati.
E sinceramente per la manutenibilità del codice mi pare molto + semplice creare una nuova classe (che eventualmente può anke essere generata al runtime sempre tramite reflection tramite una funzione che accetta i parametri necessari al corretto funzionamento dell'oggetto e senza necessità di scrivere sul file una nuova classe se siamo troppo pigri ;)) piuttosto che modificare una lunghissima catena di switch, modificando magari anke l'ordine per rispettare l'ordine di inserimento nel menu :p
^TiGeRShArK^
17-09-2007, 13:51
In sintesi: la probabilita' di commettere errori e' piu' alta usando catene di if o switch:
http://www.ibm.com/developerworks/java/library/j-cq03316/
In fact, various studies over the years have determined that methods having a cyclomatic complexity (or CC) greater than 10 have a higher risk of defects.
sinceramente non stento a crederci dato che anke nella mia poca esperienza avevo notato + o - ciò :p
http://www.ibm.com/developerworks/java/library/j-cq03316/
In fact, various studies over the years have determined that methods having a cyclomatic complexity (or CC) greater than 10 have a higher risk of defects.
sinceramente non stento a crederci dato che anke nella mia poca esperienza avevo notato + o - ciò :p
^TiGeRShArK^
17-09-2007, 13:55
non lo so.. io avrei pensato a solo due classi: MainMenu e MenuItem
MainMenu si preoccupa di gestire i MenuItems e l'unica cosa che devi fare nel caso vuoi aggiungere una nuova voce sarebbe aggiungere un else if nella catena
ma per me rimane una questione di scelta, non di religione
non intendevo te ;)
e per modificare l'ordine del menu come faresti? :p
cmq scrivere una catena di if/else per un applicazione reale con n menu è semplicemente uno spararsi sui coglioni imho :p
sarà ke sono un patito della reflection.. ma in molti casi è utile dato che non vedo perchè scrivere altro codice quando il codice che ti serve può essere semplicemente generato con una sola riga di codice :p
MainMenu si preoccupa di gestire i MenuItems e l'unica cosa che devi fare nel caso vuoi aggiungere una nuova voce sarebbe aggiungere un else if nella catena
ma per me rimane una questione di scelta, non di religione
non intendevo te ;)
e per modificare l'ordine del menu come faresti? :p
cmq scrivere una catena di if/else per un applicazione reale con n menu è semplicemente uno spararsi sui coglioni imho :p
sarà ke sono un patito della reflection.. ma in molti casi è utile dato che non vedo perchè scrivere altro codice quando il codice che ti serve può essere semplicemente generato con una sola riga di codice :p
k0nt3
17-09-2007, 14:08
l'ordine non c'entra, MenuItem contiene tutto
comunque non è certo una scelta valida in generale quella che ho postato io, vale nel caso in cui il menu ha poche voci (dove per "poche" come sempre si spera nel buon senso di chi scrive il codice)
d'altra parte però anche l'implementazione di diamonds è soggetta allo sparamento nei coglioni nel caso in cui le voci cambiano alla velocità della luce
comunque non è certo una scelta valida in generale quella che ho postato io, vale nel caso in cui il menu ha poche voci (dove per "poche" come sempre si spera nel buon senso di chi scrive il codice)
d'altra parte però anche l'implementazione di diamonds è soggetta allo sparamento nei coglioni nel caso in cui le voci cambiano alla velocità della luce
Dott.Wisem
17-09-2007, 14:10
Non conosco programmatori che abitualmente programmano in una dozzina di linguaggi di programmazione diversi. :D
In genere se ne usa uno, magari due per periodi di tempo più o meno lunghi.
Per cui mi sembra più che naturale abituarsi a programmare in un certo modo. ;) Ma già usare due linguaggi che siano radicalmente diversi come sintassi, per me è una rottura non indifferente. Sarò pigro... :p
Ad esempio, trovo che SmallTalk sia un linguaggio estremamente affascinante, essendo quello che si avvicina maggiormente al concetto di linguaggio object-oriented 'puro' (possiede solo 6 keyword riservate... Il resto è implementato mediante scambi di messaggi fra oggetti, incluse le strutture di controllo!). Però ha una sintassi totalmente diversa dalle solite, cosa che scoraggia notevolmente il suo apprendimento.
Vedi, lo dici anche tu: sono ABITUATI in un certo modo. E comunque la frequenza non è certo indice di validità. ;)No, ma se i linguaggi più usati impongono certi schemi mentali da 30 anni, uno tende ad usare quelli, anche se in giro c'è di meglio. E non mi pare una scelta irrazionale, ma puramente di ordine pratico. :)
Vedi sopra: se non lo fai tutti i giorni non vedo la difficoltà nell'adattarsi. L'uomo è riuscito a sopravvivere grazie alle sue formidabilità capacità di adattamento. ;)Indubbiamente, ma prima di sforzarmi di adottare un insolito schema mentale, devo considerare il tempo che occorre per apprendere nuovi concetti, in relazione ai vantaggi concreti che otterrei, sia nell'immediato che nel lungo periodo.
Non me lo ricordo. :|
Mi riferisco ai vari esempi sulla classe MenuItem fatti qualche pagina fa.
A me interessa che venga elaborato un protocollo. Il COME ciò avvenga, e QUANTI & QUALI ce ne siano non m'importa (tranne quando devo aggiungerne qualcuno, il che non avviene tutti i giorni :D).
Anche per questo ho usato il mapping: era già previsto che in futuro dovessi gestire diversi protocolli (uno l'ho aggiunto qualche tempo fa), a seconda delle esigenze della nostra piattaforma.
In questo modo lo posso fare in maniera "indolore", senza andare a toccare minimamente tutto il codice già scritto, funzionate e testato.
Comunque qui mi pare che nessuno abbia scritto di evitare del tutto switch e/o catene di if/else: ci sono casi in cui ciò non è oggettivamente possibile, ad esempio.Appunto, come sto cercando di dire da tanti post, alla fine il punto è che il mapping non è sempre la soluzione migliore, né la più leggibile, così come non sempre lo è lo switch o l'if-then-else. ;)
In genere se ne usa uno, magari due per periodi di tempo più o meno lunghi.
Per cui mi sembra più che naturale abituarsi a programmare in un certo modo. ;) Ma già usare due linguaggi che siano radicalmente diversi come sintassi, per me è una rottura non indifferente. Sarò pigro... :p
Ad esempio, trovo che SmallTalk sia un linguaggio estremamente affascinante, essendo quello che si avvicina maggiormente al concetto di linguaggio object-oriented 'puro' (possiede solo 6 keyword riservate... Il resto è implementato mediante scambi di messaggi fra oggetti, incluse le strutture di controllo!). Però ha una sintassi totalmente diversa dalle solite, cosa che scoraggia notevolmente il suo apprendimento.
Vedi, lo dici anche tu: sono ABITUATI in un certo modo. E comunque la frequenza non è certo indice di validità. ;)No, ma se i linguaggi più usati impongono certi schemi mentali da 30 anni, uno tende ad usare quelli, anche se in giro c'è di meglio. E non mi pare una scelta irrazionale, ma puramente di ordine pratico. :)
Vedi sopra: se non lo fai tutti i giorni non vedo la difficoltà nell'adattarsi. L'uomo è riuscito a sopravvivere grazie alle sue formidabilità capacità di adattamento. ;)Indubbiamente, ma prima di sforzarmi di adottare un insolito schema mentale, devo considerare il tempo che occorre per apprendere nuovi concetti, in relazione ai vantaggi concreti che otterrei, sia nell'immediato che nel lungo periodo.
Non me lo ricordo. :|
Mi riferisco ai vari esempi sulla classe MenuItem fatti qualche pagina fa.
A me interessa che venga elaborato un protocollo. Il COME ciò avvenga, e QUANTI & QUALI ce ne siano non m'importa (tranne quando devo aggiungerne qualcuno, il che non avviene tutti i giorni :D).
Anche per questo ho usato il mapping: era già previsto che in futuro dovessi gestire diversi protocolli (uno l'ho aggiunto qualche tempo fa), a seconda delle esigenze della nostra piattaforma.
In questo modo lo posso fare in maniera "indolore", senza andare a toccare minimamente tutto il codice già scritto, funzionate e testato.
Comunque qui mi pare che nessuno abbia scritto di evitare del tutto switch e/o catene di if/else: ci sono casi in cui ciò non è oggettivamente possibile, ad esempio.Appunto, come sto cercando di dire da tanti post, alla fine il punto è che il mapping non è sempre la soluzione migliore, né la più leggibile, così come non sempre lo è lo switch o l'if-then-else. ;)
PGI-Bis
17-09-2007, 14:10
Ho letto con interesse L'articolo di IBM che è stato citato: ha qualche problema.
Questa parte, ad esempio
"Studies have shown that the average person has the capacity to handle about seven pieces of data in her or his head, plus or minus two."
fa riferimento ad un noto studio di George Miller (The Magical Number Seven Plus Minus Two). Brillante, encomiabile e vetusto. Di quello studio oggi resta solo il principio "l'uomo tende all'ammucchiata". Di informazioni, che credevate :oink: . La questione attiene alla teoria dei raggruppamenti ed oggi sappiamo che la capacità di gestire una molteplicità di informazioni dipende da addestramento, contesto e atteggiamento in misura tale da non rendere neppure possibile discutere di una capacità minima. Si può prendere, ad esempio, il lavoro di Faloon, Ericsson e Chase (Acquisition of a memory skill), il quale dimostra come la capacità di raggruppare dipenda dall'addestramento o il lavoro di Simon (How Big is a Chunk) secondo cui, in modo apparentemente incredibile, il raggruppamento di un certo numero di informazioni è facilitato dall'aumento di quel numero (per contestualizzazione).
La teoria dei raggruppamenti rappresenta un modello plausibile di gestione della complessità da parte del cervello umano ma non offre una misura della stessa per via dell'elevato numero di variabili che potrebbero influenzarla.
E questo senza neppure toccare il problema della divergenza tra le informazioni acquisibili (quello che vedo) e le informazioni acquisite (quello che ho in mente dopo aver visto).
Insomma, è più che apprezzabile il tentativo di definire una metrica della complessità ma prendiamola cum grano salis.
Questa parte, ad esempio
"Studies have shown that the average person has the capacity to handle about seven pieces of data in her or his head, plus or minus two."
fa riferimento ad un noto studio di George Miller (The Magical Number Seven Plus Minus Two). Brillante, encomiabile e vetusto. Di quello studio oggi resta solo il principio "l'uomo tende all'ammucchiata". Di informazioni, che credevate :oink: . La questione attiene alla teoria dei raggruppamenti ed oggi sappiamo che la capacità di gestire una molteplicità di informazioni dipende da addestramento, contesto e atteggiamento in misura tale da non rendere neppure possibile discutere di una capacità minima. Si può prendere, ad esempio, il lavoro di Faloon, Ericsson e Chase (Acquisition of a memory skill), il quale dimostra come la capacità di raggruppare dipenda dall'addestramento o il lavoro di Simon (How Big is a Chunk) secondo cui, in modo apparentemente incredibile, il raggruppamento di un certo numero di informazioni è facilitato dall'aumento di quel numero (per contestualizzazione).
La teoria dei raggruppamenti rappresenta un modello plausibile di gestione della complessità da parte del cervello umano ma non offre una misura della stessa per via dell'elevato numero di variabili che potrebbero influenzarla.
E questo senza neppure toccare il problema della divergenza tra le informazioni acquisibili (quello che vedo) e le informazioni acquisite (quello che ho in mente dopo aver visto).
Insomma, è più che apprezzabile il tentativo di definire una metrica della complessità ma prendiamola cum grano salis.
^TiGeRShArK^
17-09-2007, 14:12
l'ordine non c'entra, MenuItem contiene tutto
comunque non è certo una scelta valida in generale quella che ho postato io, vale nel caso in cui il menu ha poche voci (dove per "poche" come sempre si spera nel buon senso di chi scrive il codice)
d'altra parte però anche l'implementazione di diamonds è soggetta allo sparamento nei coglioni nel caso in cui le voci cambiano alla velocità della luce
xkè non è stato implementato il meccanismo che ho specificato sopra :p
in quel modo sarebbe stato sufficiente aggiungere la nuova classe senza modificare alcunchè :D
comunque non è certo una scelta valida in generale quella che ho postato io, vale nel caso in cui il menu ha poche voci (dove per "poche" come sempre si spera nel buon senso di chi scrive il codice)
d'altra parte però anche l'implementazione di diamonds è soggetta allo sparamento nei coglioni nel caso in cui le voci cambiano alla velocità della luce
xkè non è stato implementato il meccanismo che ho specificato sopra :p
in quel modo sarebbe stato sufficiente aggiungere la nuova classe senza modificare alcunchè :D
^TiGeRShArK^
17-09-2007, 14:13
Appunto, come sto cercando di dire da tanti post, alla fine il punto è che il mapping non è sempre la soluzione migliore, né la più leggibile, così come non sempre lo è lo switch o l'if-then-else. ;)
si ovviamente non è SEMPRE preferibile il mapping o qualche altro artificio, ma imho nella maggior parte dei casi sufficientemente complessi si :p
si ovviamente non è SEMPRE preferibile il mapping o qualche altro artificio, ma imho nella maggior parte dei casi sufficientemente complessi si :p
^TiGeRShArK^
17-09-2007, 14:16
Di quello studio oggi resta solo il principio "l'uomo tende all'ammucchiata". Di informazioni, che credevate :oink:
speravo in qualcos'altro :sob:
certo magari una bella ammucchiata uomo-donna con uomo che va da 1 ad 1 e donna da 1 ad N :oink:
speravo in qualcos'altro :sob:
certo magari una bella ammucchiata uomo-donna con uomo che va da 1 ad 1 e donna da 1 ad N :oink:
fek
17-09-2007, 14:38
Questa parte, ad esempio
"Studies have shown that the average person has the capacity to handle about seven pieces of data in her or his head, plus or minus two."
fa riferimento ad un noto studio di George Miller (The Magical Number Seven Plus Minus Two).
Non e' il solo studio che dimostra la correlazione fra la complessita' ciclomatica e il defect rate.
http://delivery.acm.org/10.1145/150000/141952/p178-walsh.pdf?key1=141952&key2=1182300911&coll=GUIDE&dl=ACM&CFID=30038273&CFTOKEN=80047901
http://blogs.construx.com/forums/rss.aspx?ForumID=30&PostID=262
... in tests that we did using the the Cyclomatic Complexity Metric, we established a correlation between the number of lines of code that need to be changed and the complexity of the code.
http://www.cs.rutgers.edu/~rmartin/teaching/spring06/cs553/papers/010.pdf
While effects of complexity can be modified somewhat
as discussed in Section 6, the correlation still persists.
In [10], a study was performed on IBM and Nortel
systems, evaluating multiple measures of complexity
against defect rates. It was found that while the most
complex modules were not necessarily the most defectprone,
and vice versa, they tended to be ranked among
the higher-defect clusters.
E svariati altri. Direi che questa correlazione e' piu' che evidente e ben supportata dai dati empirici.
"Studies have shown that the average person has the capacity to handle about seven pieces of data in her or his head, plus or minus two."
fa riferimento ad un noto studio di George Miller (The Magical Number Seven Plus Minus Two).
Non e' il solo studio che dimostra la correlazione fra la complessita' ciclomatica e il defect rate.
http://delivery.acm.org/10.1145/150000/141952/p178-walsh.pdf?key1=141952&key2=1182300911&coll=GUIDE&dl=ACM&CFID=30038273&CFTOKEN=80047901
http://blogs.construx.com/forums/rss.aspx?ForumID=30&PostID=262
... in tests that we did using the the Cyclomatic Complexity Metric, we established a correlation between the number of lines of code that need to be changed and the complexity of the code.
http://www.cs.rutgers.edu/~rmartin/teaching/spring06/cs553/papers/010.pdf
While effects of complexity can be modified somewhat
as discussed in Section 6, the correlation still persists.
In [10], a study was performed on IBM and Nortel
systems, evaluating multiple measures of complexity
against defect rates. It was found that while the most
complex modules were not necessarily the most defectprone,
and vice versa, they tended to be ranked among
the higher-defect clusters.
E svariati altri. Direi che questa correlazione e' piu' che evidente e ben supportata dai dati empirici.
cdimauro
17-09-2007, 14:41
Ma già usare due linguaggi che siano radicalmente diversi come sintassi, per me è una rottura non indifferente. Sarò pigro... :p
Io ne ho imparati un bel po', ma normalmente ne usavo un paio alla volta in determinati periodi.
Ad esempio, trovo che SmallTalk sia un linguaggio estremamente affascinante, essendo quello che si avvicina maggiormente al concetto di linguaggio object-oriented 'puro' (possiede solo 6 keyword riservate... Il resto è implementato mediante scambi di messaggi fra oggetti, incluse le strutture di controllo!). Però ha una sintassi totalmente diversa dalle solite, cosa che scoraggia notevolmente il suo apprendimento.
Hai fatto l'esempio giusto: è un linguaggio MOOOOOLTO particolare. :D
No, ma se i linguaggi più usati impongono certi schemi mentali da 30 anni, uno tende ad usare quelli, anche se in giro c'è di meglio. E non mi pare una scelta irrazionale, ma puramente di ordine pratico. :)
La pratica deriva dal fatto che i linguaggi di cui parli sono semplicemente i più usati. Quindi si è diffuso un certo modo di programmare.
Indubbiamente, ma prima di sforzarmi di adottare un insolito schema mentale, devo considerare il tempo che occorre per apprendere nuovi concetti, in relazione ai vantaggi concreti che otterrei, sia nell'immediato che nel lungo periodo.
Chiaro, ma linguaggi particolarmente ricchi e versatili come Python non si impara a usarli bene subito, ma lavorandoci ogni giorno.
Mi riferisco ai vari esempi sulla classe MenuItem fatti qualche pagina fa.
Ah, ecco. Capito. Sì, hai ragione.
Appunto, come sto cercando di dire da tanti post, alla fine il punto è che il mapping non è sempre la soluzione migliore, né la più leggibile, così come non sempre lo è lo switch o l'if-then-else. ;)
Su questo concordo con "TigerShark". :)
Io ne ho imparati un bel po', ma normalmente ne usavo un paio alla volta in determinati periodi.
Ad esempio, trovo che SmallTalk sia un linguaggio estremamente affascinante, essendo quello che si avvicina maggiormente al concetto di linguaggio object-oriented 'puro' (possiede solo 6 keyword riservate... Il resto è implementato mediante scambi di messaggi fra oggetti, incluse le strutture di controllo!). Però ha una sintassi totalmente diversa dalle solite, cosa che scoraggia notevolmente il suo apprendimento.
Hai fatto l'esempio giusto: è un linguaggio MOOOOOLTO particolare. :D
No, ma se i linguaggi più usati impongono certi schemi mentali da 30 anni, uno tende ad usare quelli, anche se in giro c'è di meglio. E non mi pare una scelta irrazionale, ma puramente di ordine pratico. :)
La pratica deriva dal fatto che i linguaggi di cui parli sono semplicemente i più usati. Quindi si è diffuso un certo modo di programmare.
Indubbiamente, ma prima di sforzarmi di adottare un insolito schema mentale, devo considerare il tempo che occorre per apprendere nuovi concetti, in relazione ai vantaggi concreti che otterrei, sia nell'immediato che nel lungo periodo.
Chiaro, ma linguaggi particolarmente ricchi e versatili come Python non si impara a usarli bene subito, ma lavorandoci ogni giorno.
Mi riferisco ai vari esempi sulla classe MenuItem fatti qualche pagina fa.
Ah, ecco. Capito. Sì, hai ragione.
Appunto, come sto cercando di dire da tanti post, alla fine il punto è che il mapping non è sempre la soluzione migliore, né la più leggibile, così come non sempre lo è lo switch o l'if-then-else. ;)
Su questo concordo con "TigerShark". :)
cdimauro
17-09-2007, 14:46
Non e' il solo studio che dimostra la correlazione fra la complessita' ciclomatica e il defect rate.
Infatti sappiamo che a una definizione oggettiva / universale della misura della "complessità" di un codice non ci si arriverà mai, ma ricerche come queste sono comunque interessanti perché possono darci delle indicazioni utili per orientarci nello sviluppo del codice.
D'altra parte dalla teoria sappiamo che non è possibile dimostrare che un qualunque software non abbia bug, ma non per questo ci asteniamo dallo svilupparne. :p
Infatti sappiamo che a una definizione oggettiva / universale della misura della "complessità" di un codice non ci si arriverà mai, ma ricerche come queste sono comunque interessanti perché possono darci delle indicazioni utili per orientarci nello sviluppo del codice.
D'altra parte dalla teoria sappiamo che non è possibile dimostrare che un qualunque software non abbia bug, ma non per questo ci asteniamo dallo svilupparne. :p
PGI-Bis
17-09-2007, 14:47
Non e' il solo studio che dimostra la correlazione fra la complessita' ciclomatica e il defect rate.
Immagino di no e con ogni probabilità l'autore di quell'articolo non ha ritenuto opportuno, vista la sede, approfondire la questione. Ma sai che io ho il tarlo del "perchè".
Immagino di no e con ogni probabilità l'autore di quell'articolo non ha ritenuto opportuno, vista la sede, approfondire la questione. Ma sai che io ho il tarlo del "perchè".
marco.r
17-09-2007, 20:18
def StrToInt(s):
Bases = (('%', 2), ('&', 8), ('$', 16), ('0x', 16), ('0X', 16), ('', 10))
return int(*((s[len(Prefix) : ], Base) for Prefix, Base in Bases if s.startswith(Prefix)).next())
Devo dire che neanche a me piace tantissimo :p, non tanto per l'uso dei generatori (che pure sono meno chiari delle liste tradizionali), quanto perche'
spezzerei l'ultima riga... trovo difficile la lettura di list comprehension, o l'equivalente dei generatori, quando gli elementi vengono dati in pasto a qualcosa di piu' complicato di una chiamata a funzione... il codice "conclude" in mezzo alla riga.
Bases = (('%', 2), ('&', 8), ('$', 16), ('0x', 16), ('0X', 16), ('', 10))
return int(*((s[len(Prefix) : ], Base) for Prefix, Base in Bases if s.startswith(Prefix)).next())
Devo dire che neanche a me piace tantissimo :p, non tanto per l'uso dei generatori (che pure sono meno chiari delle liste tradizionali), quanto perche'
spezzerei l'ultima riga... trovo difficile la lettura di list comprehension, o l'equivalente dei generatori, quando gli elementi vengono dati in pasto a qualcosa di piu' complicato di una chiamata a funzione... il codice "conclude" in mezzo alla riga.
cdimauro
17-09-2007, 20:25
Devo dire che neanche a me piace tantissimo :p, non tanto per l'uso dei generatori (che pure sono meno chiari delle liste tradizionali), quanto perche'
spezzerei l'ultima riga... trovo difficile la lettura di list comprehension, o l'equivalente dei generatori, quando gli elementi vengono dati in pasto a qualcosa di piu' complicato di una chiamata a funzione... il codice "conclude" in mezzo alla riga.
Questa:
def StrToInt(s):
Bases = (('%', 2), ('&', 8), ('$', 16), ('0x', 16), ('0X', 16), ('', 10))
Choise = ((s[len(Prefix) : ], Base) for Prefix, Base in Bases if s.startswith(Prefix)).next())
return int(*Choise)
andrebbe meglio?
O questa:
def StrToInt(s):
Bases = (('%', 2), ('&', 8), ('$', 16), ('0x', 16), ('0X', 16), ('', 10))
Generator = ((s[len(Prefix) : ], Base) for Prefix, Base in Bases if s.startswith(Prefix))
Choise = Generator.next()
return int(*Choise)
?
Oltre a queste soluzioni significherebbe rinunciare del tutto all'uso dei generatori, ma non mi aggrederebbe: li trovo troppo comodi e, almeno per me, anche leggibili (ho subito visibile quello che mi aspetto e che mi servirà dopo).
spezzerei l'ultima riga... trovo difficile la lettura di list comprehension, o l'equivalente dei generatori, quando gli elementi vengono dati in pasto a qualcosa di piu' complicato di una chiamata a funzione... il codice "conclude" in mezzo alla riga.
Questa:
def StrToInt(s):
Bases = (('%', 2), ('&', 8), ('$', 16), ('0x', 16), ('0X', 16), ('', 10))
Choise = ((s[len(Prefix) : ], Base) for Prefix, Base in Bases if s.startswith(Prefix)).next())
return int(*Choise)
andrebbe meglio?
O questa:
def StrToInt(s):
Bases = (('%', 2), ('&', 8), ('$', 16), ('0x', 16), ('0X', 16), ('', 10))
Generator = ((s[len(Prefix) : ], Base) for Prefix, Base in Bases if s.startswith(Prefix))
Choise = Generator.next()
return int(*Choise)
?
Oltre a queste soluzioni significherebbe rinunciare del tutto all'uso dei generatori, ma non mi aggrederebbe: li trovo troppo comodi e, almeno per me, anche leggibili (ho subito visibile quello che mi aspetto e che mi servirà dopo).
marco.r
17-09-2007, 20:40
Rileggendolo l'unica cosa che potrei fare se volessi renderlo più leggibile è mettere la generator expression in una variabile:
Ops, ho visto dopo la correzione. Gia' meglio :p, anche metterei nella linea seguente anche il .next(). Trovo che chiamare un metodo su una lista/generatori creati cosi' riduca la leggibilita' perche' il contenuto a cui si applica lo trovi ad inizio riga, mentre il metodo alla fine.
Hai ragione da vendere pero' quando dici che la leggibilita' di un linguaggio non dipende da quanto e' leggibile a chi il linguaggio non lo conosce o lo conosce poco. In realta' sintassi simili possono pure generare confusione perche' chi legge qualcosa che sembra quello che conosce gia' pensa giustamente che il comportamento sia simile, e questo non e' necessariamente vero.
D'altra parte linguaggi diversi richiedono approcci e concetti diversi per cui anche le stesse cose (una sequenza) non vengono usate allo stesso modo ed e' naturale che vengano rappresentate in modo diverso.
A meno che non si intenda proprio rappresentare un concetto presente in un altro linguaggio e allora e' importante che la rassomiglianza sia sia estetica che di sostanza.
Per inciso e' proprio quello che succede con liste e generatori di python ,che rassomigliano alla definizione di insieme dellinguaggio matematico.
Per quel che riguarda l'if "a posteriori"... beh non piace neanche a me :D
Ops, ho visto dopo la correzione. Gia' meglio :p, anche metterei nella linea seguente anche il .next(). Trovo che chiamare un metodo su una lista/generatori creati cosi' riduca la leggibilita' perche' il contenuto a cui si applica lo trovi ad inizio riga, mentre il metodo alla fine.
Hai ragione da vendere pero' quando dici che la leggibilita' di un linguaggio non dipende da quanto e' leggibile a chi il linguaggio non lo conosce o lo conosce poco. In realta' sintassi simili possono pure generare confusione perche' chi legge qualcosa che sembra quello che conosce gia' pensa giustamente che il comportamento sia simile, e questo non e' necessariamente vero.
D'altra parte linguaggi diversi richiedono approcci e concetti diversi per cui anche le stesse cose (una sequenza) non vengono usate allo stesso modo ed e' naturale che vengano rappresentate in modo diverso.
A meno che non si intenda proprio rappresentare un concetto presente in un altro linguaggio e allora e' importante che la rassomiglianza sia sia estetica che di sostanza.
Per inciso e' proprio quello che succede con liste e generatori di python ,che rassomigliano alla definizione di insieme dellinguaggio matematico.
Per quel che riguarda l'if "a posteriori"... beh non piace neanche a me :D
marco.r
17-09-2007, 20:42
Oltre a queste soluzioni significherebbe rinunciare del tutto all'uso dei generatori, ma non mi aggrederebbe: li trovo troppo comodi e, almeno per me, anche leggibili (ho subito visibile quello che mi aspetto e che mi servirà dopo).
Risposto sopra. Mi piace di piu' l'ultima, anche se piu' lunga.
Risposto sopra. Mi piace di piu' l'ultima, anche se piu' lunga.
cdimauro
17-09-2007, 20:57
Un punto di vista interessante. Grazie per le osservazioni. :)
Una domanda al volo in merito all'if "a posteriori": la tua (non) preferenza vale anche per l'operatore ternario introdotto con Python 2.5 (di cui ho postato un esempio qualche messaggio fa)?
Una domanda al volo in merito all'if "a posteriori": la tua (non) preferenza vale anche per l'operatore ternario introdotto con Python 2.5 (di cui ho postato un esempio qualche messaggio fa)?
dupa
17-09-2007, 21:28
ma se linux è scritto in C e secondo voi non è performante come il C++, come mai il signor google usa linux sui suoi server? :confused:
cdimauro
17-09-2007, 21:44
Ti sei perso qualcosa leggendo questo thread: qui è stato detto che il C++ è ALMENO performante quanto il C, il che vuol dire che non è SEMPRE migliore, ma per lo meno uguale. Quindi considerando che del C è anche un superset, è senza dubbio preferibile al C.
Detto ciò, il signor Google sfrutta quello che offre il mercato, e avendo deciso di puntare su piattaforme Linux, è implicito l'uso del C come linguaggio.
Ma le prestazioni NON sono l'unica cosa che interessa al signor Google, visto che utilizza ampiamente Python nella sua piattaforma che, pur facendo uso della compilazione bytecode dei sorgenti, non può comunque raggiungere le stesse prestazioni di un linguaggio come il C.
Evidentemente alle prestazioni preferisce produttività e manutenibilità del codice. ;)
Detto ciò, il signor Google sfrutta quello che offre il mercato, e avendo deciso di puntare su piattaforme Linux, è implicito l'uso del C come linguaggio.
Ma le prestazioni NON sono l'unica cosa che interessa al signor Google, visto che utilizza ampiamente Python nella sua piattaforma che, pur facendo uso della compilazione bytecode dei sorgenti, non può comunque raggiungere le stesse prestazioni di un linguaggio come il C.
Evidentemente alle prestazioni preferisce produttività e manutenibilità del codice. ;)
thebol
17-09-2007, 22:04
ma se linux è scritto in C e secondo voi non è performante come il C++, come mai il signor google usa linux sui suoi server? :confused:
C è l'"unico" linguaggio che nn usano. Vanno avanti a C++, Java e Pyton.
imho usano linux perchè è free ed è molto customizzabile.
C è l'"unico" linguaggio che nn usano. Vanno avanti a C++, Java e Pyton.
imho usano linux perchè è free ed è molto customizzabile.
Mixmar
17-09-2007, 22:07
Detto ciò, il signor Google sfrutta quello che offre il mercato, e avendo deciso di puntare su piattaforme Linux, è implicito l'uso del C come linguaggio.
Poteva farlo anche in Java. :ciapet:
No, chiedo scusa per l'intervento stupido ed improduttivo, volevo solo agganciarmi ad uno dei tuoi posti cdimauro, per non essere accusato di O.T. selvaggio.
Volevo solo dire che una cosa che proprio non comprendo del Python, a cui tu attribuisci giustamente doti di maggiore leggibilità (e io giustamente divergo da questa opinione, perchè dalla discussione è emerso che la leggibilità è un fatto abbondantemente soggettivo), è il concetto di indentazione come elemento strutturale del linguaggio.
Voglio dire, nel mondo (della programmazione) "moderno" (sì, lo so, ormai non significa niente, ma chiudete un occhio ;) ), chiunque ha a disposizione uno straccio di IDE, o semplicemente di editor evoluto, che gli fa l'indentazione automatica del codice: perchè rendere i whitespace così importanti, quando nè nei linguaggi di markup, nè nei linguaggi funzionali, nè in tutti i linguaggi C-like hanno un altro significato se non quello di separare una parola dalla precedente quando non si abbiano a disposizione punti, punti e virgola, operatori, parentesi eccetera?
Scusa, ma non riesco proprio a farmelo piacere... Però ammetto che io non ho mai programmato in Python: la mia è solo una considerazione "a priori".
Poteva farlo anche in Java. :ciapet:
No, chiedo scusa per l'intervento stupido ed improduttivo, volevo solo agganciarmi ad uno dei tuoi posti cdimauro, per non essere accusato di O.T. selvaggio.
Volevo solo dire che una cosa che proprio non comprendo del Python, a cui tu attribuisci giustamente doti di maggiore leggibilità (e io giustamente divergo da questa opinione, perchè dalla discussione è emerso che la leggibilità è un fatto abbondantemente soggettivo), è il concetto di indentazione come elemento strutturale del linguaggio.
Voglio dire, nel mondo (della programmazione) "moderno" (sì, lo so, ormai non significa niente, ma chiudete un occhio ;) ), chiunque ha a disposizione uno straccio di IDE, o semplicemente di editor evoluto, che gli fa l'indentazione automatica del codice: perchè rendere i whitespace così importanti, quando nè nei linguaggi di markup, nè nei linguaggi funzionali, nè in tutti i linguaggi C-like hanno un altro significato se non quello di separare una parola dalla precedente quando non si abbiano a disposizione punti, punti e virgola, operatori, parentesi eccetera?
Scusa, ma non riesco proprio a farmelo piacere... Però ammetto che io non ho mai programmato in Python: la mia è solo una considerazione "a priori".
dupa
17-09-2007, 22:11
Ti sei perso qualcosa leggendo questo thread: qui è stato detto che il C++ è ALMENO performante quanto il C, il che vuol dire che non è SEMPRE migliore, ma per lo meno uguale. Quindi considerando che del C è anche un superset, è senza dubbio preferibile al C.
php è il "migliore" linguaggio per il web? dipende!
molti, soprattutto gli amanti dell'ingegneria del software, non si metterebbero mai a scriver una complessa applicazione web in php.
però se pensi alle applicazioni web maggiormente diffuse, son scritte in php.
se uno oggi partisse con un nuovo software opensource per gestire blog scritto con java, usando hibernate, spring, struts.. ecc. troverebbe forse pochi adepti pronti a dare una mano.
allo stesso modo ai tempi di linux probabilmente torvald sapeva programmare bene anche in c++, ma magari aveva trovato sorgenti già disponibili da cui attingere in c, probabilmente sapeva "bene" il c++ e "molto bene" il c.. e se avesse scelto di usar il c++ per scriver linux, magari avrebbe tagliato fuori tutti quei programmatori c, che hanno poi dato una mano per far diventare quel so quello che oggi è.
durante i corsi di ing. del software ti citano spesso vari linguaggi di programmazione orientata agli oggetti definiti molti e molti anni fa... peccato che oggi non li usa nessuno.
oppure, io son laureato, sviluppo in ambito java e guadagno molto meno di un mio ex compagno di classe diplomato che sviluppa in cobol.
in ogni caso usare strumenti complessi richiede le capacità di saperli usare alla grande e soprattutto quando in azienda ti arriva un nuovo dipendente a cui devi spiegare come funzionano gli strumenti che usi, un conto è spiegargli php.. un conto è spiegargli java, spring, struts, hibernate.. ecc.
Ciao
php è il "migliore" linguaggio per il web? dipende!
molti, soprattutto gli amanti dell'ingegneria del software, non si metterebbero mai a scriver una complessa applicazione web in php.
però se pensi alle applicazioni web maggiormente diffuse, son scritte in php.
se uno oggi partisse con un nuovo software opensource per gestire blog scritto con java, usando hibernate, spring, struts.. ecc. troverebbe forse pochi adepti pronti a dare una mano.
allo stesso modo ai tempi di linux probabilmente torvald sapeva programmare bene anche in c++, ma magari aveva trovato sorgenti già disponibili da cui attingere in c, probabilmente sapeva "bene" il c++ e "molto bene" il c.. e se avesse scelto di usar il c++ per scriver linux, magari avrebbe tagliato fuori tutti quei programmatori c, che hanno poi dato una mano per far diventare quel so quello che oggi è.
durante i corsi di ing. del software ti citano spesso vari linguaggi di programmazione orientata agli oggetti definiti molti e molti anni fa... peccato che oggi non li usa nessuno.
oppure, io son laureato, sviluppo in ambito java e guadagno molto meno di un mio ex compagno di classe diplomato che sviluppa in cobol.
in ogni caso usare strumenti complessi richiede le capacità di saperli usare alla grande e soprattutto quando in azienda ti arriva un nuovo dipendente a cui devi spiegare come funzionano gli strumenti che usi, un conto è spiegargli php.. un conto è spiegargli java, spring, struts, hibernate.. ecc.
Ciao
cdimauro
17-09-2007, 22:19
Poteva farlo anche in Java. :ciapet:
Quoto thebol. :D
No, chiedo scusa per l'intervento stupido ed improduttivo, volevo solo agganciarmi ad uno dei tuoi posti cdimauro, per non essere accusato di O.T. selvaggio.
Volevo solo dire che una cosa che proprio non comprendo del Python, a cui tu attribuisci giustamente doti di maggiore leggibilità (e io giustamente divergo da questa opinione, perchè dalla discussione è emerso che la leggibilità è un fatto abbondantemente soggettivo), è il concetto di indentazione come elemento strutturale del linguaggio.
Voglio dire, nel mondo (della programmazione) "moderno" (sì, lo so, ormai non significa niente, ma chiudete un occhio ;) ), chiunque ha a disposizione uno straccio di IDE, o semplicemente di editor evoluto, che gli fa l'indentazione automatica del codice: perchè rendere i whitespace così importanti, quando nè nei linguaggi di markup, nè nei linguaggi funzionali, nè in tutti i linguaggi C-like hanno un altro significato se non quello di separare una parola dalla precedente quando non si abbiano a disposizione punti, punti e virgola, operatori, parentesi eccetera?
Scusa, ma non riesco proprio a farmelo piacere... Però ammetto che io non ho mai programmato in Python: la mia è solo una considerazione "a priori".
Semplice: perché in questo modo sei obbligato a scrivere codice con un'indentazione omogenea, il che rende il sorgente più leggibile.
Hai presente sorgenti indentati a mo' di albero di natale o a dente di sega?
Ecco, con Python ciò non è possibile: l'indentazione cresce sempre di livello quando si apre un costrutto che preve un blocco, e torna ESATTAMENTE allo stesso livello quando viene chiuso.
Non ci sono blocchi con istruzioni aventi un'indentazione diversa (fanno eccezione le istruzioni che continuano sulle righe successive).
Detto ciò, Python è di un annetto più giovane di Java, e ai tempi IDE che realizzavano automaticamente l'indentazione del codice non ne ricordo. :p
D'altra parte il fatto che adesso esistano IDE con questa funzionalità non dovrebbe preoccupare nessuno che abbia intenzione di provare Python. ;)
Quoto thebol. :D
No, chiedo scusa per l'intervento stupido ed improduttivo, volevo solo agganciarmi ad uno dei tuoi posti cdimauro, per non essere accusato di O.T. selvaggio.
Volevo solo dire che una cosa che proprio non comprendo del Python, a cui tu attribuisci giustamente doti di maggiore leggibilità (e io giustamente divergo da questa opinione, perchè dalla discussione è emerso che la leggibilità è un fatto abbondantemente soggettivo), è il concetto di indentazione come elemento strutturale del linguaggio.
Voglio dire, nel mondo (della programmazione) "moderno" (sì, lo so, ormai non significa niente, ma chiudete un occhio ;) ), chiunque ha a disposizione uno straccio di IDE, o semplicemente di editor evoluto, che gli fa l'indentazione automatica del codice: perchè rendere i whitespace così importanti, quando nè nei linguaggi di markup, nè nei linguaggi funzionali, nè in tutti i linguaggi C-like hanno un altro significato se non quello di separare una parola dalla precedente quando non si abbiano a disposizione punti, punti e virgola, operatori, parentesi eccetera?
Scusa, ma non riesco proprio a farmelo piacere... Però ammetto che io non ho mai programmato in Python: la mia è solo una considerazione "a priori".
Semplice: perché in questo modo sei obbligato a scrivere codice con un'indentazione omogenea, il che rende il sorgente più leggibile.
Hai presente sorgenti indentati a mo' di albero di natale o a dente di sega?
Ecco, con Python ciò non è possibile: l'indentazione cresce sempre di livello quando si apre un costrutto che preve un blocco, e torna ESATTAMENTE allo stesso livello quando viene chiuso.
Non ci sono blocchi con istruzioni aventi un'indentazione diversa (fanno eccezione le istruzioni che continuano sulle righe successive).
Detto ciò, Python è di un annetto più giovane di Java, e ai tempi IDE che realizzavano automaticamente l'indentazione del codice non ne ricordo. :p
D'altra parte il fatto che adesso esistano IDE con questa funzionalità non dovrebbe preoccupare nessuno che abbia intenzione di provare Python. ;)
k0nt3
17-09-2007, 22:22
C è l'"unico" linguaggio che nn usano. Vanno avanti a C++, Java e Pyton.
imho usano linux perchè è free ed è molto customizzabile.
mi sa che ti sbagli.. hanno apportato una marea di patch al kernel di linux. penso proprio che hanno usato il C
Ti sei perso qualcosa leggendo questo thread: qui è stato detto che il C++ è ALMENO performante quanto il C, il che vuol dire che non è SEMPRE migliore, ma per lo meno uguale. Quindi considerando che del C è anche un superset, è senza dubbio preferibile al C.
a leggere il thread non mi pare proprio così evidente. il C++ ha una serie di difetti interminabile
imho usano linux perchè è free ed è molto customizzabile.
mi sa che ti sbagli.. hanno apportato una marea di patch al kernel di linux. penso proprio che hanno usato il C
Ti sei perso qualcosa leggendo questo thread: qui è stato detto che il C++ è ALMENO performante quanto il C, il che vuol dire che non è SEMPRE migliore, ma per lo meno uguale. Quindi considerando che del C è anche un superset, è senza dubbio preferibile al C.
a leggere il thread non mi pare proprio così evidente. il C++ ha una serie di difetti interminabile
cdimauro
17-09-2007, 22:27
php è il "migliore" linguaggio per il web? dipende!
molti, soprattutto gli amanti dell'ingegneria del software, non si metterebbero mai a scriver una complessa applicazione web in php.
però se pensi alle applicazioni web maggiormente diffuse, son scritte in php.
Su PHP i miei commenti qui si sono decisamente sprecati.
se uno oggi partisse con un nuovo software opensource per gestire blog scritto con java, usando hibernate, spring, struts.. ecc. troverebbe forse pochi adepti pronti a dare una mano.
Immagino.
allo stesso modo ai tempi di linux probabilmente torvald sapeva programmare bene anche in c++, ma magari aveva trovato sorgenti già disponibili da cui attingere in c, probabilmente sapeva "bene" il c++ e "molto bene" il c..
A giudicare dalle sue dichiarazioni è fuor di dubbio che sconosca il C++ (non sapeva nemmeno che fosse possibile ridefinire gli operatori di dis/allocazione della memoria).
e se avesse scelto di usar il c++ per scriver linux, magari avrebbe tagliato fuori tutti quei programmatori c, che hanno poi dato una mano per far diventare quel so quello che oggi è.
Avrebbero potuto imparare il C++.
durante i corsi di ing. del software ti citano spesso vari linguaggi di programmazione orientata agli oggetti definiti molti e molti anni fa... peccato che oggi non li usa nessuno.
E' un vero peccato infatti: alcuni sono molto interessanti (SmallTalk, ad esempio, che ha un approccio "originale").
oppure, io son laureato, sviluppo in ambito java e guadagno molto meno di un mio ex compagno di classe diplomato che sviluppa in cobol.
Capita.
in ogni caso usare strumenti complessi richiede le capacità di saperli usare alla grande e soprattutto quando in azienda ti arriva un nuovo dipendente a cui devi spiegare come funzionano gli strumenti che usi, un conto è spiegargli php.. un conto è spiegargli java, spring, struts, hibernate.. ecc.
Ciao
Appunto per questo sono l'unico che attualmente lavora in Python e fa uso di Ice e FireBird: tutti gli altri usano prevalentemente PHP (C lo usa una divisione dello staff), Apache (per implementare un sistema di API richiamabili da ogni macchina della piattaforma; un po' come sparare a una mosca con un cannone) e MySQL (4 e con MyISAM; il 5 con MyISAM lo usa soltanto uno per un particolare progetto).
E' un classico: gli strumenti che permettono di essere più produttivi sono i meno considerati. Vengono favorite le soluzioni consolidate / più usate e che conoscono cani & porci, come dicevo prima.
molti, soprattutto gli amanti dell'ingegneria del software, non si metterebbero mai a scriver una complessa applicazione web in php.
però se pensi alle applicazioni web maggiormente diffuse, son scritte in php.
Su PHP i miei commenti qui si sono decisamente sprecati.
se uno oggi partisse con un nuovo software opensource per gestire blog scritto con java, usando hibernate, spring, struts.. ecc. troverebbe forse pochi adepti pronti a dare una mano.
Immagino.
allo stesso modo ai tempi di linux probabilmente torvald sapeva programmare bene anche in c++, ma magari aveva trovato sorgenti già disponibili da cui attingere in c, probabilmente sapeva "bene" il c++ e "molto bene" il c..
A giudicare dalle sue dichiarazioni è fuor di dubbio che sconosca il C++ (non sapeva nemmeno che fosse possibile ridefinire gli operatori di dis/allocazione della memoria).
e se avesse scelto di usar il c++ per scriver linux, magari avrebbe tagliato fuori tutti quei programmatori c, che hanno poi dato una mano per far diventare quel so quello che oggi è.
Avrebbero potuto imparare il C++.
durante i corsi di ing. del software ti citano spesso vari linguaggi di programmazione orientata agli oggetti definiti molti e molti anni fa... peccato che oggi non li usa nessuno.
E' un vero peccato infatti: alcuni sono molto interessanti (SmallTalk, ad esempio, che ha un approccio "originale").
oppure, io son laureato, sviluppo in ambito java e guadagno molto meno di un mio ex compagno di classe diplomato che sviluppa in cobol.
Capita.
in ogni caso usare strumenti complessi richiede le capacità di saperli usare alla grande e soprattutto quando in azienda ti arriva un nuovo dipendente a cui devi spiegare come funzionano gli strumenti che usi, un conto è spiegargli php.. un conto è spiegargli java, spring, struts, hibernate.. ecc.
Ciao
Appunto per questo sono l'unico che attualmente lavora in Python e fa uso di Ice e FireBird: tutti gli altri usano prevalentemente PHP (C lo usa una divisione dello staff), Apache (per implementare un sistema di API richiamabili da ogni macchina della piattaforma; un po' come sparare a una mosca con un cannone) e MySQL (4 e con MyISAM; il 5 con MyISAM lo usa soltanto uno per un particolare progetto).
E' un classico: gli strumenti che permettono di essere più produttivi sono i meno considerati. Vengono favorite le soluzioni consolidate / più usate e che conoscono cani & porci, come dicevo prima.
cdimauro
17-09-2007, 22:31
mi sa che ti sbagli.. hanno apportato una marea di patch al kernel di linux. penso proprio che hanno usato il C
Direi: per forza! :D
a leggere il thread non mi pare proprio così evidente.
Proprio perché ne abbiamo già parlato è evidentissimo, sebbene a te non piaccia il discorso (e non si sa per quale motivo).
il C++ ha una serie di difetti interminabile
Il C ne ha di gran lunga di più, e anche di questo si è discusso.
E' oggettivo che il C++ sia un superset (in senso stretto) del C.
E' oggettivo che il C++ abbia almeno le stesse prestazioni del C con gli stessi costrutti.
Logica impone che il C++ debba essere migliore del C.
Se c'è qualcosa che non quadra nel ragionamento non hai che da farmelo sapere, ma con dei fatti possibilmente. ;)
P.S. Hai nuovamente sbagliato a quotare. :p
Direi: per forza! :D
a leggere il thread non mi pare proprio così evidente.
Proprio perché ne abbiamo già parlato è evidentissimo, sebbene a te non piaccia il discorso (e non si sa per quale motivo).
il C++ ha una serie di difetti interminabile
Il C ne ha di gran lunga di più, e anche di questo si è discusso.
E' oggettivo che il C++ sia un superset (in senso stretto) del C.
E' oggettivo che il C++ abbia almeno le stesse prestazioni del C con gli stessi costrutti.
Logica impone che il C++ debba essere migliore del C.
Se c'è qualcosa che non quadra nel ragionamento non hai che da farmelo sapere, ma con dei fatti possibilmente. ;)
P.S. Hai nuovamente sbagliato a quotare. :p
k0nt3
17-09-2007, 22:48
:doh: di nuovo!
comunque non ho nessuna voglia di far ripartire il discorso dall'inizio :fagiano: chi vuole se lo legge
comunque non ho nessuna voglia di far ripartire il discorso dall'inizio :fagiano: chi vuole se lo legge
cdimauro
17-09-2007, 22:56
Perfettamente d'accordo. :read: :Prrr:
marco.r
17-09-2007, 23:11
oppure, io son laureato, sviluppo in ambito java e guadagno molto meno di un mio ex compagno di classe diplomato che sviluppa in cobol.
Ed entrambi prendete meno di un imbianchino, ma piu' del mio (ormai ex) collega che ha deciso di guadagnare di meno pur di andare a lavorare per una ditta di videogiochi. Meno il lavoro e' attraente meno offerta c'é e, con le debite eccezioni, piu´ viene pagato.
Ed entrambi prendete meno di un imbianchino, ma piu' del mio (ormai ex) collega che ha deciso di guadagnare di meno pur di andare a lavorare per una ditta di videogiochi. Meno il lavoro e' attraente meno offerta c'é e, con le debite eccezioni, piu´ viene pagato.
atragon
17-09-2007, 23:57
oppure, io son laureato, sviluppo in ambito java e guadagno molto meno di un mio ex compagno di classe diplomato che sviluppa in cobol.
Non è un demerito tuo ma una semplice legge di mercato: oggi come oggi tutti saltano sul carro della modernità ma buona parte del mondo è rimasto indietro e, curiiosamente, è il mondo "che paga". Non so se sia il caso del tuo ex compagno ma bisogna ricordare che banche e assicurazioni hanno miliardi di righe di codice scritte in Cobol c'è sempre meno gente che sa fare manutenzione e il porting a qualche cosa di meglio costa tempo e denaro e allora "dai, lascia perdere, fallo girare così com'è basta" :rolleyes: Da un istituto cliente ci hanno messo 4 anni a migrare dei semplici programmi per la gestione di certe bollette da Cobol a C++ (da Vax a PC...)...
Non è un demerito tuo ma una semplice legge di mercato: oggi come oggi tutti saltano sul carro della modernità ma buona parte del mondo è rimasto indietro e, curiiosamente, è il mondo "che paga". Non so se sia il caso del tuo ex compagno ma bisogna ricordare che banche e assicurazioni hanno miliardi di righe di codice scritte in Cobol c'è sempre meno gente che sa fare manutenzione e il porting a qualche cosa di meglio costa tempo e denaro e allora "dai, lascia perdere, fallo girare così com'è basta" :rolleyes: Da un istituto cliente ci hanno messo 4 anni a migrare dei semplici programmi per la gestione di certe bollette da Cobol a C++ (da Vax a PC...)...
bist
18-09-2007, 03:28
Voglio dire, nel mondo (della programmazione) "moderno" (sì, lo so, ormai non significa niente, ma chiudete un occhio ;) ), chiunque ha a disposizione uno straccio di IDE, o semplicemente di editor evoluto, che gli fa l'indentazione automatica del codice: perchè rendere i whitespace così importanti, quando nè nei linguaggi di markup, nè nei linguaggi funzionali, nè in tutti i linguaggi C-like hanno un altro significato se non quello di separare una parola dalla precedente quando non si abbiano a disposizione punti, punti e virgola, operatori, parentesi eccetera?
Perché è più chiaro, sai che il codice sarà sempre e per forza identato in un certo modo, è più facile leggere il codice di altri. Inoltre ti risparmi qualche '{' e '}' (a questo punto però potevano togliere i ':' dopo certe parole chiave...).
a leggere il thread non mi pare proprio così evidente. il C++ ha una serie di difetti interminabile
E' vero, sono esattamente tutti quelli derivati dal C :D Ed è lo stesso motivo per cui C++ è un superset di C ma si legge meglio quando non viene usato come tale ;)
Perché è più chiaro, sai che il codice sarà sempre e per forza identato in un certo modo, è più facile leggere il codice di altri. Inoltre ti risparmi qualche '{' e '}' (a questo punto però potevano togliere i ':' dopo certe parole chiave...).
a leggere il thread non mi pare proprio così evidente. il C++ ha una serie di difetti interminabile
E' vero, sono esattamente tutti quelli derivati dal C :D Ed è lo stesso motivo per cui C++ è un superset di C ma si legge meglio quando non viene usato come tale ;)
thebol
18-09-2007, 07:54
mi sa che ti sbagli.. hanno apportato una marea di patch al kernel di linux. penso proprio che hanno usato il C
per patchare il SO, ok, non penso possano patcharlo o customizzarlo in c++(o le patch non entrerebbero mai sulla versione standard di linux). Ma per la produzione e sviluppo, non lo usano.
per patchare il SO, ok, non penso possano patcharlo o customizzarlo in c++(o le patch non entrerebbero mai sulla versione standard di linux). Ma per la produzione e sviluppo, non lo usano.
cdimauro
18-09-2007, 08:13
Lo credo bene: i tempi di sviluppo sarebbero decisamente più lunghi.
ERRATA CORRIGE: Python è di qualche anno più vecchio, e non più giovane, di Java. ;)
ERRATA CORRIGE: Python è di qualche anno più vecchio, e non più giovane, di Java. ;)
^TiGeRShArK^
18-09-2007, 09:13
se uno oggi partisse con un nuovo software opensource per gestire blog scritto con java, usando hibernate, spring, struts.. ecc. troverebbe forse pochi adepti pronti a dare una mano.
è assolutamente inutile dato che con rubyonrails ad esempio puoi creare davvvero un sito di gestione dei blog in 15 minuti come puoi vedere dalla dimostrazione in tempo reale sul sito :asd:
cmq tornando seri non ho capito cosa c'entri il tuo discorso sulla maggiore diffusione dei linguaggi che non è prova della loro bontà con quello ke diceva cesare che puoi praticamente sempre usare il C++ in tutte le situazioni in cui puoi usare il c :mbe:
è assolutamente inutile dato che con rubyonrails ad esempio puoi creare davvvero un sito di gestione dei blog in 15 minuti come puoi vedere dalla dimostrazione in tempo reale sul sito :asd:
cmq tornando seri non ho capito cosa c'entri il tuo discorso sulla maggiore diffusione dei linguaggi che non è prova della loro bontà con quello ke diceva cesare che puoi praticamente sempre usare il C++ in tutte le situazioni in cui puoi usare il c :mbe:
fek
18-09-2007, 10:40
Questa:
def StrToInt(s):
Bases = (('%', 2), ('&', 8), ('$', 16), ('0x', 16), ('0X', 16), ('', 10))
Choise = ((s[len(Prefix) : ], Base) for Prefix, Base in Bases if s.startswith(Prefix)).next())
return int(*Choise)
andrebbe meglio?
O questa:
def StrToInt(s):
Bases = (('%', 2), ('&', 8), ('$', 16), ('0x', 16), ('0X', 16), ('', 10))
Generator = ((s[len(Prefix) : ], Base) for Prefix, Base in Bases if s.startswith(Prefix))
Choise = Generator.next()
return int(*Choise)
?
Oltre a queste soluzioni significherebbe rinunciare del tutto all'uso dei generatori, ma non mi aggrederebbe: li trovo troppo comodi e, almeno per me, anche leggibili (ho subito visibile quello che mi aspetto e che mi servirà dopo).
Cesare, quel codice e' illeggibile, ti giuro che dandogli un'occhiata non capisco che stia succedendo :)
Fai un esperimento, fai leggere quel codice a qualcuno che non sa' programmare e domandagli se capisce piu' o meno quello che vuoi fare. Io lo faccio abbastanza spesso con gli artisti, gli faccio leggere il mio codice e se non lo capiscono lo cambio.
Ritornando all'argomento del topic, qualcuno mi puo' mostrare un qualche costrutto in C che un compilatore C++ non compilerebbe con la medesima efficienza, una volta corretti eventuali errori sintattici con parole chiave e cast?
def StrToInt(s):
Bases = (('%', 2), ('&', 8), ('$', 16), ('0x', 16), ('0X', 16), ('', 10))
Choise = ((s[len(Prefix) : ], Base) for Prefix, Base in Bases if s.startswith(Prefix)).next())
return int(*Choise)
andrebbe meglio?
O questa:
def StrToInt(s):
Bases = (('%', 2), ('&', 8), ('$', 16), ('0x', 16), ('0X', 16), ('', 10))
Generator = ((s[len(Prefix) : ], Base) for Prefix, Base in Bases if s.startswith(Prefix))
Choise = Generator.next()
return int(*Choise)
?
Oltre a queste soluzioni significherebbe rinunciare del tutto all'uso dei generatori, ma non mi aggrederebbe: li trovo troppo comodi e, almeno per me, anche leggibili (ho subito visibile quello che mi aspetto e che mi servirà dopo).
Cesare, quel codice e' illeggibile, ti giuro che dandogli un'occhiata non capisco che stia succedendo :)
Fai un esperimento, fai leggere quel codice a qualcuno che non sa' programmare e domandagli se capisce piu' o meno quello che vuoi fare. Io lo faccio abbastanza spesso con gli artisti, gli faccio leggere il mio codice e se non lo capiscono lo cambio.
Ritornando all'argomento del topic, qualcuno mi puo' mostrare un qualche costrutto in C che un compilatore C++ non compilerebbe con la medesima efficienza, una volta corretti eventuali errori sintattici con parole chiave e cast?
cdimauro
18-09-2007, 11:10
Cesare, quel codice e' illeggibile, ti giuro che dandogli un'occhiata non capisco che stia succedendo :)
Per renderlo più leggibile dovrei fare a meno della generator expression. :|
In sostanza tornare al vecchio for che scorre gli elementi, come riportava Dott.Wisem.
Ma le generator expression fanno parte del linguaggio: è chiaro che bisogna imparare a conoscerle (idem per lo slicing delle stringhe, che ho usato per eliminare il prefisso).
Non posso pretendere che chi non conosce Python sappia leggere quello che ho scritto, altrimenti dovrei usare il linguaggio "ai minimi termini" rinunciando a diversi costrutti.
Fai un esperimento, fai leggere quel codice a qualcuno che non sa' programmare e domandagli se capisce piu' o meno quello che vuoi fare. Io lo faccio abbastanza spesso con gli artisti, gli faccio leggere il mio codice e se non lo capiscono lo cambio.
:eek: Fai uso anche di template?
Ritornando all'argomento del topic, qualcuno mi puo' mostrare un qualche costrutto in C che un compilatore C++ non compilerebbe con la medesima efficienza, una volta corretti eventuali errori sintattici con parole chiave e cast?
100 a 1 che non riceverai nemmeno una risposta. :asd:
Per renderlo più leggibile dovrei fare a meno della generator expression. :|
In sostanza tornare al vecchio for che scorre gli elementi, come riportava Dott.Wisem.
Ma le generator expression fanno parte del linguaggio: è chiaro che bisogna imparare a conoscerle (idem per lo slicing delle stringhe, che ho usato per eliminare il prefisso).
Non posso pretendere che chi non conosce Python sappia leggere quello che ho scritto, altrimenti dovrei usare il linguaggio "ai minimi termini" rinunciando a diversi costrutti.
Fai un esperimento, fai leggere quel codice a qualcuno che non sa' programmare e domandagli se capisce piu' o meno quello che vuoi fare. Io lo faccio abbastanza spesso con gli artisti, gli faccio leggere il mio codice e se non lo capiscono lo cambio.
:eek: Fai uso anche di template?
Ritornando all'argomento del topic, qualcuno mi puo' mostrare un qualche costrutto in C che un compilatore C++ non compilerebbe con la medesima efficienza, una volta corretti eventuali errori sintattici con parole chiave e cast?
100 a 1 che non riceverai nemmeno una risposta. :asd:
cdimauro
18-09-2007, 11:31
Ai minimi termini continuando a usare la generator expression:
def StrToInt(s):
Bases = (('%', 2), ('&', 8), ('$', 16), ('0x', 16), ('0X', 16), ('', 10))
BaseInfosSelected = (Prefix, Base for Prefix, Base in Bases if s.startswith(Prefix))
Prefix, Base = BaseInfosSelected.next()
DigitsWithoutPrefix = s[len(Prefix) : ]
return int(DigitsWithoutPrefix, Base)
Dopo questa l'unica soluzione è NON usare la g.e.. :cry:
def StrToInt(s):
Bases = (('%', 2), ('&', 8), ('$', 16), ('0x', 16), ('0X', 16), ('', 10))
BaseInfosSelected = (Prefix, Base for Prefix, Base in Bases if s.startswith(Prefix))
Prefix, Base = BaseInfosSelected.next()
DigitsWithoutPrefix = s[len(Prefix) : ]
return int(DigitsWithoutPrefix, Base)
Dopo questa l'unica soluzione è NON usare la g.e.. :cry:
k0nt3
18-09-2007, 12:09
100 a 1 che non riceverai nemmeno una risposta. :asd:
ovvio! la domanda è sbagliata :D
ovvio! la domanda è sbagliata :D
cdimauro
18-09-2007, 12:28
E dove starebbe l'errore? Al contrario, a me sembra ben posta (come tra l'altro abbiamo già discusso). ;)
fek
18-09-2007, 15:52
Per renderlo più leggibile dovrei fare a meno della generator expression. :|
In sostanza tornare al vecchio for che scorre gli elementi, come riportava Dott.Wisem.
Ma le generator expression fanno parte del linguaggio: è chiaro che bisogna imparare a conoscerle (idem per lo slicing delle stringhe, che ho usato per eliminare il prefisso).
Non posso pretendere che chi non conosce Python sappia leggere quello che ho scritto, altrimenti dovrei usare il linguaggio "ai minimi termini" rinunciando a diversi costrutti.
Ma vedi, una feature di un linguaggio non va usata solo perche' e' li' a disposizione: se non c'e' un motivo chiaro che renda il codice piu' semplice e/o leggibile per usare una feature, semplicemente non si usa.
Rinunciare a uno o piu' costrutti per rendere il codice piu' leggibile e' decisamente una buona idea.
:eek: Fai uso anche di template?
Quando e' necessario e mi rende il codice piu' semplice si'. Quando mi rende il codice piu' complesso e illeggibile no.
100 a 1 che non riceverai nemmeno una risposta. :asd:
Perche' la risposta non c'e'. Non c'e' alcun costrutto in C che non possa essere compilato con la stessa efficienza da un compilatore C++. Programmare in C++ non vuol dire programmare per forza di cose ad oggetti.
Comunque, completamente OT, ho trovato oggi questo paper:
http://delivery.acm.org/10.1145/1230000/1227364/p145-stoecklin.pdf?key1=1227364&key2=2662210911&coll=GUIDE&dl=GUIDE&CFID=30174297&CFTOKEN=42836343
Le cose per fortuna stanno cambiando e dinosauri come Torvalds destinati a estinguersi.
In sostanza tornare al vecchio for che scorre gli elementi, come riportava Dott.Wisem.
Ma le generator expression fanno parte del linguaggio: è chiaro che bisogna imparare a conoscerle (idem per lo slicing delle stringhe, che ho usato per eliminare il prefisso).
Non posso pretendere che chi non conosce Python sappia leggere quello che ho scritto, altrimenti dovrei usare il linguaggio "ai minimi termini" rinunciando a diversi costrutti.
Ma vedi, una feature di un linguaggio non va usata solo perche' e' li' a disposizione: se non c'e' un motivo chiaro che renda il codice piu' semplice e/o leggibile per usare una feature, semplicemente non si usa.
Rinunciare a uno o piu' costrutti per rendere il codice piu' leggibile e' decisamente una buona idea.
:eek: Fai uso anche di template?
Quando e' necessario e mi rende il codice piu' semplice si'. Quando mi rende il codice piu' complesso e illeggibile no.
100 a 1 che non riceverai nemmeno una risposta. :asd:
Perche' la risposta non c'e'. Non c'e' alcun costrutto in C che non possa essere compilato con la stessa efficienza da un compilatore C++. Programmare in C++ non vuol dire programmare per forza di cose ad oggetti.
Comunque, completamente OT, ho trovato oggi questo paper:
http://delivery.acm.org/10.1145/1230000/1227364/p145-stoecklin.pdf?key1=1227364&key2=2662210911&coll=GUIDE&dl=GUIDE&CFID=30174297&CFTOKEN=42836343
Le cose per fortuna stanno cambiando e dinosauri come Torvalds destinati a estinguersi.
PGI-Bis
18-09-2007, 16:03
Mi viene da piangere. Portiamo la cultura pop nelle scuole così avremo una generazione di programmatori addestrati a farsi ancora meno domande dell'attuale. San Engelbart aiutaci tu.
cdimauro
18-09-2007, 16:18
Ma vedi, una feature di un linguaggio non va usata solo perche' e' li' a disposizione: se non c'e' un motivo chiaro che renda il codice piu' semplice e/o leggibile per usare una feature, semplicemente non si usa.
Rinunciare a uno o piu' costrutti per rendere il codice piu' leggibile e' decisamente una buona idea.
Quando e' necessario e mi rende il codice piu' semplice si'. Quando mi rende il codice piu' complesso e illeggibile no.
Chiaro. Forse dovrei rileggere il mio codice in maniera meno egoistica: quel che per me è ovvio / immediato ad altri a quanto pare non lo è affatto, e i (numerosi) messaggi che sono stati scritti in questo thread ne sono un'evidente dimostrazione.
Perche' la risposta non c'e'. Non c'e' alcun costrutto in C che non possa essere compilato con la stessa efficienza da un compilatore C++.
Tranne per quelli GNU. :asd:
Programmare in C++ non vuol dire programmare per forza di cose ad oggetti.
E' da un pezzo che lo ripeto: il C++ offre parecchi costrutti utili utili anche per altro.
Comunque, completamente OT, ho trovato oggi questo paper:
http://delivery.acm.org/10.1145/1230000/1227364/p145-stoecklin.pdf?key1=1227364&key2=2662210911&coll=GUIDE&dl=GUIDE&CFID=30174297&CFTOKEN=42836343
Interessante. Io dovrei migliorare qui:
"The learning objectives of Lesson One are to read code, review it for understandability, format and comment it according to supplied standards, use meaningful names, and test refactored code with functional testing. While making code selfdocumenting is not part of the refactoring process, students need these concepts to understand code and recognize needed refactoring."
:p
Però alla fine del documento sottolineano come sia una buona pratica quella di avere un rapporto del 30% circa fra righe di commento e righe totali del codice. Su questo non credo sarai d'accordo. :D
Le cose per fortuna stanno cambiando e dinosauri come Torvalds destinati a estinguersi.
Passerà molto tempo perché c'è troppa gente che viene plasmata e "forzata" a seguire le sue orme...
Rinunciare a uno o piu' costrutti per rendere il codice piu' leggibile e' decisamente una buona idea.
Quando e' necessario e mi rende il codice piu' semplice si'. Quando mi rende il codice piu' complesso e illeggibile no.
Chiaro. Forse dovrei rileggere il mio codice in maniera meno egoistica: quel che per me è ovvio / immediato ad altri a quanto pare non lo è affatto, e i (numerosi) messaggi che sono stati scritti in questo thread ne sono un'evidente dimostrazione.
Perche' la risposta non c'e'. Non c'e' alcun costrutto in C che non possa essere compilato con la stessa efficienza da un compilatore C++.
Tranne per quelli GNU. :asd:
Programmare in C++ non vuol dire programmare per forza di cose ad oggetti.
E' da un pezzo che lo ripeto: il C++ offre parecchi costrutti utili utili anche per altro.
Comunque, completamente OT, ho trovato oggi questo paper:
http://delivery.acm.org/10.1145/1230000/1227364/p145-stoecklin.pdf?key1=1227364&key2=2662210911&coll=GUIDE&dl=GUIDE&CFID=30174297&CFTOKEN=42836343
Interessante. Io dovrei migliorare qui:
"The learning objectives of Lesson One are to read code, review it for understandability, format and comment it according to supplied standards, use meaningful names, and test refactored code with functional testing. While making code selfdocumenting is not part of the refactoring process, students need these concepts to understand code and recognize needed refactoring."
:p
Però alla fine del documento sottolineano come sia una buona pratica quella di avere un rapporto del 30% circa fra righe di commento e righe totali del codice. Su questo non credo sarai d'accordo. :D
Le cose per fortuna stanno cambiando e dinosauri come Torvalds destinati a estinguersi.
Passerà molto tempo perché c'è troppa gente che viene plasmata e "forzata" a seguire le sue orme...
cdimauro
18-09-2007, 16:19
Mi viene da piangere. Portiamo la cultura pop nelle scuole così avremo una generazione di programmatori addestrati a farsi ancora meno domande dell'attuale. San Engelbart aiutaci tu.
Se ti riferisci al documento si parla di pratiche di buona programmazione.
Poi sappiamo tutti che non esiste la ricetta "teoricamente corretta" per lo sviluppo del codice. ;)
Se ti riferisci al documento si parla di pratiche di buona programmazione.
Poi sappiamo tutti che non esiste la ricetta "teoricamente corretta" per lo sviluppo del codice. ;)
PGI-Bis
18-09-2007, 16:41
Guarda, ti chiedo solo di leggerlo, insieme ai riferimenti bibliografici. Nulla di più. Se porto quel testo a mio nipote che ha due anni prende e mi dice "zio, questa roba è infondata".
cdimauro
18-09-2007, 16:49
Su queste cose è difficile trovare un fondamento (teorico). Si parla sempre di "best practices" e risultati empirici.
Che la programmazione a oggetti sia utile nello sviluppo di software robusto e manutenibile non l'ha dimostrato nessuno, eppure si tratta di un'opinione ampiamente condivisa (tranne da Torvalds e affini :D).
P.S. L'ho letto tutto ovviamente.
Che la programmazione a oggetti sia utile nello sviluppo di software robusto e manutenibile non l'ha dimostrato nessuno, eppure si tratta di un'opinione ampiamente condivisa (tranne da Torvalds e affini :D).
P.S. L'ho letto tutto ovviamente.
PGI-Bis
18-09-2007, 16:54
Ho visto che non ti è sfuggita la sottile incongruenza tra il self-documenting-code e la necessita di documentare il codice a latere.
Bizzarro, vero? Adesso guardiamo la bibliografia. Prendi "Using a Behavioral Theory of Program Comprehension". Cosa c'è di strano in quel testo?
Bizzarro, vero? Adesso guardiamo la bibliografia. Prendi "Using a Behavioral Theory of Program Comprehension". Cosa c'è di strano in quel testo?
fek
18-09-2007, 16:55
Guarda, ti chiedo solo di leggerlo, insieme ai riferimenti bibliografici. Nulla di più. Se porto quel testo a mio nipote che ha due anni prende e mi dice "zio, questa roba è infondata".
Quindi tuo nipote di due anni avra' piu' o meno la tua preparazione in materia.
Quindi tuo nipote di due anni avra' piu' o meno la tua preparazione in materia.
PGI-Bis
18-09-2007, 17:02
Ahh, piccato eh? :D Mio nipote è molto più intelligente di me. E' una questione generazionale. Credo. Forse lo dico per consolarmi.
Tu come spieghi la divergenza che ho segnalato riguardo ai commenti? Perchè non puoi non averla colta.
Tu come spieghi la divergenza che ho segnalato riguardo ai commenti? Perchè non puoi non averla colta.
k0nt3
18-09-2007, 17:05
E dove starebbe l'errore? Al contrario, a me sembra ben posta (come tra l'altro abbiamo già discusso). ;)
si da per scontato che se un linguaggio è un superset dell'altro allora è necessariamente migliore. beh questo è falso
si da per scontato che se un linguaggio è un superset dell'altro allora è necessariamente migliore. beh questo è falso
PGI-Bis
18-09-2007, 17:06
Allora, fek? Vuoi provare con un altro insulto?
fek
18-09-2007, 17:12
Allora, fek? Vuoi provare con un altro insulto?
Non ti toglierei mai il privilegio e l'onere. Mi limito ad affermare i fatti.
Non ti toglierei mai il privilegio e l'onere. Mi limito ad affermare i fatti.
cdimauro
18-09-2007, 17:12
si da per scontato che se un linguaggio è un superset dell'altro allora è necessariamente migliore. beh questo è falso
Ah, e per te non lo sarebbe? Quindi con un linguaggio io posso fare TUTTO quello che fa un altro linguaggio e qualcosa in più, e per te non sarebbe migliore?
Se la pensi così penso sia inutile continuare la discussione, perché la cosa si commenta da sé... :rolleyes:
Ah, e per te non lo sarebbe? Quindi con un linguaggio io posso fare TUTTO quello che fa un altro linguaggio e qualcosa in più, e per te non sarebbe migliore?
Se la pensi così penso sia inutile continuare la discussione, perché la cosa si commenta da sé... :rolleyes:
k0nt3
18-09-2007, 17:18
Ah, e per te non lo sarebbe? Quindi con un linguaggio io posso fare TUTTO quello che fa un altro linguaggio e qualcosa in più, e per te non sarebbe migliore?
Se la pensi così penso sia inutile continuare la discussione, perché la cosa si commenta da sé... :rolleyes:
quindi il miglior linguaggio in assoluto è quello che ammette ogni sequenza di caratteri dell'universo, nel linguaggio migliore una roba del genere avrebbe significato:
skdjvhfoewqvinqwvloqpjqwefoweihfjqoevniaeohcoqwjpvoevjpovfjwevnewhvoihwev
lo so che potreste non capire il senso del mio intervento ma sono sicuro che dopo qualche giorno di meditazione potrebbe essere più chiaro
Se la pensi così penso sia inutile continuare la discussione, perché la cosa si commenta da sé... :rolleyes:
quindi il miglior linguaggio in assoluto è quello che ammette ogni sequenza di caratteri dell'universo, nel linguaggio migliore una roba del genere avrebbe significato:
skdjvhfoewqvinqwvloqpjqwefoweihfjqoevniaeohcoqwjpvoevjpovfjwevnewhvoihwev
lo so che potreste non capire il senso del mio intervento ma sono sicuro che dopo qualche giorno di meditazione potrebbe essere più chiaro
PGI-Bis
18-09-2007, 17:26
Te lo dico io. Sulla parte della documentazione il testo subisce l'influenza del pregevole documento citato nella bibliografia e che io ho indicato a cidimauro. Leggendolo si nota come la teoria dell'autore spieghi l'acquisizione di consapevolezza del programmatore sul programma attraverso una successione di trasformazioni di prospettiva.
A questo punto chi abbia una infarinatura di orientamento agli oggetti si trova nell'imbarazzo di dover dire: ma queste trasformazioni di prospettiva non sussistono.
Siccome le persone che scrivono quel genere di testi sono tutto fuorchè impreparate la risposta deve essere cercata nel contesto storico in cui è stato prodotto quel documento. E, come per magia, si scopre che quel documento è del 1978. 1978 significa programmazione strutturata. L'orientamento agli oggetti allora era ancora una questione sperimentale.
E qui sta il punto. Beck può tentare la strada del codice auto-documentante perchè, in forza della sua esperienza nell'ambiente smalltalk, ha una consolidata visione OO della programmazione. Ha quella che si potrebbe chiamare accezione semantica dei dati.
Le due versioni, tanto percento e meno percento, non sono conciliabili: Fowler, 3, Comments. Vedi che ruolo minimale assumono i commenti? Extract Method, Rename Method, Introduce Assertion. Ci sono ben tre refactoring applicabili in sostituzione di un "cattivo" commento.
A questo punto chi abbia una infarinatura di orientamento agli oggetti si trova nell'imbarazzo di dover dire: ma queste trasformazioni di prospettiva non sussistono.
Siccome le persone che scrivono quel genere di testi sono tutto fuorchè impreparate la risposta deve essere cercata nel contesto storico in cui è stato prodotto quel documento. E, come per magia, si scopre che quel documento è del 1978. 1978 significa programmazione strutturata. L'orientamento agli oggetti allora era ancora una questione sperimentale.
E qui sta il punto. Beck può tentare la strada del codice auto-documentante perchè, in forza della sua esperienza nell'ambiente smalltalk, ha una consolidata visione OO della programmazione. Ha quella che si potrebbe chiamare accezione semantica dei dati.
Le due versioni, tanto percento e meno percento, non sono conciliabili: Fowler, 3, Comments. Vedi che ruolo minimale assumono i commenti? Extract Method, Rename Method, Introduce Assertion. Ci sono ben tre refactoring applicabili in sostituzione di un "cattivo" commento.
Dott.Wisem
18-09-2007, 19:57
Ah, e per te non lo sarebbe? Quindi con un linguaggio io posso fare TUTTO quello che fa un altro linguaggio e qualcosa in più, e per te non sarebbe migliore?
Se la pensi così penso sia inutile continuare la discussione, perché la cosa si commenta da sé... :rolleyes:Scusa, ma se io mi invento un linguaggio che è un superset del C, non significa necessariamente che abbia creato un linguaggio migliore, altrimenti SmallTalk, che possiede solo 6 keyword, dovrebbe essere di uno schifo esagerato... :D
Se la pensi così penso sia inutile continuare la discussione, perché la cosa si commenta da sé... :rolleyes:Scusa, ma se io mi invento un linguaggio che è un superset del C, non significa necessariamente che abbia creato un linguaggio migliore, altrimenti SmallTalk, che possiede solo 6 keyword, dovrebbe essere di uno schifo esagerato... :D
cdimauro
18-09-2007, 20:17
quindi il miglior linguaggio in assoluto è quello che ammette ogni sequenza di caratteri dell'universo, nel linguaggio migliore una roba del genere avrebbe significato:
skdjvhfoewqvinqwvloqpjqwefoweihfjqoevniaeohcoqwjpvoevjpovfjwevnewhvoihwev
lo so che potreste non capire il senso del mio intervento ma sono sicuro che dopo qualche giorno di meditazione potrebbe essere più chiaro
Scusa, ma se io mi invento un linguaggio che è un superset del C, non significa necessariamente che abbia creato un linguaggio migliore, altrimenti SmallTalk, che possiede solo 6 keyword, dovrebbe essere di uno schifo esagerato... :D
Mi sembra ovvio che le funzionalità aggiuntive non debbano essere banali, altrimenti basterebbe mettere nel linguaggio un altro modo per scrivere commenti e già avremmo un linguaggio "più ricco".
Rispondete a questa domanda: il C K&R è migliore del C99? E il Turbo Pascal 3.0 è migliore del 4.0? E così via: il concetto mi sembra ovvio.
skdjvhfoewqvinqwvloqpjqwefoweihfjqoevniaeohcoqwjpvoevjpovfjwevnewhvoihwev
lo so che potreste non capire il senso del mio intervento ma sono sicuro che dopo qualche giorno di meditazione potrebbe essere più chiaro
Scusa, ma se io mi invento un linguaggio che è un superset del C, non significa necessariamente che abbia creato un linguaggio migliore, altrimenti SmallTalk, che possiede solo 6 keyword, dovrebbe essere di uno schifo esagerato... :D
Mi sembra ovvio che le funzionalità aggiuntive non debbano essere banali, altrimenti basterebbe mettere nel linguaggio un altro modo per scrivere commenti e già avremmo un linguaggio "più ricco".
Rispondete a questa domanda: il C K&R è migliore del C99? E il Turbo Pascal 3.0 è migliore del 4.0? E così via: il concetto mi sembra ovvio.
cdimauro
18-09-2007, 20:21
Ho visto che non ti è sfuggita la sottile incongruenza tra il self-documenting-code e la necessita di documentare il codice a latere.
Bizzarro, vero? Adesso guardiamo la bibliografia. Prendi "Using a Behavioral Theory of Program Comprehension". Cosa c'è di strano in quel testo?
Non mi è sfuggita quell'incongruenza e sono stato io stesso a sollevarla, conoscendo anche il pensiero di Fran sull'argomento.
Come non mi è sfuggita l'utilità di un eccellente strumento qual è la rifattorizzazione, ad esempio.
Con ciò voglio dire che non si può certo buttare uno studio perché riporta ALCUNE cose che non ci quadrano.
Al solito, e come tu stesso hai sottolineato, il tutto va preso "cum grano salis".
Bizzarro, vero? Adesso guardiamo la bibliografia. Prendi "Using a Behavioral Theory of Program Comprehension". Cosa c'è di strano in quel testo?
Non mi è sfuggita quell'incongruenza e sono stato io stesso a sollevarla, conoscendo anche il pensiero di Fran sull'argomento.
Come non mi è sfuggita l'utilità di un eccellente strumento qual è la rifattorizzazione, ad esempio.
Con ciò voglio dire che non si può certo buttare uno studio perché riporta ALCUNE cose che non ci quadrano.
Al solito, e come tu stesso hai sottolineato, il tutto va preso "cum grano salis".
k0nt3
18-09-2007, 20:24
Mi sembra ovvio che le funzionalità aggiuntive non debbano essere banali, altrimenti basterebbe mettere nel linguaggio un altro modo per scrivere commenti e già avremmo un linguaggio "più ricco".
cosa è banale e cosa non lo è?
Rispondete a questa domanda: il C K&R è migliore del C99? E il Turbo Pascal 3.0 è migliore del 4.0? E così via: il concetto mi sembra ovvio.
e chi lo sa cosa è migliore.. dipende
hai una metrica per stabilire quale linguaggio è migliore per caso?
in generale sono portato a dire che il C99 è migliore del C K&R perchè ne è un affinamento e non uno stravolgimento, tuttavia non posso darti la certezza matematica perchè non ho le basi per farlo
cosa è banale e cosa non lo è?
Rispondete a questa domanda: il C K&R è migliore del C99? E il Turbo Pascal 3.0 è migliore del 4.0? E così via: il concetto mi sembra ovvio.
e chi lo sa cosa è migliore.. dipende
hai una metrica per stabilire quale linguaggio è migliore per caso?
in generale sono portato a dire che il C99 è migliore del C K&R perchè ne è un affinamento e non uno stravolgimento, tuttavia non posso darti la certezza matematica perchè non ho le basi per farlo
PGI-Bis
18-09-2007, 20:37
Con ciò voglio dire che non si può certo buttare uno studio perché riporta ALCUNE cose che non ci quadrano.
Al solito, e come tu stesso hai sottolineato, il tutto va preso "cum grano salis".
C'è un limite alle cose che puoi prendere cum grano salis. Là propongono un metodo di insegnamento del refactoring dove non una sola volta si accenna al motivo per cui lo studente dovrebbe applicare il refactoring. Non lo dicono nè nella prima parte, nè nella seconda. Neppure un breve accenno, en passant, tanto per farsi due risate. Niente. Molto formativo.
Al solito, e come tu stesso hai sottolineato, il tutto va preso "cum grano salis".
C'è un limite alle cose che puoi prendere cum grano salis. Là propongono un metodo di insegnamento del refactoring dove non una sola volta si accenna al motivo per cui lo studente dovrebbe applicare il refactoring. Non lo dicono nè nella prima parte, nè nella seconda. Neppure un breve accenno, en passant, tanto per farsi due risate. Niente. Molto formativo.
Dott.Wisem
18-09-2007, 20:48
Mi sembra ovvio che le funzionalità aggiuntive non debbano essere banali, altrimenti basterebbe mettere nel linguaggio un altro modo per scrivere commenti e già avremmo un linguaggio "più ricco".Non è una questione di aggiunte banali o sofisticate. Io potrei anche inserire una funzionalità molto sofisticata, ma dalla sintassi orripilante... In questo caso gran parte dei programmatori preferirebbero usare il vecchio linguaggio, pur con le sue limitazioni. Io, ad esempio, quella roba in Python che hai postato, proprio non riesco a farmela piacere... ;)
Mixmar
18-09-2007, 22:32
Riflessione quasi estemporanea: si potrebbe pensare di ordinare i linguaggi di programmazione usando come criterio il numero e il grado di involuzione di costrutti "fantasiosi", "potenti" (nel senso che esprimono, in modo non ambiguo e sintetico concetti (cioè, operazioni o sequenze di operazioni) complessi) e per questo motivo difficilmente leggibili "a prima vista" (anche se forse, con un po' di "syntax coloring"... :D ).
Dalla discussione risulterebbe che ad un estremo metteremmo l'assembly (in compagnia di Cobol e tanti altri amici), poi verrebbe Basic (almeno, le primissime versioni) con Fortran suo padre, poi C, quindi Pascal e/o C++ (non mi assalite, parlo da quasi-profano di entrambi! :D ) e via via, passando per Java. Per ora il primo è Python: se possiede altre cose così contorte, ma, devo ammettere così sintetiche, come la "generator expression" citata da cdimauro, senza dubbio ha il grado di "incasinatezza" (solo nel senso che gli ho appena dato! :) ) più elevato.
Tutto questo però, mi fa pensare una volta di più che questa caratteristica dei linguaggi sia comunque ortogonale alle caratteristiche forse più interessanti: potenzialità espressiva, riusabilità, "concisione"...
Dalla discussione risulterebbe che ad un estremo metteremmo l'assembly (in compagnia di Cobol e tanti altri amici), poi verrebbe Basic (almeno, le primissime versioni) con Fortran suo padre, poi C, quindi Pascal e/o C++ (non mi assalite, parlo da quasi-profano di entrambi! :D ) e via via, passando per Java. Per ora il primo è Python: se possiede altre cose così contorte, ma, devo ammettere così sintetiche, come la "generator expression" citata da cdimauro, senza dubbio ha il grado di "incasinatezza" (solo nel senso che gli ho appena dato! :) ) più elevato.
Tutto questo però, mi fa pensare una volta di più che questa caratteristica dei linguaggi sia comunque ortogonale alle caratteristiche forse più interessanti: potenzialità espressiva, riusabilità, "concisione"...
PGI-Bis
18-09-2007, 22:40
10 a 1 che adesso qualcuno salta fuori con brainfuck e whitespace :D
^TiGeRShArK^
18-09-2007, 23:16
Mi sembra ovvio che le funzionalità aggiuntive non debbano essere banali, altrimenti basterebbe mettere nel linguaggio un altro modo per scrivere commenti e già avremmo un linguaggio "più ricco".
Rispondete a questa domanda: il C K&R è migliore del C99? E il Turbo Pascal 3.0 è migliore del 4.0? E così via: il concetto mi sembra ovvio.
o, soprattutto, java 1.0 (brrr :eek: ) è migliore di java 6.0? :mbe:
Rispondete a questa domanda: il C K&R è migliore del C99? E il Turbo Pascal 3.0 è migliore del 4.0? E così via: il concetto mi sembra ovvio.
o, soprattutto, java 1.0 (brrr :eek: ) è migliore di java 6.0? :mbe:
PGI-Bis
18-09-2007, 23:32
Ecco, mi hai fatto venire il magone mi hai fatto... :cry: Java 1.0. Ragazzi che linguaggio era. Stupendo.
atragon
19-09-2007, 00:03
cosa è banale e cosa non lo è?
e chi lo sa cosa è migliore.. dipende
hai una metrica per stabilire quale linguaggio è migliore per caso?
in generale sono portato a dire che il C99 è migliore del C K&R perchè ne è un affinamento e non uno stravolgimento, tuttavia non posso darti la certezza matematica perchè non ho le basi per farlo
Si però dai ragionando così non si va da nessuna parte. Una metrica, di carattere assolutamente generale, esiste per valutare gli strumenti ed è l'ausilio che forniscono a chi lavora. Il progresso non ci fornisce strumenti perfetti ma strumenti di volta in volta migliori, il che non vuol dire che non abbiano controindicazioni a volte pesanti, ma che nel complesso hanno un computo positivo tra negatività e positività. Altrimenti si può contestare qualunque cosa, gli argomenti ci saranno sempre.
Nel caso specifico, perdonami ma ti parlo da utente che ha usato Delphi, C, C# e ora Ruby e che non ha mai digerito il C++, mi pare che le argomentazioni fornite a supporto del C++ nei confronti del C in questa discussione siano abbastanza semplici e condivisibili, parliamo, ripeto, del caso specifico
e chi lo sa cosa è migliore.. dipende
hai una metrica per stabilire quale linguaggio è migliore per caso?
in generale sono portato a dire che il C99 è migliore del C K&R perchè ne è un affinamento e non uno stravolgimento, tuttavia non posso darti la certezza matematica perchè non ho le basi per farlo
Si però dai ragionando così non si va da nessuna parte. Una metrica, di carattere assolutamente generale, esiste per valutare gli strumenti ed è l'ausilio che forniscono a chi lavora. Il progresso non ci fornisce strumenti perfetti ma strumenti di volta in volta migliori, il che non vuol dire che non abbiano controindicazioni a volte pesanti, ma che nel complesso hanno un computo positivo tra negatività e positività. Altrimenti si può contestare qualunque cosa, gli argomenti ci saranno sempre.
Nel caso specifico, perdonami ma ti parlo da utente che ha usato Delphi, C, C# e ora Ruby e che non ha mai digerito il C++, mi pare che le argomentazioni fornite a supporto del C++ nei confronti del C in questa discussione siano abbastanza semplici e condivisibili, parliamo, ripeto, del caso specifico
cdimauro
19-09-2007, 08:32
Perfettamente d'accordo, hai centrato il punto. :)
Hai citato Delphi, e se consideriamo l'evoluzione che ha avuto il Turbo Pascal possiamo a tutti gli effetti dire che ci troviamo di fronte a un linguaggio che ha subito degli enormi cambiamenti di cui i programmatori hanno ampiamente beneficiato.
Non ho conosciuto NESSUNO che si sia lamentato dell'introduzione delle unit nel TP 4.0 (e della possibilità di inserire codice assembly in linea, poter gestire interrupt, ecc.); nessuno che si sia lamentato dell'introduzione degli oggetti col TP 5.5, e così via.
Non possiamo buttare via il progresso soltanto per difendere l'indifendibile posizione di alcuni illustri trogloditi informatici che continuano a lavorare con la clava...
Hai citato Delphi, e se consideriamo l'evoluzione che ha avuto il Turbo Pascal possiamo a tutti gli effetti dire che ci troviamo di fronte a un linguaggio che ha subito degli enormi cambiamenti di cui i programmatori hanno ampiamente beneficiato.
Non ho conosciuto NESSUNO che si sia lamentato dell'introduzione delle unit nel TP 4.0 (e della possibilità di inserire codice assembly in linea, poter gestire interrupt, ecc.); nessuno che si sia lamentato dell'introduzione degli oggetti col TP 5.5, e così via.
Non possiamo buttare via il progresso soltanto per difendere l'indifendibile posizione di alcuni illustri trogloditi informatici che continuano a lavorare con la clava...
cdimauro
19-09-2007, 08:39
Non è una questione di aggiunte banali o sofisticate. Io potrei anche inserire una funzionalità molto sofisticata, ma dalla sintassi orripilante... In questo caso gran parte dei programmatori preferirebbero usare il vecchio linguaggio, pur con le sue limitazioni. Io, ad esempio, quella roba in Python che hai postato, proprio non riesco a farmela piacere... ;)
Per ora il primo è Python: se possiede altre cose così contorte, ma, devo ammettere così sintetiche, come la "generator expression" citata da cdimauro, senza dubbio ha il grado di "incasinatezza" (solo nel senso che gli ho appena dato! :) ) più elevato.
Non è che si può prendere UN esempio utilizzato da un power user per mettere alla berlina un costrutto molto utile come quello delle generator expression di Python.
Anzi, addirittura con un solo esempio di un solo costrutto si mette alla berlina un intero linguaggio (e il resto dove lo mettiamo? Gli avete dato almeno un'occhiata). :rolleyes:
Numeri = [1, 2, 3, 4, 5, 6]
print 'Numeri:', Numeri
Quadrati = (Numero ** 2 for Numero in Numeri)
print 'Quadrati: ',
for Quadrato in Quadrati:
print Quadrato,
print
Cubi = (Numero ** 3 for Numero in Numeri)
print 'Cubi: ',
for Cubo in Cubi:
print Cubo,
print
Adesso ditemi se anche quest'esempio è del tutto illegibile, pur facendo uso delle generator expression.
Al solito, vale la massima di cui sopra: le cose prendiamole "cum grano salis".
Per ora il primo è Python: se possiede altre cose così contorte, ma, devo ammettere così sintetiche, come la "generator expression" citata da cdimauro, senza dubbio ha il grado di "incasinatezza" (solo nel senso che gli ho appena dato! :) ) più elevato.
Non è che si può prendere UN esempio utilizzato da un power user per mettere alla berlina un costrutto molto utile come quello delle generator expression di Python.
Anzi, addirittura con un solo esempio di un solo costrutto si mette alla berlina un intero linguaggio (e il resto dove lo mettiamo? Gli avete dato almeno un'occhiata). :rolleyes:
Numeri = [1, 2, 3, 4, 5, 6]
print 'Numeri:', Numeri
Quadrati = (Numero ** 2 for Numero in Numeri)
print 'Quadrati: ',
for Quadrato in Quadrati:
print Quadrato,
Cubi = (Numero ** 3 for Numero in Numeri)
print 'Cubi: ',
for Cubo in Cubi:
print Cubo,
Adesso ditemi se anche quest'esempio è del tutto illegibile, pur facendo uso delle generator expression.
Al solito, vale la massima di cui sopra: le cose prendiamole "cum grano salis".
cdimauro
19-09-2007, 08:45
C'è un limite alle cose che puoi prendere cum grano salis. Là propongono un metodo di insegnamento del refactoring dove non una sola volta si accenna al motivo per cui lo studente dovrebbe applicare il refactoring. Non lo dicono nè nella prima parte, nè nella seconda. Neppure un breve accenno, en passant, tanto per farsi due risate. Niente. Molto formativo.
Allora abbiamo letto due documenti diversi, perché io noto questo già nell'abstract:
"Refactoring is the process of transforming the internal structure of existing code while keeping the integrity of the code’s functional requirements. Refactoring is proven to increase program maintainability, flexibility, and understandability and is recognized as a best practice in the software development community.
However, with the exception of courses or lectures on extreme programming, refactoring is overlooked in the computer science curriculum.
This paper presents the fourth lesson of an innovative pedagogical approach to teaching refactoring on the college level. This lesson covers the creation of well formed object-oriented methods including characteristics for evaluating such methods.
Through this hands-on approach, building well formed object-oriented methods through refactoring can be better
understood and integrated into the computer science curriculum."
già nell'introduzione.
Da notare anche la parte che ho sottolineato (e la frase seguente) che specifica chiaramente l'obiettivo del documento.
Allora abbiamo letto due documenti diversi, perché io noto questo già nell'abstract:
"Refactoring is the process of transforming the internal structure of existing code while keeping the integrity of the code’s functional requirements. Refactoring is proven to increase program maintainability, flexibility, and understandability and is recognized as a best practice in the software development community.
However, with the exception of courses or lectures on extreme programming, refactoring is overlooked in the computer science curriculum.
This paper presents the fourth lesson of an innovative pedagogical approach to teaching refactoring on the college level. This lesson covers the creation of well formed object-oriented methods including characteristics for evaluating such methods.
Through this hands-on approach, building well formed object-oriented methods through refactoring can be better
understood and integrated into the computer science curriculum."
già nell'introduzione.
Da notare anche la parte che ho sottolineato (e la frase seguente) che specifica chiaramente l'obiettivo del documento.
cdimauro
19-09-2007, 08:46
Ecco, mi hai fatto venire il magone mi hai fatto... :cry: Java 1.0. Ragazzi che linguaggio era. Stupendo.
Quindi non rimpiangeresti nulla, neppure "qualcosina" della versione 1.1 (di cui parlasti qualche tempo fa)? ;)
Quindi non rimpiangeresti nulla, neppure "qualcosina" della versione 1.1 (di cui parlasti qualche tempo fa)? ;)
^TiGeRShArK^
19-09-2007, 09:56
Ecco, mi hai fatto venire il magone mi hai fatto... :cry: Java 1.0. Ragazzi che linguaggio era. Stupendo.
peccato che fosse lento come una lumaca grassa e non potessi fare n-mila cose oltre alla specifica "aleatoria" di varie parti della JVM :p
zìzzì :O
davvero stupendo :O
:asd:
peccato che fosse lento come una lumaca grassa e non potessi fare n-mila cose oltre alla specifica "aleatoria" di varie parti della JVM :p
zìzzì :O
davvero stupendo :O
:asd:
^TiGeRShArK^
19-09-2007, 09:59
Quindi non rimpiangeresti nulla, neppure "qualcosina" della versione 1.1 (di cui parlasti qualche tempo fa)? ;)
Io non l'ho mai usato nella versione 1.0 ma devo dire ke dal poco ke ho visto in giro c'era davvero da essere masochisti ai tempi :asd:
Io non l'ho mai usato nella versione 1.0 ma devo dire ke dal poco ke ho visto in giro c'era davvero da essere masochisti ai tempi :asd:
cdimauro
19-09-2007, 10:24
Onestamente non ricordo la versione (Java ho iniziato a usarlo nel 1996 all'università, se non ricordo male), ma PGI tempo fa disse che c'era una caratteristica che gli piaceva e che era stata introdotta nella versione 1.1.
PGI-Bis
19-09-2007, 10:52
Dire "refactoring is proven" non conta moltissimo. Occorre che si dia questa prova. Il testo non la da ma, dato l'argomento, non è obbligato a darla nel testo. Quello di cui mi lamento, e penso sia più grave dell'incoerenza già esaminata, è la mancanza di un pur minimo accenno al fatto che agli studenti debba essere fornita questa prova. Funziona. Perchè? Fatti i ca..i tuoi! E' certamente innovativo.
Il Java del tempo che fu. Lo preferivo perchè aveva meno cose. Non è detto che sia un buon criterio in generale ma a me sembra che sia questa la ragione per cui lo guardo con nostalgia.
Ero incerto se dire 1.0 o 1.1, per via dei tipi interni introdotti dal secondo. Alla fine ho scelto di toglierli perchè la dichiarazione di un tipo interno (in particolare di un tipo locale e anonimo) non è esattamente liscia come l'olio. Mi riferisco, in particolare, all'intersezione tra spazi di nomi (della classe contenuta rispetto a quella continente) e alla pubblicazione occulta del riferimento this (dichiarare un tipo interno in un costruttore è una bad practice perchè implica il passaggio del riferimento this in un momento in cui l'oggetto potrebbe non essere pienamente inizializzato).
E' un beneficio sintattico il cui costo potrebbe non essere pienamente ammortizzato.
Occhio alla lentezza. Quando parlo di Java 1.0 parlo del linguaggio di programmazione Java 1.0. Per la piattaforma io scelgo la versione 6, per prestazioni, librerie e licenza.
Il Java del tempo che fu. Lo preferivo perchè aveva meno cose. Non è detto che sia un buon criterio in generale ma a me sembra che sia questa la ragione per cui lo guardo con nostalgia.
Ero incerto se dire 1.0 o 1.1, per via dei tipi interni introdotti dal secondo. Alla fine ho scelto di toglierli perchè la dichiarazione di un tipo interno (in particolare di un tipo locale e anonimo) non è esattamente liscia come l'olio. Mi riferisco, in particolare, all'intersezione tra spazi di nomi (della classe contenuta rispetto a quella continente) e alla pubblicazione occulta del riferimento this (dichiarare un tipo interno in un costruttore è una bad practice perchè implica il passaggio del riferimento this in un momento in cui l'oggetto potrebbe non essere pienamente inizializzato).
E' un beneficio sintattico il cui costo potrebbe non essere pienamente ammortizzato.
Occhio alla lentezza. Quando parlo di Java 1.0 parlo del linguaggio di programmazione Java 1.0. Per la piattaforma io scelgo la versione 6, per prestazioni, librerie e licenza.
^TiGeRShArK^
19-09-2007, 10:52
Onestamente non ricordo la versione (Java ho iniziato a usarlo nel 1996 all'università, se non ricordo male), ma PGI tempo fa disse che c'era una caratteristica che gli piaceva e che era stata introdotta nella versione 1.1.
da quello ke so io java 1.0 era una specie di beta del linguaggio...
In effetti si è andato stabilizzando da java 1.2 in poi, anche se per varie cose (Tipo il memory manager per poter avere la garanzia di gestire la concorrenza in maniera corretta) si è dovuto aspettare addirittura java 5.
da quello ke so io java 1.0 era una specie di beta del linguaggio...
In effetti si è andato stabilizzando da java 1.2 in poi, anche se per varie cose (Tipo il memory manager per poter avere la garanzia di gestire la concorrenza in maniera corretta) si è dovuto aspettare addirittura java 5.
^TiGeRShArK^
19-09-2007, 10:54
Dire "refactoring is proven" non conta moltissimo. Occorre che si dia questa prova. Il testo non la da ma, dato l'argomento, non è obbligato a darla nel testo. Quello di cui mi lamento, e penso sia più grave dell'incoerenza già esaminata, è la mancanza di un pur minimo accenno al fatto che agli studenti debba essere fornita questa prova. Funziona. Perchè? Fatti i ca..i tuoi! E' certamente innovativo.
Il Java del tempo che fu. Lo preferivo perchè aveva meno cose. Non è detto che sia un buon criterio in generale ma a me sembra che sia questa la ragione per cui lo guardo con nostalgia.
Ero incerto se dire 1.0 o 1.1, per via dei tipi interni introdotti dal secondo. Alla fine ho scelto di toglierli perchè la dichiarazione di un tipo interno (in particolare di un tipo locale e anonimo) non è esattamente liscia come l'olio. Mi riferisco, in particolare, all'intersezione tra spazi di nomi (della classe contenuta rispetto a quella continente) e alla pubblicazione occulta del riferimento this (dichiarare un tipo interno in un costruttore è una bad practice perchè implica il passaggio del riferimento this in un momento in cui l'oggetto potrebbe non essere pienamente inizializzato).
E' un beneficio sintattico il cui costo potrebbe non essere pienamente ammortizzato.
Occhio alla lentezza. Quando parlo di Java 1.0 parlo del linguaggio di programmazione Java 1.0. Per la piattaforma io scelgo la versione 6, per prestazioni, librerie e licenza.
ah ok..
io invece mi riferivo alla piattaforma xkè imho Java slegato dalla sua piattaforma non avrebbe alcun senso di esistere :p
EDIT: e tra l'altro ho appena scoperto ke la reflection è stata introdotta da java 1.1 :eek:
Il Java del tempo che fu. Lo preferivo perchè aveva meno cose. Non è detto che sia un buon criterio in generale ma a me sembra che sia questa la ragione per cui lo guardo con nostalgia.
Ero incerto se dire 1.0 o 1.1, per via dei tipi interni introdotti dal secondo. Alla fine ho scelto di toglierli perchè la dichiarazione di un tipo interno (in particolare di un tipo locale e anonimo) non è esattamente liscia come l'olio. Mi riferisco, in particolare, all'intersezione tra spazi di nomi (della classe contenuta rispetto a quella continente) e alla pubblicazione occulta del riferimento this (dichiarare un tipo interno in un costruttore è una bad practice perchè implica il passaggio del riferimento this in un momento in cui l'oggetto potrebbe non essere pienamente inizializzato).
E' un beneficio sintattico il cui costo potrebbe non essere pienamente ammortizzato.
Occhio alla lentezza. Quando parlo di Java 1.0 parlo del linguaggio di programmazione Java 1.0. Per la piattaforma io scelgo la versione 6, per prestazioni, librerie e licenza.
ah ok..
io invece mi riferivo alla piattaforma xkè imho Java slegato dalla sua piattaforma non avrebbe alcun senso di esistere :p
EDIT: e tra l'altro ho appena scoperto ke la reflection è stata introdotta da java 1.1 :eek:
k0nt3
19-09-2007, 11:15
Si però dai ragionando così non si va da nessuna parte. Una metrica, di carattere assolutamente generale, esiste per valutare gli strumenti ed è l'ausilio che forniscono a chi lavora. Il progresso non ci fornisce strumenti perfetti ma strumenti di volta in volta migliori, il che non vuol dire che non abbiano controindicazioni a volte pesanti, ma che nel complesso hanno un computo positivo tra negatività e positività. Altrimenti si può contestare qualunque cosa, gli argomenti ci saranno sempre.
Nel caso specifico, perdonami ma ti parlo da utente che ha usato Delphi, C, C# e ora Ruby e che non ha mai digerito il C++, mi pare che le argomentazioni fornite a supporto del C++ nei confronti del C in questa discussione siano abbastanza semplici e condivisibili, parliamo, ripeto, del caso specifico
no, una metrica di carattere generale non esiste, altrimenti sarebbe banale stabilire il linguaggio migliore.
il fatto è che la bontà di un linguaggio dipende da un'infinità di variabili spesso in contrasto tra di loro e non ortogonali come ha detto qualcuno poco più sopra.
come ho già detto da qualche parte in questo thread, per certe cose in cui non è necessaria la programmazione OO, il C rimane un gran bel linguaggio. se invece uno vuole programmare a oggetti il C++ è probabilmente la scelta peggiore.
il C++ ha il difetto di avere troppi modi per fare la stessa cosa, di essere eccessivamente complesso dal punto di vista del compilatore e altre cose che sono state sollevate in precedenza. per cui il C++ non è necessariamente migliore del C.
comunque sia anche parlando del C si può parlare di progresso perchè è uno standard che si è evoluto e si evolverà ancora probabilmente, ma non supporterà mai la programmazione OO, perchè non è il suo obiettivo. se vuoi programmare a oggetti usi un altro linguaggio.
e sono daccordo che la programmazione a oggetti è utile nella maggiorparte dei casi, ma non in tutti i casi.
dipende è la parola giusta. leggendo il documento linkato in precedenza mi vengono i brividi: un metodo non deve essere più lungo di 10 righe ecc.. mah
Nel caso specifico, perdonami ma ti parlo da utente che ha usato Delphi, C, C# e ora Ruby e che non ha mai digerito il C++, mi pare che le argomentazioni fornite a supporto del C++ nei confronti del C in questa discussione siano abbastanza semplici e condivisibili, parliamo, ripeto, del caso specifico
no, una metrica di carattere generale non esiste, altrimenti sarebbe banale stabilire il linguaggio migliore.
il fatto è che la bontà di un linguaggio dipende da un'infinità di variabili spesso in contrasto tra di loro e non ortogonali come ha detto qualcuno poco più sopra.
come ho già detto da qualche parte in questo thread, per certe cose in cui non è necessaria la programmazione OO, il C rimane un gran bel linguaggio. se invece uno vuole programmare a oggetti il C++ è probabilmente la scelta peggiore.
il C++ ha il difetto di avere troppi modi per fare la stessa cosa, di essere eccessivamente complesso dal punto di vista del compilatore e altre cose che sono state sollevate in precedenza. per cui il C++ non è necessariamente migliore del C.
comunque sia anche parlando del C si può parlare di progresso perchè è uno standard che si è evoluto e si evolverà ancora probabilmente, ma non supporterà mai la programmazione OO, perchè non è il suo obiettivo. se vuoi programmare a oggetti usi un altro linguaggio.
e sono daccordo che la programmazione a oggetti è utile nella maggiorparte dei casi, ma non in tutti i casi.
dipende è la parola giusta. leggendo il documento linkato in precedenza mi vengono i brividi: un metodo non deve essere più lungo di 10 righe ecc.. mah
k0nt3
19-09-2007, 11:44
Numeri = [1, 2, 3, 4, 5, 6]
print 'Numeri:', Numeri
Quadrati = (Numero ** 2 for Numero in Numeri)
print 'Quadrati: ',
for Quadrato in Quadrati:
print Quadrato,
print
Cubi = (Numero ** 3 for Numero in Numeri)
print 'Cubi: ',
for Cubo in Cubi:
print Cubo,
print
Adesso ditemi se anche quest'esempio è del tutto illegibile, pur facendo uso delle generator expression.
Al solito, vale la massima di cui sopra: le cose prendiamole "cum grano salis".
io che ho una conoscenza superficiale di python non riesco a capire esattamente cosa succede in quel codice.. dovrei studiarmi ste generator expression.
queste caratteristiche del python mi fanno credere che rimarrà sempre confinato allo scripting & Co ma sarà anche una mia opinione
print 'Numeri:', Numeri
Quadrati = (Numero ** 2 for Numero in Numeri)
print 'Quadrati: ',
for Quadrato in Quadrati:
print Quadrato,
Cubi = (Numero ** 3 for Numero in Numeri)
print 'Cubi: ',
for Cubo in Cubi:
print Cubo,
Adesso ditemi se anche quest'esempio è del tutto illegibile, pur facendo uso delle generator expression.
Al solito, vale la massima di cui sopra: le cose prendiamole "cum grano salis".
io che ho una conoscenza superficiale di python non riesco a capire esattamente cosa succede in quel codice.. dovrei studiarmi ste generator expression.
queste caratteristiche del python mi fanno credere che rimarrà sempre confinato allo scripting & Co ma sarà anche una mia opinione
cionci
19-09-2007, 11:51
No...dai...quello si capisce perfettamente, e non ho letto mai un sorgente Python. La cosa più complessa è ** per l'elevazione a potenza :sofico:
k0nt3
19-09-2007, 11:52
No...dai...quello si capisce perfettamente, e non ho letto mai un sorgente Python. La cosa più complessa è ** per l'elevazione a potenza :sofico:
ah era l'elevamento a potenza! :eek: provo a rileggerlo allora :fagiano:
EDIT: e come volevasi dimostrare ora l'ho capito :O
anche se il for alla fine della riga è un pò come la notazione polacca inversa
ah era l'elevamento a potenza! :eek: provo a rileggerlo allora :fagiano:
EDIT: e come volevasi dimostrare ora l'ho capito :O
anche se il for alla fine della riga è un pò come la notazione polacca inversa
cionci
19-09-2007, 11:57
EDIT: e come volevasi dimostrare ora l'ho capito :O
anche se il for alla fine della riga è un pò come la notazione polacca inversa
Perché sei abituato a metterlo prima, ma se lo leggi in italiano:
Eleva Numero al cubo per (ogni) Numero all'interno di Numeri.
Ci avrei visto meglio un foreach al posto del for...
anche se il for alla fine della riga è un pò come la notazione polacca inversa
Perché sei abituato a metterlo prima, ma se lo leggi in italiano:
Eleva Numero al cubo per (ogni) Numero all'interno di Numeri.
Ci avrei visto meglio un foreach al posto del for...
k0nt3
19-09-2007, 11:59
Perché sei abituato a metterlo prima, ma se lo leggi in italiano:
Eleva Numero al cubo per (ogni) Numero all'interno di Numeri.
Ci avrei visto meglio un foreach al posto del for...
perchè.. "per ogni Numero all'interno di Numeri eleva Numero al cubo" non è italiano? :fagiano:
la differenza è che prima definisci cos'è Numero e poi lo usi, mentre con il for alla fine è un pò più complicato da capire al volo (magari in questo caso semplice non si nota)
ma probabilmente è abitudine eh :)
Eleva Numero al cubo per (ogni) Numero all'interno di Numeri.
Ci avrei visto meglio un foreach al posto del for...
perchè.. "per ogni Numero all'interno di Numeri eleva Numero al cubo" non è italiano? :fagiano:
la differenza è che prima definisci cos'è Numero e poi lo usi, mentre con il for alla fine è un pò più complicato da capire al volo (magari in questo caso semplice non si nota)
ma probabilmente è abitudine eh :)
cionci
19-09-2007, 12:02
perchè.. "per ogni Numero all'interno di Numeri eleva Numero al cubo" non è italiano? :fagiano:
Certo...io intendevo che visto che sei abituato a mettere il for prima vedendolo lì non riesci a renderti conto che se preso il codice e semplicemente letto torna anche in quel modo.
Certo...io intendevo che visto che sei abituato a mettere il for prima vedendolo lì non riesci a renderti conto che se preso il codice e semplicemente letto torna anche in quel modo.
^TiGeRShArK^
19-09-2007, 12:10
leggendo il documento linkato in precedenza mi vengono i brividi: un metodo non deve essere più lungo di 10 righe ecc.. mah
I brividi? :mbe:
e allora se vedessi metodi di oltre mille righe di codice sui cui ci ho dovuto mettere le mani e non si capiva oggettivamente una mazza ke faresti? :asd:
I brividi? :mbe:
e allora se vedessi metodi di oltre mille righe di codice sui cui ci ho dovuto mettere le mani e non si capiva oggettivamente una mazza ke faresti? :asd:
k0nt3
19-09-2007, 12:21
I brividi? :mbe:
e allora se vedessi metodi di oltre mille righe di codice sui cui ci ho dovuto mettere le mani e non si capiva oggettivamente una mazza ke faresti? :asd:
mi è già capitato grazie :D ho deciso di smettere
il problema non è nel preferire i metodi corti, ma nel porre un limite quantitativo IMHO. 10 è un numero come un altro.. magari una volta è meglio 15 e un'altra 7, chissenefrega di contare le righe, basta usare la testa
e allora se vedessi metodi di oltre mille righe di codice sui cui ci ho dovuto mettere le mani e non si capiva oggettivamente una mazza ke faresti? :asd:
mi è già capitato grazie :D ho deciso di smettere
il problema non è nel preferire i metodi corti, ma nel porre un limite quantitativo IMHO. 10 è un numero come un altro.. magari una volta è meglio 15 e un'altra 7, chissenefrega di contare le righe, basta usare la testa
cionci
19-09-2007, 12:21
I brividi? :mbe:
e allora se vedessi metodi di oltre mille righe di codice sui cui ci ho dovuto mettere le mani e non si capiva oggettivamente una mazza ke faresti? :asd:
Ora...sulle 10 sarei leggermente più flessibile...arriverei a 15 (in un linguaggio non OO anche a più righe).
e allora se vedessi metodi di oltre mille righe di codice sui cui ci ho dovuto mettere le mani e non si capiva oggettivamente una mazza ke faresti? :asd:
Ora...sulle 10 sarei leggermente più flessibile...arriverei a 15 (in un linguaggio non OO anche a più righe).
^TiGeRShArK^
19-09-2007, 12:33
Ora...sulle 10 sarei leggermente più flessibile...arriverei a 15 (in un linguaggio non OO anche a più righe).
io + che a righe di codice mi regolo a dimensione sullo schermo :p
non le ho mai contate le righe per vedere se un metodo rispettava certi standard...
certo che metodi corti e autoesplicativi sono indubbiamente preferibili :p
Ruby ad esempio per ora l'ho sempre usato come linguaggio di scripting dato che il programma + lungo che ho scritto era di 70 righe di codice... e non avevo tanta fantasia di mettermi a creare oggetti e cose varie visto che entrava quasi tutto in una schermata :p
io + che a righe di codice mi regolo a dimensione sullo schermo :p
non le ho mai contate le righe per vedere se un metodo rispettava certi standard...
certo che metodi corti e autoesplicativi sono indubbiamente preferibili :p
Ruby ad esempio per ora l'ho sempre usato come linguaggio di scripting dato che il programma + lungo che ho scritto era di 70 righe di codice... e non avevo tanta fantasia di mettermi a creare oggetti e cose varie visto che entrava quasi tutto in una schermata :p
The3DProgrammer
19-09-2007, 12:42
solo io nn riesco a scaricare quello stramaledetto documento?:muro:
cdimauro
19-09-2007, 12:53
Dire "refactoring is proven" non conta moltissimo. Occorre che si dia questa prova. Il testo non la da ma, dato l'argomento, non è obbligato a darla nel testo. Quello di cui mi lamento, e penso sia più grave dell'incoerenza già esaminata, è la mancanza di un pur minimo accenno al fatto che agli studenti debba essere fornita questa prova. Funziona. Perchè? Fatti i ca..i tuoi! E' certamente innovativo.
Ne abbiamo già parlato: si tratta di studi di carattere puramente empirico, come lo sono anche i documenti di IBM e HP che sono stati postati.
Il Java del tempo che fu. Lo preferivo perchè aveva meno cose. Non è detto che sia un buon criterio in generale ma a me sembra che sia questa la ragione per cui lo guardo con nostalgia.
Ero incerto se dire 1.0 o 1.1, per via dei tipi interni introdotti dal secondo. Alla fine ho scelto di toglierli perchè la dichiarazione di un tipo interno (in particolare di un tipo locale e anonimo) non è esattamente liscia come l'olio. Mi riferisco, in particolare, all'intersezione tra spazi di nomi (della classe contenuta rispetto a quella continente) e alla pubblicazione occulta del riferimento this (dichiarare un tipo interno in un costruttore è una bad practice perchè implica il passaggio del riferimento this in un momento in cui l'oggetto potrebbe non essere pienamente inizializzato).
E' un beneficio sintattico il cui costo potrebbe non essere pienamente ammortizzato.
Non conosco i tipi interni (o magari li ho usati ma non so che si chiamano così :D), per cui mi fermo qui.
Occhio alla lentezza. Quando parlo di Java 1.0 parlo del linguaggio di programmazione Java 1.0. Per la piattaforma io scelgo la versione 6, per prestazioni, librerie e licenza.
Chiaro.
Ne abbiamo già parlato: si tratta di studi di carattere puramente empirico, come lo sono anche i documenti di IBM e HP che sono stati postati.
Il Java del tempo che fu. Lo preferivo perchè aveva meno cose. Non è detto che sia un buon criterio in generale ma a me sembra che sia questa la ragione per cui lo guardo con nostalgia.
Ero incerto se dire 1.0 o 1.1, per via dei tipi interni introdotti dal secondo. Alla fine ho scelto di toglierli perchè la dichiarazione di un tipo interno (in particolare di un tipo locale e anonimo) non è esattamente liscia come l'olio. Mi riferisco, in particolare, all'intersezione tra spazi di nomi (della classe contenuta rispetto a quella continente) e alla pubblicazione occulta del riferimento this (dichiarare un tipo interno in un costruttore è una bad practice perchè implica il passaggio del riferimento this in un momento in cui l'oggetto potrebbe non essere pienamente inizializzato).
E' un beneficio sintattico il cui costo potrebbe non essere pienamente ammortizzato.
Non conosco i tipi interni (o magari li ho usati ma non so che si chiamano così :D), per cui mi fermo qui.
Occhio alla lentezza. Quando parlo di Java 1.0 parlo del linguaggio di programmazione Java 1.0. Per la piattaforma io scelgo la versione 6, per prestazioni, librerie e licenza.
Chiaro.
cdimauro
19-09-2007, 12:54
da quello ke so io java 1.0 era una specie di beta del linguaggio...
In effetti si è andato stabilizzando da java 1.2 in poi, anche se per varie cose (Tipo il memory manager per poter avere la garanzia di gestire la concorrenza in maniera corretta) si è dovuto aspettare addirittura java 5.
Ma il memory manager non riguarda strettamente il linguaggio (come sintassi) o sbaglio?
In effetti si è andato stabilizzando da java 1.2 in poi, anche se per varie cose (Tipo il memory manager per poter avere la garanzia di gestire la concorrenza in maniera corretta) si è dovuto aspettare addirittura java 5.
Ma il memory manager non riguarda strettamente il linguaggio (come sintassi) o sbaglio?
cdimauro
19-09-2007, 12:55
ah ok..
io invece mi riferivo alla piattaforma xkè imho Java slegato dalla sua piattaforma non avrebbe alcun senso di esistere :p
EDIT: e tra l'altro ho appena scoperto ke la reflection è stata introdotta da java 1.1 :eek:
Senza reflection non ci sono né Junit né i test automatizzati con Ant. :muro:
io invece mi riferivo alla piattaforma xkè imho Java slegato dalla sua piattaforma non avrebbe alcun senso di esistere :p
EDIT: e tra l'altro ho appena scoperto ke la reflection è stata introdotta da java 1.1 :eek:
Senza reflection non ci sono né Junit né i test automatizzati con Ant. :muro:
bist
19-09-2007, 13:04
io + che a righe di codice mi regolo a dimensione sullo schermo :p
Anch'io.
http://img204.imageshack.us/img204/4250/notepadppzc7.th.jpg (http://img204.imageshack.us/my.php?image=notepadppzc7.jpg)
Anch'io.
http://img204.imageshack.us/img204/4250/notepadppzc7.th.jpg (http://img204.imageshack.us/my.php?image=notepadppzc7.jpg)
cdimauro
19-09-2007, 13:11
no, una metrica di carattere generale non esiste, altrimenti sarebbe banale stabilire il linguaggio migliore.
Questa è una ovvia: non esiste nemmeno una metrica per la complessità del codice, figuriamoci quella sulla "bontà" di un linguaggio. :p
il fatto è che la bontà di un linguaggio dipende da un'infinità di variabili spesso in contrasto tra di loro e non ortogonali come ha detto qualcuno poco più sopra.
Dovremmo fidarci del buon senso dettato dall'esperienza, infatti.
come ho già detto da qualche parte in questo thread, per certe cose in cui non è necessaria la programmazione OO, il C rimane un gran bel linguaggio. se invece uno vuole programmare a oggetti il C++ è probabilmente la scelta peggiore.
Condivido, ma il mio giudizio è dettato strettamente da una questione di gusti (per programmare a oggetti IO preferisco ben altro).
il C++ ha il difetto di avere troppi modi per fare la stessa cosa,
Tipo la dichiarazione delle classi? Sì, sicuramente. Ma a parte questo non so cos'altro ci sarebbe di PERL-ish (leggi: "more ways to do the same thing" :D).
di essere eccessivamente complesso dal punto di vista del compilatore e altre cose che sono state sollevate in precedenza. per cui il C++ non è necessariamente migliore del C.
Non credo che il compilatore sia più complesso di quello di altri linguaggi, come anche il D, ad esempio.
Quanto al migliore, beh, anche togliendo le classi il C++ rimane sempre migliore del C: offre tanti costrutti in più, e non hanno nemmeno una sintassi contorta (a parte i template forse, ma qui, al solito, si va sui gusti personali).
comunque sia anche parlando del C si può parlare di progresso perchè è uno standard che si è evoluto e si evolverà ancora probabilmente, ma non supporterà mai la programmazione OO, perchè non è il suo obiettivo. se vuoi programmare a oggetti usi un altro linguaggio.
Opinione personale, come dicevo sopra.
e sono daccordo che la programmazione a oggetti è utile nella maggiorparte dei casi, ma non in tutti i casi.
Ovvio. Sempre per il famoso "cum grano salis" con cui si dovrebbero fare le cose.
dipende è la parola giusta. leggendo il documento linkato in precedenza mi vengono i brividi: un metodo non deve essere più lungo di 10 righe ecc.. mah
Anche a me fa storcere il naso: mi sembra troppo poco. Un senso, comunque, ce l'ha: più è lungo un metodo, più saranno le sue "responsabilità" e quindi più sarà elevata la possibilità che vengano introdotti bug.
Questa è una ovvia: non esiste nemmeno una metrica per la complessità del codice, figuriamoci quella sulla "bontà" di un linguaggio. :p
il fatto è che la bontà di un linguaggio dipende da un'infinità di variabili spesso in contrasto tra di loro e non ortogonali come ha detto qualcuno poco più sopra.
Dovremmo fidarci del buon senso dettato dall'esperienza, infatti.
come ho già detto da qualche parte in questo thread, per certe cose in cui non è necessaria la programmazione OO, il C rimane un gran bel linguaggio. se invece uno vuole programmare a oggetti il C++ è probabilmente la scelta peggiore.
Condivido, ma il mio giudizio è dettato strettamente da una questione di gusti (per programmare a oggetti IO preferisco ben altro).
il C++ ha il difetto di avere troppi modi per fare la stessa cosa,
Tipo la dichiarazione delle classi? Sì, sicuramente. Ma a parte questo non so cos'altro ci sarebbe di PERL-ish (leggi: "more ways to do the same thing" :D).
di essere eccessivamente complesso dal punto di vista del compilatore e altre cose che sono state sollevate in precedenza. per cui il C++ non è necessariamente migliore del C.
Non credo che il compilatore sia più complesso di quello di altri linguaggi, come anche il D, ad esempio.
Quanto al migliore, beh, anche togliendo le classi il C++ rimane sempre migliore del C: offre tanti costrutti in più, e non hanno nemmeno una sintassi contorta (a parte i template forse, ma qui, al solito, si va sui gusti personali).
comunque sia anche parlando del C si può parlare di progresso perchè è uno standard che si è evoluto e si evolverà ancora probabilmente, ma non supporterà mai la programmazione OO, perchè non è il suo obiettivo. se vuoi programmare a oggetti usi un altro linguaggio.
Opinione personale, come dicevo sopra.
e sono daccordo che la programmazione a oggetti è utile nella maggiorparte dei casi, ma non in tutti i casi.
Ovvio. Sempre per il famoso "cum grano salis" con cui si dovrebbero fare le cose.
dipende è la parola giusta. leggendo il documento linkato in precedenza mi vengono i brividi: un metodo non deve essere più lungo di 10 righe ecc.. mah
Anche a me fa storcere il naso: mi sembra troppo poco. Un senso, comunque, ce l'ha: più è lungo un metodo, più saranno le sue "responsabilità" e quindi più sarà elevata la possibilità che vengano introdotti bug.
PGI-Bis
19-09-2007, 13:15
Che sia empirico può anche andar bene. Quello che non va tanto bene e che conoscendone l'empiricità si dica poi "prova che". L'esperimento non può provare. Può solo confutare. E' una della grandi conquiste del sapere moderno. Buttiamola nel water.
Il modello di memoria riguarda il linguaggio, se non altro per il fatto che esso è presente come parte delle specifiche. Credo che la necessità che esso sia specificato derivi dall'essere java "concorrente", nel senso che prevede espressamente un certo numero di forme dedicate alla gestione di flussi di esecuzione paralleli.
I tipi interni sono... i tipi interni. Li conosci sicuramente. Ti sarà capitato di scrivere:
Runnable task = new Runnable() {
public void run() { ...bingo... }
};
O di dichiarare una classe, un'interfaccia o un enumerativo dentro ad un'altra classe o interfaccia. E' un tipo interno: sta dentro a un altro tipo. Non ci sono solo in Java. Impossibile non approfittarne. E' una carotona nuda dallo sguardo lascivo che ti fa le boccucce. Richiede che siano introdotte un bel po' di regole. Trattandosi di una comodità sintattica bisognerebbe vedere se il gioco valga la candela. Sinceramente sono incerto sulla mia opinione al riguardo. Un po' sì e un po' no. Viviamo di certezze.
Trovo molto interessante l'approccio "visuale" alle dimensioni di un metodo.
Il modello di memoria riguarda il linguaggio, se non altro per il fatto che esso è presente come parte delle specifiche. Credo che la necessità che esso sia specificato derivi dall'essere java "concorrente", nel senso che prevede espressamente un certo numero di forme dedicate alla gestione di flussi di esecuzione paralleli.
I tipi interni sono... i tipi interni. Li conosci sicuramente. Ti sarà capitato di scrivere:
Runnable task = new Runnable() {
public void run() { ...bingo... }
};
O di dichiarare una classe, un'interfaccia o un enumerativo dentro ad un'altra classe o interfaccia. E' un tipo interno: sta dentro a un altro tipo. Non ci sono solo in Java. Impossibile non approfittarne. E' una carotona nuda dallo sguardo lascivo che ti fa le boccucce. Richiede che siano introdotte un bel po' di regole. Trattandosi di una comodità sintattica bisognerebbe vedere se il gioco valga la candela. Sinceramente sono incerto sulla mia opinione al riguardo. Un po' sì e un po' no. Viviamo di certezze.
Trovo molto interessante l'approccio "visuale" alle dimensioni di un metodo.
cdimauro
19-09-2007, 13:17
io che ho una conoscenza superficiale di python non riesco a capire esattamente cosa succede in quel codice.. dovrei studiarmi ste generator expression.
queste caratteristiche del python mi fanno credere che rimarrà sempre confinato allo scripting & Co ma sarà anche una mia opinione
No...dai...quello si capisce perfettamente, e non ho letto mai un sorgente Python. La cosa più complessa è ** per l'elevazione a potenza :sofico:
ah era l'elevamento a potenza! :eek: provo a rileggerlo allora :fagiano:
EDIT: e come volevasi dimostrare ora l'ho capito :O
anche se il for alla fine della riga è un pò come la notazione polacca inversa
Perché sei abituato a metterlo prima, ma se lo leggi in italiano:
Eleva Numero al cubo per (ogni) Numero all'interno di Numeri.
Ci avrei visto meglio un foreach al posto del for...
Ero tentato di usare x * x al posto di x ** 2, perché qualcuno poteva non conoscere o arrivare al significato dell'operatore di elevazione a potenza di Python (che, comunque, è lo stesso del Fortran e di altri linguaggi, se non ricordo male), e proprio per questo ho preferito aggiungere il codice dei "cubi" oltre a quello dei "quadrati", in modo che confrontando i due pezzi di codice e i nomi usati dalle variabili fosse facile risalire in ogni caso al significato dell'operazione, ma è bastato. :p
Quanto al for che scorre gli elementi, meglio del "foreach" sarebbe stato meglio un "for each", ma mantenendo sempre la presenza dell'operatore "in".
Comunque son dettagli: dal for si può sempre uscire, per cui l'eventuale each perderebbe di significato. :D
queste caratteristiche del python mi fanno credere che rimarrà sempre confinato allo scripting & Co ma sarà anche una mia opinione
No...dai...quello si capisce perfettamente, e non ho letto mai un sorgente Python. La cosa più complessa è ** per l'elevazione a potenza :sofico:
ah era l'elevamento a potenza! :eek: provo a rileggerlo allora :fagiano:
EDIT: e come volevasi dimostrare ora l'ho capito :O
anche se il for alla fine della riga è un pò come la notazione polacca inversa
Perché sei abituato a metterlo prima, ma se lo leggi in italiano:
Eleva Numero al cubo per (ogni) Numero all'interno di Numeri.
Ci avrei visto meglio un foreach al posto del for...
Ero tentato di usare x * x al posto di x ** 2, perché qualcuno poteva non conoscere o arrivare al significato dell'operatore di elevazione a potenza di Python (che, comunque, è lo stesso del Fortran e di altri linguaggi, se non ricordo male), e proprio per questo ho preferito aggiungere il codice dei "cubi" oltre a quello dei "quadrati", in modo che confrontando i due pezzi di codice e i nomi usati dalle variabili fosse facile risalire in ogni caso al significato dell'operazione, ma è bastato. :p
Quanto al for che scorre gli elementi, meglio del "foreach" sarebbe stato meglio un "for each", ma mantenendo sempre la presenza dell'operatore "in".
Comunque son dettagli: dal for si può sempre uscire, per cui l'eventuale each perderebbe di significato. :D
cdimauro
19-09-2007, 13:19
perchè.. "per ogni Numero all'interno di Numeri eleva Numero al cubo" non è italiano? :fagiano:
la differenza è che prima definisci cos'è Numero e poi lo usi, mentre con il for alla fine è un pò più complicato da capire al volo (magari in questo caso semplice non si nota)
ma probabilmente è abitudine eh :)
Certo...io intendevo che visto che sei abituato a mettere il for prima vedendolo lì non riesci a renderti conto che se preso il codice e semplicemente letto torna anche in quel modo.
Esattamente: è soltanto una questione d'abitudine, ma io il codice preferisco leggerlo e mi sembra che si legga ugualmente bene pur non conoscendo Python come linguaggio. ;)
P.S. Al resto rispondo dopo pranzo. :D
la differenza è che prima definisci cos'è Numero e poi lo usi, mentre con il for alla fine è un pò più complicato da capire al volo (magari in questo caso semplice non si nota)
ma probabilmente è abitudine eh :)
Certo...io intendevo che visto che sei abituato a mettere il for prima vedendolo lì non riesci a renderti conto che se preso il codice e semplicemente letto torna anche in quel modo.
Esattamente: è soltanto una questione d'abitudine, ma io il codice preferisco leggerlo e mi sembra che si legga ugualmente bene pur non conoscendo Python come linguaggio. ;)
P.S. Al resto rispondo dopo pranzo. :D
k0nt3
19-09-2007, 13:45
Questa è una ovvia: non esiste nemmeno una metrica per la complessità del codice, figuriamoci quella sulla "bontà" di un linguaggio. :p
Dovremmo fidarci del buon senso dettato dall'esperienza, infatti.
pensavo fosse ovvio.. ma dalle risposte non sembrava :p
si può cercare di stabilire il linguaggio migliore per fare una determinata cosa, ma non il linguaggio migliore in generale.
Condivido, ma il mio giudizio è dettato strettamente da una questione di gusti (per programmare a oggetti IO preferisco ben altro).
Tipo la dichiarazione delle classi? Sì, sicuramente. Ma a parte questo non so cos'altro ci sarebbe di PERL-ish (leggi: "more ways to do the same thing" :D).
il C++ supporta molti stili e paradigmi di programmazione che si sovrappongono tra loro e questo è il male. per fare un altro esempio banale non ho mai capito cos'è quel pugno in un occhio del cin e cout, non ci azzecca niente con il resto del linguaggio IMHO
Non credo che il compilatore sia più complesso di quello di altri linguaggi, come anche il D, ad esempio.
su questo argomento non penso che io e te possiamo portare fatti a dimostrazione delle nostre tesi.. io tendo a fidarmi di quello che scrive il creatore del D su questo argomento, perchè perlomeno ha molta esperienza in fatto di compilatori
Quanto al migliore, beh, anche togliendo le classi il C++ rimane sempre migliore del C: offre tanti costrutti in più, e non hanno nemmeno una sintassi contorta (a parte i template forse, ma qui, al solito, si va sui gusti personali).
vabbè il C++ senza classi non è il C++..
Anche a me fa storcere il naso: mi sembra troppo poco. Un senso, comunque, ce l'ha: più è lungo un metodo, più saranno le sue "responsabilità" e quindi più sarà elevata la possibilità che vengano introdotti bug.
ma questo si sapeva molto molto tempo prima che arrivassero i programmatori estremi a portare la luce :asd:
anzi ti dirò che sforzarsi a stare in un determinato numero di righe può essere dannoso.. molto meglio affidarsi al caro vecchio Buon Senso™
Dovremmo fidarci del buon senso dettato dall'esperienza, infatti.
pensavo fosse ovvio.. ma dalle risposte non sembrava :p
si può cercare di stabilire il linguaggio migliore per fare una determinata cosa, ma non il linguaggio migliore in generale.
Condivido, ma il mio giudizio è dettato strettamente da una questione di gusti (per programmare a oggetti IO preferisco ben altro).
Tipo la dichiarazione delle classi? Sì, sicuramente. Ma a parte questo non so cos'altro ci sarebbe di PERL-ish (leggi: "more ways to do the same thing" :D).
il C++ supporta molti stili e paradigmi di programmazione che si sovrappongono tra loro e questo è il male. per fare un altro esempio banale non ho mai capito cos'è quel pugno in un occhio del cin e cout, non ci azzecca niente con il resto del linguaggio IMHO
Non credo che il compilatore sia più complesso di quello di altri linguaggi, come anche il D, ad esempio.
su questo argomento non penso che io e te possiamo portare fatti a dimostrazione delle nostre tesi.. io tendo a fidarmi di quello che scrive il creatore del D su questo argomento, perchè perlomeno ha molta esperienza in fatto di compilatori
Quanto al migliore, beh, anche togliendo le classi il C++ rimane sempre migliore del C: offre tanti costrutti in più, e non hanno nemmeno una sintassi contorta (a parte i template forse, ma qui, al solito, si va sui gusti personali).
vabbè il C++ senza classi non è il C++..
Anche a me fa storcere il naso: mi sembra troppo poco. Un senso, comunque, ce l'ha: più è lungo un metodo, più saranno le sue "responsabilità" e quindi più sarà elevata la possibilità che vengano introdotti bug.
ma questo si sapeva molto molto tempo prima che arrivassero i programmatori estremi a portare la luce :asd:
anzi ti dirò che sforzarsi a stare in un determinato numero di righe può essere dannoso.. molto meglio affidarsi al caro vecchio Buon Senso™
^TiGeRShArK^
19-09-2007, 13:45
Anch'io.
http://img204.imageshack.us/img204/4250/notepadppzc7.th.jpg (http://img204.imageshack.us/my.php?image=notepadppzc7.jpg)
intendevo con caratteri normalei :stordita:
sul fisso lavoro a 1280X1024 con caratteri normali e sul portatile a 1400 X 1040 però con caratteri + grandi... ma la dimensione è circa uguale...
Certo ke se metti font di grandezza 48 non ti entra una mazza in una schermata :asd:
http://img204.imageshack.us/img204/4250/notepadppzc7.th.jpg (http://img204.imageshack.us/my.php?image=notepadppzc7.jpg)
intendevo con caratteri normalei :stordita:
sul fisso lavoro a 1280X1024 con caratteri normali e sul portatile a 1400 X 1040 però con caratteri + grandi... ma la dimensione è circa uguale...
Certo ke se metti font di grandezza 48 non ti entra una mazza in una schermata :asd:
cdimauro
19-09-2007, 13:47
Che sia empirico può anche andar bene. Quello che non va tanto bene e che conoscendone l'empiricità si dica poi "prova che". L'esperimento non può provare. Può solo confutare. E' una della grandi conquiste del sapere moderno. Buttiamola nel water.
Onestamente tempo per andare a controllare anche la bibliografia non ne ho.
I tipi interni sono... i tipi interni. Li conosci sicuramente. Ti sarà capitato di scrivere:
Runnable task = new Runnable() {
public void run() { ...bingo... }
};
No, così non m'è mai capitato. Sono fermo a
Runnable task = new Runnable();
O di dichiarare una classe, un'interfaccia o un enumerativo dentro ad un'altra classe o interfaccia. E' un tipo interno: sta dentro a un altro tipo. Non ci sono solo in Java. Impossibile non approfittarne. E' una carotona nuda dallo sguardo lascivo che ti fa le boccucce. Richiede che siano introdotte un bel po' di regole. Trattandosi di una comodità sintattica bisognerebbe vedere se il gioco valga la candela. Sinceramente sono incerto sulla mia opinione al riguardo. Un po' sì e un po' no. Viviamo di certezze.
Sì, di dichiarare tipi dentro un'altra classe / interfaccia m'è capitato e onestamente lo trovo utile. In Delphi è stata introdotta soltanto di recente, ma è una caratteristica che aspettavo da tempo.
La trovo molto utile in particolare per nascondere i dettagli interni di una classe (o interfaccia): se, tanto per fare un esempio, mi serve un array di interi, perché lo devo dichiarare all'esterno per poi usarlo soltanto all'interno della classe?
Questo mi ha sempre costretto a dichiarare i tipi che mi servivano nella parte "pubblica" della unit (o package in Java), quando non era assolutamente necessario.
Trovo molto interessante l'approccio "visuale" alle dimensioni di un metodo.
Idem. Ma dipende dal monitor e dalla GUI che usi: io ho la tendenza a scrivere linee più lunghe (l'avrete notato :D) proprio perché "vedo che c'è ancora spazio".
Onestamente tempo per andare a controllare anche la bibliografia non ne ho.
I tipi interni sono... i tipi interni. Li conosci sicuramente. Ti sarà capitato di scrivere:
Runnable task = new Runnable() {
public void run() { ...bingo... }
};
No, così non m'è mai capitato. Sono fermo a
Runnable task = new Runnable();
O di dichiarare una classe, un'interfaccia o un enumerativo dentro ad un'altra classe o interfaccia. E' un tipo interno: sta dentro a un altro tipo. Non ci sono solo in Java. Impossibile non approfittarne. E' una carotona nuda dallo sguardo lascivo che ti fa le boccucce. Richiede che siano introdotte un bel po' di regole. Trattandosi di una comodità sintattica bisognerebbe vedere se il gioco valga la candela. Sinceramente sono incerto sulla mia opinione al riguardo. Un po' sì e un po' no. Viviamo di certezze.
Sì, di dichiarare tipi dentro un'altra classe / interfaccia m'è capitato e onestamente lo trovo utile. In Delphi è stata introdotta soltanto di recente, ma è una caratteristica che aspettavo da tempo.
La trovo molto utile in particolare per nascondere i dettagli interni di una classe (o interfaccia): se, tanto per fare un esempio, mi serve un array di interi, perché lo devo dichiarare all'esterno per poi usarlo soltanto all'interno della classe?
Questo mi ha sempre costretto a dichiarare i tipi che mi servivano nella parte "pubblica" della unit (o package in Java), quando non era assolutamente necessario.
Trovo molto interessante l'approccio "visuale" alle dimensioni di un metodo.
Idem. Ma dipende dal monitor e dalla GUI che usi: io ho la tendenza a scrivere linee più lunghe (l'avrete notato :D) proprio perché "vedo che c'è ancora spazio".
^TiGeRShArK^
19-09-2007, 13:48
I tipi interni sono... i tipi interni. Li conosci sicuramente.
anch'io all'inizio non avevo capito perfettamente cosa intendevi per "tipi interni" :stordita:
solo pensandoci un pò m'è venuto in mente che non è altro che la traduzione italiana di "inner classes" :asd:
Onestamente in italiano è la prima volta che lo vedo scritto :fagiano:
anch'io all'inizio non avevo capito perfettamente cosa intendevi per "tipi interni" :stordita:
solo pensandoci un pò m'è venuto in mente che non è altro che la traduzione italiana di "inner classes" :asd:
Onestamente in italiano è la prima volta che lo vedo scritto :fagiano:
bist
19-09-2007, 13:58
Un mio prof le traduceva come 'classi innestate'. Non so cosa suoni peggio : )
cdimauro
19-09-2007, 14:02
pensavo fosse ovvio.. ma dalle risposte non sembrava :p
si può cercare di stabilire il linguaggio migliore per fare una determinata cosa, ma non il linguaggio migliore in generale.
No, in generale no. Sui singoli casi è possibile discutere e magari arrivarci, come stiamo cercando di fare, appunto.
il C++ supporta molti stili e paradigmi di programmazione che si sovrappongono tra loro e questo è il male.
Il male è l'uso che ne fa. Se tu dovessi usare ESCLUSIVAMENTE la programmazione a oggetti, ti assicuro che preferisti impiccarti. :asd:
Ne parlammo sempre in questo forum con PGI-Bis, che espose in che modo sarebbe stato necessario, ad esempio, istanziare una stringa: da suicidio (e non scherzo :D).
per fare un altro esempio banale non ho mai capito cos'è quel pugno in un occhio del cin e cout, non ci azzecca niente con il resto del linguaggio IMHO
E' semplicemente una banale applicazione dell'overloading degli operatori: né più né meno. Se non ti piacciono puoi non usarli, e in ogni caso puoi ridefinirteli come ti pare (cosa che in C non puoi fare).
su questo argomento non penso che io e te possiamo portare fatti a dimostrazione delle nostre tesi.. io tendo a fidarmi di quello che scrive il creatore del D su questo argomento, perchè perlomeno ha molta esperienza in fatto di compilatori
Ho anch'io esperienza, sebbene per uso personale, e mi sono posto non poche volte il problema di realizzarne con linguaggi come C++, Delphi, Java, ecc. Onestamente tutta questa complessità non la vedo.
vabbè il C++ senza classi non è il C++..
E' un suo sottoinsieme che rimane comunque un superset del C. Poi, ripeto, se non le si vuole usare non c'è problema, ma intanto ci sono.
ma questo si sapeva molto molto tempo prima che arrivassero i programmatori estremi a portare la luce :asd:
anzi ti dirò che sforzarsi a stare in un determinato numero di righe può essere dannoso.. molto meglio affidarsi al caro vecchio Buon Senso™
Certamente, ma questi studi sono comunque comodi perché ti permettono di analizzare il diverso grado d'incidenza dei bug (es: certe "prassi" sono più dannose di altre). Sempre a livello sperimentale, eh!
si può cercare di stabilire il linguaggio migliore per fare una determinata cosa, ma non il linguaggio migliore in generale.
No, in generale no. Sui singoli casi è possibile discutere e magari arrivarci, come stiamo cercando di fare, appunto.
il C++ supporta molti stili e paradigmi di programmazione che si sovrappongono tra loro e questo è il male.
Il male è l'uso che ne fa. Se tu dovessi usare ESCLUSIVAMENTE la programmazione a oggetti, ti assicuro che preferisti impiccarti. :asd:
Ne parlammo sempre in questo forum con PGI-Bis, che espose in che modo sarebbe stato necessario, ad esempio, istanziare una stringa: da suicidio (e non scherzo :D).
per fare un altro esempio banale non ho mai capito cos'è quel pugno in un occhio del cin e cout, non ci azzecca niente con il resto del linguaggio IMHO
E' semplicemente una banale applicazione dell'overloading degli operatori: né più né meno. Se non ti piacciono puoi non usarli, e in ogni caso puoi ridefinirteli come ti pare (cosa che in C non puoi fare).
su questo argomento non penso che io e te possiamo portare fatti a dimostrazione delle nostre tesi.. io tendo a fidarmi di quello che scrive il creatore del D su questo argomento, perchè perlomeno ha molta esperienza in fatto di compilatori
Ho anch'io esperienza, sebbene per uso personale, e mi sono posto non poche volte il problema di realizzarne con linguaggi come C++, Delphi, Java, ecc. Onestamente tutta questa complessità non la vedo.
vabbè il C++ senza classi non è il C++..
E' un suo sottoinsieme che rimane comunque un superset del C. Poi, ripeto, se non le si vuole usare non c'è problema, ma intanto ci sono.
ma questo si sapeva molto molto tempo prima che arrivassero i programmatori estremi a portare la luce :asd:
anzi ti dirò che sforzarsi a stare in un determinato numero di righe può essere dannoso.. molto meglio affidarsi al caro vecchio Buon Senso™
Certamente, ma questi studi sono comunque comodi perché ti permettono di analizzare il diverso grado d'incidenza dei bug (es: certe "prassi" sono più dannose di altre). Sempre a livello sperimentale, eh!
cdimauro
19-09-2007, 14:04
anch'io all'inizio non avevo capito perfettamente cosa intendevi per "tipi interni" :stordita:
solo pensandoci un pò m'è venuto in mente che non è altro che la traduzione italiana di "inner classes" :asd:
Onestamente in italiano è la prima volta che lo vedo scritto :fagiano:
Un mio prof le traduceva come 'classi innestate'. Non so cosa suoni peggio : )
In certi casi meglio lasciare il termine in inglese, se non c'è di meglio. :p
solo pensandoci un pò m'è venuto in mente che non è altro che la traduzione italiana di "inner classes" :asd:
Onestamente in italiano è la prima volta che lo vedo scritto :fagiano:
Un mio prof le traduceva come 'classi innestate'. Non so cosa suoni peggio : )
In certi casi meglio lasciare il termine in inglese, se non c'è di meglio. :p
Mixmar
19-09-2007, 14:10
Non è che si può prendere UN esempio utilizzato da un power user per mettere alla berlina un costrutto molto utile come quello delle generator expression di Python.
Scusa se sono stato un po' semplicistico, ma la mia era solo un'ipotesi: non conosco il linguaggio, come ti ho detto. Ho solo pensato che, visto che non avevo mai visto nulla di così "ostico" ad una lettura iniziale, Python meritasse la palma del più "elegantemente contorto". Molto IMHO, of course.
Adesso ditemi se anche quest'esempio è del tutto illegibile, pur facendo uso delle generator expression.
Al solito, vale la massima di cui sopra: le cose prendiamole "cum grano salis".
Questo esempio è invece chiaramente leggibile (e quelle dichiarazioni di array con funzione incorporata erano vagamente LISP-esche :oink: ), a parte il dettaglio dell'operatore "**" che non conoscevo.
Scusa se sono stato un po' semplicistico, ma la mia era solo un'ipotesi: non conosco il linguaggio, come ti ho detto. Ho solo pensato che, visto che non avevo mai visto nulla di così "ostico" ad una lettura iniziale, Python meritasse la palma del più "elegantemente contorto". Molto IMHO, of course.
Adesso ditemi se anche quest'esempio è del tutto illegibile, pur facendo uso delle generator expression.
Al solito, vale la massima di cui sopra: le cose prendiamole "cum grano salis".
Questo esempio è invece chiaramente leggibile (e quelle dichiarazioni di array con funzione incorporata erano vagamente LISP-esche :oink: ), a parte il dettaglio dell'operatore "**" che non conoscevo.
^TiGeRShArK^
19-09-2007, 14:10
In certi casi meglio lasciare il termine in inglese, se non c'è di meglio. :p
infatti a me non è mai passato per la testa di tradurlo :asd:
è PGI ke è il paladino della nostra lingua :O
:asd:
infatti a me non è mai passato per la testa di tradurlo :asd:
è PGI ke è il paladino della nostra lingua :O
:asd:
PGI-Bis
19-09-2007, 14:13
Ellamiseria. Avessi detto "faldone", "direttorio" o "sottipaggio"... interno mi sembra tutto fuorchè bizzarro. Se ha un problema con una classe interna cosa dici? Ho un inner taip che mi fidbec un problem sulla concurrent updeit?
Innestata è un termine che ho visto e sentito usare anche io. Non ha un bel suono ma rende l'idea. Forse si usa per l'assonanza con nested. Preferisco "annidata". Che è diverso da interna.
Mi viene sempre in mente quello che una volta mi chiese: che ne pensi di "geiciùmi"? Voi che ne pensate?
Innestata è un termine che ho visto e sentito usare anche io. Non ha un bel suono ma rende l'idea. Forse si usa per l'assonanza con nested. Preferisco "annidata". Che è diverso da interna.
Mi viene sempre in mente quello che una volta mi chiese: che ne pensi di "geiciùmi"? Voi che ne pensate?
cdimauro
19-09-2007, 14:21
Scusa se sono stato un po' semplicistico, ma la mia era solo un'ipotesi: non conosco il linguaggio, come ti ho detto. Ho solo pensato che, visto che non avevo mai visto nulla di così "ostico" ad una lettura iniziale, Python meritasse la palma del più "elegantemente contorto". Molto IMHO, of course.
Non c'è problema. Qui l'unico da fustigare sono io che programmo in maniera contorta, e ho messo in cattiva luce una caratteristica e addirittura l'intero linguaggio Python che, al contrario di quel che poteva sembrare, ha una sintassi molto semplice e leggibile.
Questo esempio è invece chiaramente leggibile (e quelle dichiarazioni di array con funzione incorporata erano vagamente LISP-esche :oink: ), a parte il dettaglio dell'operatore "**" che non conoscevo.
Sì, per la parte funzionale Python s'ispira molto a LISP e Haskell, che sono i linguaggi più noti/diffusi per questa metodologia di programmazione. Le list comprehension e le generator expression sono state "prese in prestito" da quest'ultimo, se non ricordo male.
Non c'è problema. Qui l'unico da fustigare sono io che programmo in maniera contorta, e ho messo in cattiva luce una caratteristica e addirittura l'intero linguaggio Python che, al contrario di quel che poteva sembrare, ha una sintassi molto semplice e leggibile.
Questo esempio è invece chiaramente leggibile (e quelle dichiarazioni di array con funzione incorporata erano vagamente LISP-esche :oink: ), a parte il dettaglio dell'operatore "**" che non conoscevo.
Sì, per la parte funzionale Python s'ispira molto a LISP e Haskell, che sono i linguaggi più noti/diffusi per questa metodologia di programmazione. Le list comprehension e le generator expression sono state "prese in prestito" da quest'ultimo, se non ricordo male.
cdimauro
19-09-2007, 14:23
infatti a me non è mai passato per la testa di tradurlo :asd:
è PGI ke è il paladino della nostra lingua :O
:asd:
Ellamiseria. Avessi detto "faldone", "direttorio" o "sottipaggio"... interno mi sembra tutto fuorchè bizzarro. Se ha un problema con una classe interna cosa dici? Ho un inner taip che mi fidbec un problem sulla concurrent updeit?
Innestata è un termine che ho visto e sentito usare anche io. Non ha un bel suono ma rende l'idea. Forse si usa per l'assonanza con nested. Preferisco "annidata". Che è diverso da interna.
Mi viene sempre in mente quello che una volta mi chiese: che ne pensi di "geiciùmi"? Voi che ne pensate?
Io penso che ho ancora gli incubi ricordando di aver letto, parecchio tempo fa, "direttorio" per rendere in italiano il termine "directory". :Puke:
P.S. Che roba è "geiciùmi"?
è PGI ke è il paladino della nostra lingua :O
:asd:
Ellamiseria. Avessi detto "faldone", "direttorio" o "sottipaggio"... interno mi sembra tutto fuorchè bizzarro. Se ha un problema con una classe interna cosa dici? Ho un inner taip che mi fidbec un problem sulla concurrent updeit?
Innestata è un termine che ho visto e sentito usare anche io. Non ha un bel suono ma rende l'idea. Forse si usa per l'assonanza con nested. Preferisco "annidata". Che è diverso da interna.
Mi viene sempre in mente quello che una volta mi chiese: che ne pensi di "geiciùmi"? Voi che ne pensate?
Io penso che ho ancora gli incubi ricordando di aver letto, parecchio tempo fa, "direttorio" per rendere in italiano il termine "directory". :Puke:
P.S. Che roba è "geiciùmi"?
bist
19-09-2007, 14:28
P.S. Che roba è "geiciùmi"?
Azzardo un J2ME.
Azzardo un J2ME.
PGI-Bis
19-09-2007, 14:30
P.S. Che roba è "geiciùmi"?
Eh eh eh, e qui vi voglio. Avanti, che è "geiciùmi"?
Eh eh eh, e qui vi voglio. Avanti, che è "geiciùmi"?
k0nt3
19-09-2007, 14:30
Io penso che ho ancora gli incubi ricordando di aver letto, parecchio tempo fa, "direttorio" per rendere in italiano il termine "directory". :Puke:
P.S. Che roba è "geiciùmi"?
eheh io ricordo le lezioni di informatica 2 :D alla 6 lezione ho capito cosa voleva dire "direttorio" :rotfl:
geiciùmi... J2ME?
P.S. Che roba è "geiciùmi"?
eheh io ricordo le lezioni di informatica 2 :D alla 6 lezione ho capito cosa voleva dire "direttorio" :rotfl:
geiciùmi... J2ME?
PGI-Bis
19-09-2007, 14:30
Azzardo un J2ME.
Esatto. Gei Due Emme E. E' capitato anche a te?
Esatto. Gei Due Emme E. E' capitato anche a te?
bist
19-09-2007, 14:34
Esatto. Gei Due Emme E. E' capitato anche a te?
Per fortuna no : )
Per fortuna no : )
^TiGeRShArK^
19-09-2007, 14:39
Ellamiseria. Avessi detto "faldone", "direttorio" o "sottipaggio"... interno mi sembra tutto fuorchè bizzarro. Se ha un problema con una classe interna cosa dici? Ho un inner taip che mi fidbec un problem sulla concurrent updeit?
no...
inizierei ad inveire contro Sant'Inner Class :asd:
E cmq nemmeno inner type ho mai sentito.. :mbe: SEMPRE inner class :fagiano:
Mi viene sempre in mente quello che una volta mi chiese: che ne pensi di "geiciùmi"? Voi che ne pensate?
J2ME? :asd:
bella piattaforma :O
:asd:
no...
inizierei ad inveire contro Sant'Inner Class :asd:
E cmq nemmeno inner type ho mai sentito.. :mbe: SEMPRE inner class :fagiano:
Mi viene sempre in mente quello che una volta mi chiese: che ne pensi di "geiciùmi"? Voi che ne pensate?
J2ME? :asd:
bella piattaforma :O
:asd:
PGI-Bis
19-09-2007, 14:48
Eh già, coi suggeritori è facile! Io risposi con un bel "ge...che?" al che mi proposero un più semplice "gei tu em ai". Trattenni un "mavaffanchiul" perchè son sempre stato un signore.
"inner class" non va tanto bene. Ci sono cose che non sono class('s) ma possono essere inner. Le interfeis('s), le annotascion(ssss) e gli enum(sss). Non sono class('s) però sono taip(sssss). Da cui inner taip(sssss).
"inner class" non va tanto bene. Ci sono cose che non sono class('s) ma possono essere inner. Le interfeis('s), le annotascion(ssss) e gli enum(sss). Non sono class('s) però sono taip(sssss). Da cui inner taip(sssss).
^TiGeRShArK^
19-09-2007, 14:57
Eh già, coi suggeritori è facile! Io risposi con un bel "ge...che?" al che mi proposero un più semplice "gei tu em ai". Trattenni un "mavaffanchiul" perchè son sempre stato un signore.
"inner class" non va tanto bene. Ci sono cose che non sono class('s) ma possono essere inner. Le interfeis('s), le annotascion(ssss) e gli enum(sss). Non sono class('s) però sono taip(sssss). Da cui inner taip(sssss).
Ancora non li avevo letti i suggerimenti perchè io rispondo sempre un msg x volta e poi continuo la lettura :Prrr:
cmq in effetti è + corretto inner types solo ke mi sa che io ho sempre usato inner classes nel mio codice.. apposta non m'era mai venuto il dubbio :p
"inner class" non va tanto bene. Ci sono cose che non sono class('s) ma possono essere inner. Le interfeis('s), le annotascion(ssss) e gli enum(sss). Non sono class('s) però sono taip(sssss). Da cui inner taip(sssss).
Ancora non li avevo letti i suggerimenti perchè io rispondo sempre un msg x volta e poi continuo la lettura :Prrr:
cmq in effetti è + corretto inner types solo ke mi sa che io ho sempre usato inner classes nel mio codice.. apposta non m'era mai venuto il dubbio :p
k0nt3
19-09-2007, 15:03
E' semplicemente una banale applicazione dell'overloading degli operatori: né più né meno. Se non ti piacciono puoi non usarli, e in ogni caso puoi ridefinirteli come ti pare (cosa che in C non puoi fare).
se il prezzo da pagare per l'overloading (o sovraccaricamento :read: ) degli operatori sono pugni di tale portata negli occhi preferisco che non ci sia :D
in fondo se uno impara a programmare in java capisce che l'overloading degli operatori è una caratteristica del tutto superflua
Ho anch'io esperienza, sebbene per uso personale, e mi sono posto non poche volte il problema di realizzarne con linguaggi come C++, Delphi, Java, ecc. Onestamente tutta questa complessità non la vedo.
allora non saprei, se trovo documenti li posto
se il prezzo da pagare per l'overloading (o sovraccaricamento :read: ) degli operatori sono pugni di tale portata negli occhi preferisco che non ci sia :D
in fondo se uno impara a programmare in java capisce che l'overloading degli operatori è una caratteristica del tutto superflua
Ho anch'io esperienza, sebbene per uso personale, e mi sono posto non poche volte il problema di realizzarne con linguaggi come C++, Delphi, Java, ecc. Onestamente tutta questa complessità non la vedo.
allora non saprei, se trovo documenti li posto
cdimauro
19-09-2007, 15:17
se il prezzo da pagare per l'overloading (o sovraccaricamento :read: ) degli operatori sono pugni di tale portata negli occhi preferisco che non ci sia :D
Non mi risulta che la sintassi per l'overloading degli operatori sia così contorta.
E poi vuoi mettere scrivere s += "Pippo" al posto di strcat(s, "Pippo") oppure s == "Pippo" al posto di strcmp(s, "Pippo")?
Astrazione rulez. ;)
in fondo se uno impara a programmare in java capisce che l'overloading degli operatori è una caratteristica del tutto superflua
Io ho imparato che, se serve, la si usa. Se non c'è non è possibile nemmeno di decidere di non usarla, perché la risposta è sempre affermativa.
allora non saprei, se trovo documenti li posto
Guarda, a me non cambierebbe niente perché, come ho già detto, una certa esperienza me la son fatta e voglio pure continuare non appena avrò uno straccio di tempo, visto che ho un'ideuzza che mi frulla nella testa (a proposito: Jappilaaaaaaaaas! Mi serve lo spike sul parser che ho realizzato per Diamonds!!! Non riesco più a trovarlo! :muro:)
x PGI-Bis: non ci sarei mai arrivato!!! :(
Non mi risulta che la sintassi per l'overloading degli operatori sia così contorta.
E poi vuoi mettere scrivere s += "Pippo" al posto di strcat(s, "Pippo") oppure s == "Pippo" al posto di strcmp(s, "Pippo")?
Astrazione rulez. ;)
in fondo se uno impara a programmare in java capisce che l'overloading degli operatori è una caratteristica del tutto superflua
Io ho imparato che, se serve, la si usa. Se non c'è non è possibile nemmeno di decidere di non usarla, perché la risposta è sempre affermativa.
allora non saprei, se trovo documenti li posto
Guarda, a me non cambierebbe niente perché, come ho già detto, una certa esperienza me la son fatta e voglio pure continuare non appena avrò uno straccio di tempo, visto che ho un'ideuzza che mi frulla nella testa (a proposito: Jappilaaaaaaaaas! Mi serve lo spike sul parser che ho realizzato per Diamonds!!! Non riesco più a trovarlo! :muro:)
x PGI-Bis: non ci sarei mai arrivato!!! :(
Dott.Wisem
19-09-2007, 15:30
Non è che si può prendere UN esempio utilizzato da un power user per mettere alla berlina un costrutto molto utile come quello delle generator expression di Python.Io non ho detto che il Python non sia un buon linguaggio, anche perché non l'ho mai usato e quindi non sono in grado di giudicarlo. Ho soltanto detto che quel codice che avevi postato è poco leggibile dal punto di vista di un programmatore abituato ad alcune convenzioni sintattiche che risalgono ai tempi del Basic (come, ad esempio, il ciclo for) e si sono poi diffuse, con delle leggere varianti sintattiche, anche in linguaggi molto più evoluti. Questo porta dei problemi nel momento in cui vuoi introdurre delle nuove persone nel team, in quanto queste persone, a meno che non siano già programmatori Python, devono entrare in una mentalità diversa, che non è necessariamente peggiore, ma che comunque ti fa perdere del tempo prezioso per un adeguato apprendimento, quando usando un linguaggio dalla sintassi più familiare, il problema non si sarebbe posto. Non fraintendermi, non sto dicendo che hai sbagliato a scegliere il Python per i tuoi progetti... Sicuramente avrai avuto le tue buone ragioni.
Anzi, addirittura con un solo esempio di un solo costrutto si mette alla berlina un intero linguaggio (e il resto dove lo mettiamo? Gli avete dato almeno un'occhiata). :rolleyes:
Numeri = [1, 2, 3, 4, 5, 6]
print 'Numeri:', Numeri
Quadrati = (Numero ** 2 for Numero in Numeri)
print 'Quadrati: ',
for Quadrato in Quadrati:
print Quadrato,
print
Cubi = (Numero ** 3 for Numero in Numeri)
print 'Cubi: ',
for Cubo in Cubi:
print Cubo,
print
Adesso ditemi se anche quest'esempio è del tutto illegibile, pur facendo uso delle generator expression.
Onestamente non mi pare un capolavoro di leggibilità... Quel ** è proprio brutto da vedere (avrei preferito un 'numero.Pow(2)'), così come il for messo dopo l'istruzione da eseguire nel ciclo, che determina una forte confusione nella mente di chi non conosce il Python (nell'analisi matematica siamo abituati a mettere il 'per ogni' all'inizio di un'espressione. Forse è per questo che il ciclo for ci piace metterlo all'inizio), nonché il fatto che, se non ho capito male, quell'espressione fra parentesi, (Numero ** 2 for Numero in Numeri), mi pare che generi una lista di elementi, piuttosto che un solo elemento. Anche quest'ultima cosa non è proprio chiarissima ad una prima lettura. :p
Anzi, addirittura con un solo esempio di un solo costrutto si mette alla berlina un intero linguaggio (e il resto dove lo mettiamo? Gli avete dato almeno un'occhiata). :rolleyes:
Numeri = [1, 2, 3, 4, 5, 6]
print 'Numeri:', Numeri
Quadrati = (Numero ** 2 for Numero in Numeri)
print 'Quadrati: ',
for Quadrato in Quadrati:
print Quadrato,
Cubi = (Numero ** 3 for Numero in Numeri)
print 'Cubi: ',
for Cubo in Cubi:
print Cubo,
Adesso ditemi se anche quest'esempio è del tutto illegibile, pur facendo uso delle generator expression.
Onestamente non mi pare un capolavoro di leggibilità... Quel ** è proprio brutto da vedere (avrei preferito un 'numero.Pow(2)'), così come il for messo dopo l'istruzione da eseguire nel ciclo, che determina una forte confusione nella mente di chi non conosce il Python (nell'analisi matematica siamo abituati a mettere il 'per ogni' all'inizio di un'espressione. Forse è per questo che il ciclo for ci piace metterlo all'inizio), nonché il fatto che, se non ho capito male, quell'espressione fra parentesi, (Numero ** 2 for Numero in Numeri), mi pare che generi una lista di elementi, piuttosto che un solo elemento. Anche quest'ultima cosa non è proprio chiarissima ad una prima lettura. :p
k0nt3
19-09-2007, 15:34
@cdimauro
vuoi mettere s.append("Pippo")? ;)
vuoi mettere s.append("Pippo")? ;)
Dott.Wisem
19-09-2007, 15:45
@cdimauro
vuoi mettere s.append("Pippo")? ;)Per chi è abituato alle sintassi C-like, la possibiltà di poter fare un
s += "pezzo da aggiungere"
è una cosa certamente molto sintetica e leggibile. Molto dipende dal proprio background. :)
vuoi mettere s.append("Pippo")? ;)Per chi è abituato alle sintassi C-like, la possibiltà di poter fare un
s += "pezzo da aggiungere"
è una cosa certamente molto sintetica e leggibile. Molto dipende dal proprio background. :)
cdimauro
19-09-2007, 15:55
Io non ho detto che il Python non sia un buon linguaggio, anche perché non l'ho mai usato e quindi non sono in grado di giudicarlo. Ho soltanto detto che quel codice che avevi postato è poco leggibile dal punto di vista di un programmatore abituato ad alcune convenzioni sintattiche che risalgono ai tempi del Basic (come, ad esempio, il ciclo for) e si sono poi diffuse, con delle leggere varianti sintattiche, anche in linguaggi molto più evoluti. Questo porta dei problemi nel momento in cui vuoi introdurre delle nuove persone nel team, in quanto queste persone, a meno che non siano già programmatori Python, devono entrare in una mentalità diversa, che non è necessariamente peggiore, ma che comunque ti fa perdere del tempo prezioso per un adeguato apprendimento, quando usando un linguaggio dalla sintassi più familiare, il problema non si sarebbe posto. Non fraintendermi, non sto dicendo che hai sbagliato a scegliere il Python per i tuoi progetti... Sicuramente avrai avuto le tue buone ragioni.
Per quello che c'era da fare dovevo scegliere fra PERL, Python e Ruby. PHP e Java (C e C++, perché non sono linguaggi abbastanza produttivi) li ho scartati perché nell'azienda c'erano già altre persone che li conoscevano.
Sì, perché m'era stato chiesto, oltre a scrivere delle applicazioni per un grosso progetto che avevamo, di scegliere un linguaggio diverso da quelli per cui c'era già gente con competenze acquisite.
Python, infatti, l'ho scelto e imparato da zero (e in 20 giorni ho imparato a usare il linguaggio e sono arrivato alla scadenza: probabilmente non ci sarei riuscito con altri linguaggi), e adesso ci lavoro stabilmente.
Per il resto, se arrivano altre persone in azienda un periodo di addestramento è sempre necessario, ma ti assicuro che fra imparare Python e lavorare con la roba scritta in PHP preferirebbero nettamente la prima soluzione (fermo restando che apprezzerebbero questo bellissimo linguaggio). :D
Onestamente non mi pare un capolavoro di leggibilità... Quel ** è proprio brutto da vedere (avrei preferito un 'numero.Pow(2)'),
E perché allora non usare anche un numero.Mul(), numero.Div(), ecc.? Per me possiamo anche fare a meno degli operatori "tradizionali". ;)
Tra l'altro ** è un operatore "storico" usato per elevare a potenza: non è proprio "poco diffuso".
Su % come operatore suppongo che la tua opinione sia la stessa del **. ;)
così come il for messo dopo l'istruzione da eseguire nel ciclo, che determina una forte confusione nella mente di chi non conosce il Python (nell'analisi matematica siamo abituati a mettere il 'per ogni' all'inizio di un'espressione. Forse è per questo che il ciclo for ci piace metterlo all'inizio),
Come dicevamo anche con cionci e kont3, è sufficiente leggere l'espressione senza condizionamenti per riuscire a comprenderne tranquillamente il significato.
nonché il fatto che, se non ho capito male, quell'espressione fra parentesi, (Numero ** 2 for Numero in Numeri), mi pare che generi una lista di elementi, piuttosto che un solo elemento. Anche quest'ultima cosa non è proprio chiarissima ad una prima lettura. :p
No, ma ci si arriva velocemente: il fatto che si vada a operare su un numero preso da un insieme di numeri, com'è scritto chiaramente, porta intuitivamente a capire che il risultato non può essere un dato "secco".
Per quello che c'era da fare dovevo scegliere fra PERL, Python e Ruby. PHP e Java (C e C++, perché non sono linguaggi abbastanza produttivi) li ho scartati perché nell'azienda c'erano già altre persone che li conoscevano.
Sì, perché m'era stato chiesto, oltre a scrivere delle applicazioni per un grosso progetto che avevamo, di scegliere un linguaggio diverso da quelli per cui c'era già gente con competenze acquisite.
Python, infatti, l'ho scelto e imparato da zero (e in 20 giorni ho imparato a usare il linguaggio e sono arrivato alla scadenza: probabilmente non ci sarei riuscito con altri linguaggi), e adesso ci lavoro stabilmente.
Per il resto, se arrivano altre persone in azienda un periodo di addestramento è sempre necessario, ma ti assicuro che fra imparare Python e lavorare con la roba scritta in PHP preferirebbero nettamente la prima soluzione (fermo restando che apprezzerebbero questo bellissimo linguaggio). :D
Onestamente non mi pare un capolavoro di leggibilità... Quel ** è proprio brutto da vedere (avrei preferito un 'numero.Pow(2)'),
E perché allora non usare anche un numero.Mul(), numero.Div(), ecc.? Per me possiamo anche fare a meno degli operatori "tradizionali". ;)
Tra l'altro ** è un operatore "storico" usato per elevare a potenza: non è proprio "poco diffuso".
Su % come operatore suppongo che la tua opinione sia la stessa del **. ;)
così come il for messo dopo l'istruzione da eseguire nel ciclo, che determina una forte confusione nella mente di chi non conosce il Python (nell'analisi matematica siamo abituati a mettere il 'per ogni' all'inizio di un'espressione. Forse è per questo che il ciclo for ci piace metterlo all'inizio),
Come dicevamo anche con cionci e kont3, è sufficiente leggere l'espressione senza condizionamenti per riuscire a comprenderne tranquillamente il significato.
nonché il fatto che, se non ho capito male, quell'espressione fra parentesi, (Numero ** 2 for Numero in Numeri), mi pare che generi una lista di elementi, piuttosto che un solo elemento. Anche quest'ultima cosa non è proprio chiarissima ad una prima lettura. :p
No, ma ci si arriva velocemente: il fatto che si vada a operare su un numero preso da un insieme di numeri, com'è scritto chiaramente, porta intuitivamente a capire che il risultato non può essere un dato "secco".
cdimauro
19-09-2007, 15:58
@cdimauro
vuoi mettere s.append("Pippo")? ;)
Meglio s.concat("Pippo"): append in genere lo si usa nelle liste. ;) E poi s.concat() in C non lo puoi rendere: ti servirebbe definire s come istanza di una classe, e ciò non è possibile.
Comunque su s == "Pippo" non hai detto niente, eh! Assumo che tu sia d'accordo con me. :D
Per chi è abituato alle sintassi C-like, la possibiltà di poter fare un
s += "pezzo da aggiungere"
è una cosa certamente molto sintetica e leggibile. Molto dipende dal proprio background. :)
Concordo: l'ho scritto apposta con una sintassi C-like per evidenziare come sarebbe comodo e semplice da usare per chi lavora con linguaggi come il C & derivati.
vuoi mettere s.append("Pippo")? ;)
Meglio s.concat("Pippo"): append in genere lo si usa nelle liste. ;) E poi s.concat() in C non lo puoi rendere: ti servirebbe definire s come istanza di una classe, e ciò non è possibile.
Comunque su s == "Pippo" non hai detto niente, eh! Assumo che tu sia d'accordo con me. :D
Per chi è abituato alle sintassi C-like, la possibiltà di poter fare un
s += "pezzo da aggiungere"
è una cosa certamente molto sintetica e leggibile. Molto dipende dal proprio background. :)
Concordo: l'ho scritto apposta con una sintassi C-like per evidenziare come sarebbe comodo e semplice da usare per chi lavora con linguaggi come il C & derivati.
PGI-Bis
19-09-2007, 15:59
Io penso che la questione degli operatori e della loro sovrascrittura andrebbe risolta radicalmente introducendo la possibilità di usare qualsiasi carattere come identificatore di un metodo o di una funzione.
Per essere sintatticamente coerente, vale a dire per non introdurre forme diverse per operatori e metodi, noi dovremmo anche avvicinare la sintassi dell'invocazione di funzione/metodo con argomenti a quella degli operatori.
Esempio:
classe Numero
metodo + argomento { corpo del metodo }
metodo somma argomento { corpo del metodo }
la parte che sta tra "metodo" e "argomento" è l'identificatore e il ricevente (l'instanza usata per l'invocazione) è uno degli operandi.
Insomma, posso usare * come nome di un metodo e devo togliere le parentesi che racchiudono la lista di argomenti.
Ci sono lingue che permettono di usare qualsiasi simbolo come identificatore (ad esempio Scala) ma lo fanno introducendo regole in più per la valutazione delle espressioni che invocano metodo, onde evitare cose come:
numero.+(altro numero);
Per essere sintatticamente coerente, vale a dire per non introdurre forme diverse per operatori e metodi, noi dovremmo anche avvicinare la sintassi dell'invocazione di funzione/metodo con argomenti a quella degli operatori.
Esempio:
classe Numero
metodo + argomento { corpo del metodo }
metodo somma argomento { corpo del metodo }
la parte che sta tra "metodo" e "argomento" è l'identificatore e il ricevente (l'instanza usata per l'invocazione) è uno degli operandi.
Insomma, posso usare * come nome di un metodo e devo togliere le parentesi che racchiudono la lista di argomenti.
Ci sono lingue che permettono di usare qualsiasi simbolo come identificatore (ad esempio Scala) ma lo fanno introducendo regole in più per la valutazione delle espressioni che invocano metodo, onde evitare cose come:
numero.+(altro numero);
cdimauro
19-09-2007, 16:07
Infatti è un problema di non facile soluzione.
Scrivere parser con operatori definibili da qualunque accozzaglia di simboli è piuttosto complicato (in primis perché comporterebbe problemi per il loro riconoscimento, perché potrebbero risultare delle ambiguità, e non sarebbe nemmeno tanto difficile).
Anche perché sarebbe da definire l'associatività e la loro priorità.
Onestamente io sono per usare il meno possibile operatori facenti uso di simboli: sono ben più leggibili quelli costituiti da lettere (es: and al posto di &&, ecc.).
Scrivere parser con operatori definibili da qualunque accozzaglia di simboli è piuttosto complicato (in primis perché comporterebbe problemi per il loro riconoscimento, perché potrebbero risultare delle ambiguità, e non sarebbe nemmeno tanto difficile).
Anche perché sarebbe da definire l'associatività e la loro priorità.
Onestamente io sono per usare il meno possibile operatori facenti uso di simboli: sono ben più leggibili quelli costituiti da lettere (es: and al posto di &&, ecc.).
^TiGeRShArK^
19-09-2007, 16:49
(a proposito: Jappilaaaaaaaaas! Mi serve lo spike sul parser che ho realizzato per Diamonds!!! Non riesco più a trovarlo! :muro:)
:eek:
non ci sono + tutti gli spikes? :mbe:
una volta erano nella cartella allo stesso livello di trunk ke si kiamava spikes se non erro....:confused:
:eek:
non ci sono + tutti gli spikes? :mbe:
una volta erano nella cartella allo stesso livello di trunk ke si kiamava spikes se non erro....:confused:
Dott.Wisem
19-09-2007, 16:52
[...]E perché allora non usare anche un numero.Mul(), numero.Div(), ecc.? Per me possiamo anche fare a meno degli operatori "tradizionali". ;)
Tra l'altro ** è un operatore "storico" usato per elevare a potenza: non è proprio "poco diffuso".
Su % come operatore suppongo che la tua opinione sia la stessa del **. ;)No, non è che preferisco usare sempre una sintassi del tipo 'oggetto.metodo(argomento)', ma in quel caso specifico (elevamento a potenza) si. Se poi il linguaggio consentisse una sintassi del tipo, x^2, tanto meglio, ma sono proprio quei due asterischi consecutivi che non mi piacciono. Non conosco tantissimi linguaggi, ma devo ammettere che non li avevo mai visti usati in quel modo.
Relativamente all'operatore di modulo %, preferirei usare una sintassi del tipo '12 mod 5', ma oramai il % è diffusissimo, quindi non è un grande problema...
Come dicevamo anche con cionci e kont3, è sufficiente leggere l'espressione senza condizionamenti per riuscire a comprenderne tranquillamente il significato. Diciamo che si può intuire il significato ma, al di là del diverso posizionamento del costrutto, rimangono comunque dei punti oscuri che si possono comprendere solo approfondendo il discorso. Se invece vedo un ciclo for, while, ecc., seguito da un blocco racchiuso fra parentesi graffe, normalmente dubbi non ce ne sono...
Tra l'altro ** è un operatore "storico" usato per elevare a potenza: non è proprio "poco diffuso".
Su % come operatore suppongo che la tua opinione sia la stessa del **. ;)No, non è che preferisco usare sempre una sintassi del tipo 'oggetto.metodo(argomento)', ma in quel caso specifico (elevamento a potenza) si. Se poi il linguaggio consentisse una sintassi del tipo, x^2, tanto meglio, ma sono proprio quei due asterischi consecutivi che non mi piacciono. Non conosco tantissimi linguaggi, ma devo ammettere che non li avevo mai visti usati in quel modo.
Relativamente all'operatore di modulo %, preferirei usare una sintassi del tipo '12 mod 5', ma oramai il % è diffusissimo, quindi non è un grande problema...
Come dicevamo anche con cionci e kont3, è sufficiente leggere l'espressione senza condizionamenti per riuscire a comprenderne tranquillamente il significato. Diciamo che si può intuire il significato ma, al di là del diverso posizionamento del costrutto, rimangono comunque dei punti oscuri che si possono comprendere solo approfondendo il discorso. Se invece vedo un ciclo for, while, ecc., seguito da un blocco racchiuso fra parentesi graffe, normalmente dubbi non ce ne sono...
cdimauro
19-09-2007, 17:04
:eek:
non ci sono + tutti gli spikes? :mbe:
una volta erano nella cartella allo stesso livello di trunk ke si kiamava spikes se non erro....:confused:
Non mi pare fossero nello stesso livello di trunk: ricordo che erano stati creati degli appositi branch o roba simile.
No, non è che preferisco usare sempre una sintassi del tipo 'oggetto.metodo(argomento)', ma in quel caso specifico (elevamento a potenza) si. Se poi il linguaggio consentisse una sintassi del tipo, x^2, tanto meglio, ma sono proprio quei due asterischi consecutivi che non mi piacciono. Non conosco tantissimi linguaggi, ma devo ammettere che non li avevo mai visti usati in quel modo.
Ti assicuro che lo ritrovi in diversi linguaggi. Probabilmente la scelta di ** è stata dettata proprio da questo motivo.
Relativamente all'operatore di modulo %, preferirei usare una sintassi del tipo '12 mod 5', ma oramai il % è diffusissimo, quindi non è un grande problema...
Ecco, vedi: è un problema proprio di abitudine. Lo stesso si può dire per **: è abituale trovarlo in linguaggi che mettono a disposizione l'operatore di elevazione a potenza usando dei simboli. ;)
Diciamo che si può intuire il significato ma, al di là del diverso posizionamento del costrutto, rimangono comunque dei punti oscuri che si possono comprendere solo approfondendo il discorso. Se invece vedo un ciclo for, while, ecc., seguito da un blocco racchiuso fra parentesi graffe, normalmente dubbi non ce ne sono...
Idem come sopra: è proprio una questione di abitudine, com'è abituale vedere un blocco di codice delimitato dalle parentesi graffe (che in Pascal, invece, delimitano dei commenti).
Piuttosto che leggere il codice secondo un certo schema mentale, è meglio leggerlo parola (o simbolo) dopo parola, e ci si arriva velocemente al significato. :)
non ci sono + tutti gli spikes? :mbe:
una volta erano nella cartella allo stesso livello di trunk ke si kiamava spikes se non erro....:confused:
Non mi pare fossero nello stesso livello di trunk: ricordo che erano stati creati degli appositi branch o roba simile.
No, non è che preferisco usare sempre una sintassi del tipo 'oggetto.metodo(argomento)', ma in quel caso specifico (elevamento a potenza) si. Se poi il linguaggio consentisse una sintassi del tipo, x^2, tanto meglio, ma sono proprio quei due asterischi consecutivi che non mi piacciono. Non conosco tantissimi linguaggi, ma devo ammettere che non li avevo mai visti usati in quel modo.
Ti assicuro che lo ritrovi in diversi linguaggi. Probabilmente la scelta di ** è stata dettata proprio da questo motivo.
Relativamente all'operatore di modulo %, preferirei usare una sintassi del tipo '12 mod 5', ma oramai il % è diffusissimo, quindi non è un grande problema...
Ecco, vedi: è un problema proprio di abitudine. Lo stesso si può dire per **: è abituale trovarlo in linguaggi che mettono a disposizione l'operatore di elevazione a potenza usando dei simboli. ;)
Diciamo che si può intuire il significato ma, al di là del diverso posizionamento del costrutto, rimangono comunque dei punti oscuri che si possono comprendere solo approfondendo il discorso. Se invece vedo un ciclo for, while, ecc., seguito da un blocco racchiuso fra parentesi graffe, normalmente dubbi non ce ne sono...
Idem come sopra: è proprio una questione di abitudine, com'è abituale vedere un blocco di codice delimitato dalle parentesi graffe (che in Pascal, invece, delimitano dei commenti).
Piuttosto che leggere il codice secondo un certo schema mentale, è meglio leggerlo parola (o simbolo) dopo parola, e ci si arriva velocemente al significato. :)
^TiGeRShArK^
19-09-2007, 17:09
Non mi pare fossero nello stesso livello di trunk: ricordo che erano stati creati degli appositi branch o roba simile.
ehmm..
con SVN non esistono i branch almeno nell'accezione tipica di CVS :p
praticamente era stata creata un'altra cartella chiamata branches (o qualcosa del genere) sempre allo stesso livello di trunk e in branches c'erano le varie cartelle con i salvataggi delle diverse iterazioni.
Se non erro erano allo stesso livello di trunk..
ma onestamente su sourceforge non mi sono mai messo cercarli....
ora ho controllato un attimo e in effetti gli spikes sono nella cartella branches... :mbe:
evidentemente m'ero un pò confuso :p
ma cmq è allo stesso livello di trunk e purtroppo non vedo lo spike del parser...:(
anke se ad esempio c'è ancora il mio branch con java web start :mbe:
ehmm..
con SVN non esistono i branch almeno nell'accezione tipica di CVS :p
praticamente era stata creata un'altra cartella chiamata branches (o qualcosa del genere) sempre allo stesso livello di trunk e in branches c'erano le varie cartelle con i salvataggi delle diverse iterazioni.
Se non erro erano allo stesso livello di trunk..
ma onestamente su sourceforge non mi sono mai messo cercarli....
ora ho controllato un attimo e in effetti gli spikes sono nella cartella branches... :mbe:
evidentemente m'ero un pò confuso :p
ma cmq è allo stesso livello di trunk e purtroppo non vedo lo spike del parser...:(
anke se ad esempio c'è ancora il mio branch con java web start :mbe:
cdimauro
19-09-2007, 17:31
Pork. Vabbé, contatto Marco in PVT e vediamo se riesce a recuperarlo.
Grazie e scusate l'OT. :D
Grazie e scusate l'OT. :D
marco.r
19-09-2007, 17:33
perchè.. "per ogni Numero all'interno di Numeri eleva Numero al cubo" non è italiano? :fagiano:
la differenza è che prima definisci cos'è Numero e poi lo usi, mentre con il for alla fine è un pò più complicato da capire al volo (magari in questo caso semplice non si nota)
ma probabilmente è abitudine eh :)
E' ispirato alla notazione insiemistica "l'insieme di tutti i valori Numero^2 per Numero che sta nell'insieme Numeri".
Per chi ha un background matematico e' leggibilissimo. In haskell e' ancora piu' "intuitivo" (nel senso di vicino alla notazione matematica) :p :
quadrati = [ x ^ 2 | x <- [1..10] ]
cubi = [ x ^ 3 | x <- [1..] ]
La seconda tra l'altro ritorna l'insieme di tutti i cubi :eh: :D
la differenza è che prima definisci cos'è Numero e poi lo usi, mentre con il for alla fine è un pò più complicato da capire al volo (magari in questo caso semplice non si nota)
ma probabilmente è abitudine eh :)
E' ispirato alla notazione insiemistica "l'insieme di tutti i valori Numero^2 per Numero che sta nell'insieme Numeri".
Per chi ha un background matematico e' leggibilissimo. In haskell e' ancora piu' "intuitivo" (nel senso di vicino alla notazione matematica) :p :
quadrati = [ x ^ 2 | x <- [1..10] ]
cubi = [ x ^ 3 | x <- [1..] ]
La seconda tra l'altro ritorna l'insieme di tutti i cubi :eh: :D
atragon
19-09-2007, 18:06
no, una metrica di carattere generale non esiste, altrimenti sarebbe banale stabilire il linguaggio migliore.
Scusa ma quando scegli un lavoro valuti anche lo strumento migliore per quel lavoro no? Certamente è come dici:
come ho già detto da qualche parte in questo thread, per certe cose in cui non è necessaria la programmazione OO, il C rimane un gran bel linguaggio.
Il punto è capire quali problemi risolve uno e quali risolve l'altro, restando nell'ambito della diatriba C vs C++. L'idea che ho e che mi sembra generalizzata è che C++ sia applicabile a uno spettro maggiore di problemi, consenta un miglior sviluppo dal punto di vista architetturale per un ventaglio più ampio di problemi. Che poi nello specifico si possa puntare su altri strumenti è indubbio, ci mancherebbe ma questo implica solo che il C++ non è perfetto e ci mancherebbe di nuovo. Ma in sostanza la domanda cardine è sempre quella: cosa fa il C che C++ non fa?
se invece uno vuole programmare a oggetti il C++ è probabilmente la scelta peggiore.
il C++ ha il difetto di avere troppi modi per fare la stessa cosa, di essere eccessivamente complesso dal punto di vista del compilatore e altre cose che sono state sollevate in precedenza. per cui il C++ non è necessariamente migliore del C..
Detto così sembra peggìore di tutto :D. La complessità è un limite ma mi pare di capire che in parecchi tutto sommato l'hanno superata e hanno comunque ottenuto un saldo positivo...io stesso pur non avendo potuto applicarmici più di tanto e pertanto avendo "sofferto" a causa del C++ non posso negare di aver ottenuto qualche soddisfazione.
comunque sia anche parlando del C si può parlare di progresso perchè è uno standard che si è evoluto e si evolverà ancora probabilmente, ma non supporterà mai la programmazione OO, perchè non è il suo obiettivo. se vuoi programmare a oggetti usi un altro linguaggio.
e sono daccordo che la programmazione a oggetti è utile nella maggiorparte dei casi, ma non in tutti i casi.
dipende è la parola giusta. leggendo il documento linkato in precedenza mi vengono i brividi: un metodo non deve essere più lungo di 10 righe ecc.. mah
Il discorso per me è sempre quello: il C ha un ambito sempre più ristretto di applicazione e, tutto sommato, può ringraziare che l'assembly non è proprio immediato....
Scusa ma quando scegli un lavoro valuti anche lo strumento migliore per quel lavoro no? Certamente è come dici:
come ho già detto da qualche parte in questo thread, per certe cose in cui non è necessaria la programmazione OO, il C rimane un gran bel linguaggio.
Il punto è capire quali problemi risolve uno e quali risolve l'altro, restando nell'ambito della diatriba C vs C++. L'idea che ho e che mi sembra generalizzata è che C++ sia applicabile a uno spettro maggiore di problemi, consenta un miglior sviluppo dal punto di vista architetturale per un ventaglio più ampio di problemi. Che poi nello specifico si possa puntare su altri strumenti è indubbio, ci mancherebbe ma questo implica solo che il C++ non è perfetto e ci mancherebbe di nuovo. Ma in sostanza la domanda cardine è sempre quella: cosa fa il C che C++ non fa?
se invece uno vuole programmare a oggetti il C++ è probabilmente la scelta peggiore.
il C++ ha il difetto di avere troppi modi per fare la stessa cosa, di essere eccessivamente complesso dal punto di vista del compilatore e altre cose che sono state sollevate in precedenza. per cui il C++ non è necessariamente migliore del C..
Detto così sembra peggìore di tutto :D. La complessità è un limite ma mi pare di capire che in parecchi tutto sommato l'hanno superata e hanno comunque ottenuto un saldo positivo...io stesso pur non avendo potuto applicarmici più di tanto e pertanto avendo "sofferto" a causa del C++ non posso negare di aver ottenuto qualche soddisfazione.
comunque sia anche parlando del C si può parlare di progresso perchè è uno standard che si è evoluto e si evolverà ancora probabilmente, ma non supporterà mai la programmazione OO, perchè non è il suo obiettivo. se vuoi programmare a oggetti usi un altro linguaggio.
e sono daccordo che la programmazione a oggetti è utile nella maggiorparte dei casi, ma non in tutti i casi.
dipende è la parola giusta. leggendo il documento linkato in precedenza mi vengono i brividi: un metodo non deve essere più lungo di 10 righe ecc.. mah
Il discorso per me è sempre quello: il C ha un ambito sempre più ristretto di applicazione e, tutto sommato, può ringraziare che l'assembly non è proprio immediato....
Dott.Wisem
19-09-2007, 19:01
Ti assicuro che lo ritrovi in diversi linguaggi. Probabilmente la scelta di ** è stata dettata proprio da questo motivo.Da una breve ricerca su google sono riuscito a trovare solo il Fortran che usa tale operatore per l'elevamento a potenza. Esistono linguaggi moderni (e diffusi) che lo usano, a parte il Python? In ogni caso, non mi piace. :p
Ecco, vedi: è un problema proprio di abitudine. Lo stesso si può dire per **: è abituale trovarlo in linguaggi che mettono a disposizione l'operatore di elevazione a potenza usando dei simboli. ;) Come ti ho detto nel post precedente, l'operatore '%', personalmente non mi piace, ma è diventato d'uso comune, quindi non si può dire che un codice che lo contiene sia poco leggibile (sebbene un'espressione che contenga 'mod' al posto di '%', sia oggettivamente più leggibile).
Il punto è che la leggibilità è influenzata dalla sintassi a cui si è abituati, in base alla diffusione dei linguaggi. Quindi, per me, un linguaggio leggibile, oggi, deve seguire quelle tradizioni sintattiche che permettano a chiunque abbia un minimo di conoscenze informatiche (anche scolastiche) di leggere e capire il senso di un pezzo di codice, senza troppi sforzi mentali (poco importa poi che questi sforzi siano legati ad un'abitudine verso certe consuetudini).
[...]Piuttosto che leggere il codice secondo un certo schema mentale, è meglio leggerlo parola (o simbolo) dopo parola, e ci si arriva velocemente al significato. :)Non puoi dare per scontato che sia così facile, soprattutto quando sei abituato fin dai tempi della scuola a leggere e scrivere codice in un certo modo, e i codici d'esempio che trovi sulle riviste, su internet, ecc., sono scritti usando i linguaggi classici. ;)
Ecco, vedi: è un problema proprio di abitudine. Lo stesso si può dire per **: è abituale trovarlo in linguaggi che mettono a disposizione l'operatore di elevazione a potenza usando dei simboli. ;) Come ti ho detto nel post precedente, l'operatore '%', personalmente non mi piace, ma è diventato d'uso comune, quindi non si può dire che un codice che lo contiene sia poco leggibile (sebbene un'espressione che contenga 'mod' al posto di '%', sia oggettivamente più leggibile).
Il punto è che la leggibilità è influenzata dalla sintassi a cui si è abituati, in base alla diffusione dei linguaggi. Quindi, per me, un linguaggio leggibile, oggi, deve seguire quelle tradizioni sintattiche che permettano a chiunque abbia un minimo di conoscenze informatiche (anche scolastiche) di leggere e capire il senso di un pezzo di codice, senza troppi sforzi mentali (poco importa poi che questi sforzi siano legati ad un'abitudine verso certe consuetudini).
[...]Piuttosto che leggere il codice secondo un certo schema mentale, è meglio leggerlo parola (o simbolo) dopo parola, e ci si arriva velocemente al significato. :)Non puoi dare per scontato che sia così facile, soprattutto quando sei abituato fin dai tempi della scuola a leggere e scrivere codice in un certo modo, e i codici d'esempio che trovi sulle riviste, su internet, ecc., sono scritti usando i linguaggi classici. ;)
dierre
19-09-2007, 19:38
Io non ho detto che il Python non sia un buon linguaggio, anche perché non l'ho mai usato e quindi non sono in grado di giudicarlo. Ho soltanto detto che quel codice che avevi postato è poco leggibile dal punto di vista di un programmatore abituato ad alcune convenzioni sintattiche che risalgono ai tempi del Basic (come, ad esempio, il ciclo for) e si sono poi diffuse, con delle leggere varianti sintattiche, anche in linguaggi molto più evoluti. Questo porta dei problemi nel momento in cui vuoi introdurre delle nuove persone nel team, in quanto queste persone, a meno che non siano già programmatori Python, devono entrare in una mentalità diversa, che non è necessariamente peggiore, ma che comunque ti fa perdere del tempo prezioso per un adeguato apprendimento, quando usando un linguaggio dalla sintassi più familiare, il problema non si sarebbe posto. Non fraintendermi, non sto dicendo che hai sbagliato a scegliere il Python per i tuoi progetti... Sicuramente avrai avuto le tue buone ragioni.[...]
Ti suggerisco di perderceli cinque minuti. Anch'io venivo da un background di tipo C, C++ etc...e una volta presa la mano col python, secondo me, è tutto molto più pulito e veloce da scrivere.
Che poi il python non sia la scelta adatta in alcuni casi è vero, ma non di certo per la sintassi che è davvero ben progettata.
Ti suggerisco di perderceli cinque minuti. Anch'io venivo da un background di tipo C, C++ etc...e una volta presa la mano col python, secondo me, è tutto molto più pulito e veloce da scrivere.
Che poi il python non sia la scelta adatta in alcuni casi è vero, ma non di certo per la sintassi che è davvero ben progettata.
cdimauro
19-09-2007, 20:02
E' ispirato alla notazione insiemistica "l'insieme di tutti i valori Numero^2 per Numero che sta nell'insieme Numeri".
Per chi ha un background matematico e' leggibilissimo. In haskell e' ancora piu' "intuitivo" (nel senso di vicino alla notazione matematica) :p :
quadrati = [ x ^ 2 | x <- [1..10] ]
cubi = [ x ^ 3 | x <- [1..] ]
La seconda tra l'altro ritorna l'insieme di tutti i cubi :eh: :D
Ehm... Per curiosità, dopo quanto si ferma?
Per chi ha un background matematico e' leggibilissimo. In haskell e' ancora piu' "intuitivo" (nel senso di vicino alla notazione matematica) :p :
quadrati = [ x ^ 2 | x <- [1..10] ]
cubi = [ x ^ 3 | x <- [1..] ]
La seconda tra l'altro ritorna l'insieme di tutti i cubi :eh: :D
Ehm... Per curiosità, dopo quanto si ferma?
cdimauro
19-09-2007, 20:14
Il discorso per me è sempre quello: il C ha un ambito sempre più ristretto di applicazione e, tutto sommato, può ringraziare che l'assembly non è proprio immediato....
Purtroppo questo è successo perché hanno costruito sempre gli assemblatori "a immagine" degli opcode delle istruzioni. :rolleyes:
Purtroppo questo è successo perché hanno costruito sempre gli assemblatori "a immagine" degli opcode delle istruzioni. :rolleyes:
cdimauro
19-09-2007, 20:37
Da una breve ricerca su google sono riuscito a trovare solo il Fortran che usa tale operatore per l'elevamento a potenza. Esistono linguaggi moderni (e diffusi) che lo usano, a parte il Python?
Dovrei cercare anch'io. Su Wikipedia ho trovato questo http://en.wikipedia.org/wiki/Operator_(programming) :
"The exponentiation operator (typically written as ^ or **) is often right associative."
ma non ci sono altre indicazioni utili.
In ogni caso, non mi piace. :pCome ti ho detto nel post precedente, l'operatore '%', personalmente non mi piace, ma è diventato d'uso comune, quindi non si può dire che un codice che lo contiene sia poco leggibile (sebbene un'espressione che contenga 'mod' al posto di '%', sia oggettivamente più leggibile).
E' poco leggibile per chi è digiuno di programmazione con linguaggi che non lo usano (ad esempio in Pascal si fa uso di mod).
In Python % viene usato come operatore di sostituzione in una stringa:
print 'Ciao %s, oggi è una %s giornata' % ('Pippo', 'bella')
restituisce:
Ciao Pippo, oggi è una bella giornata
;)
Il punto è che la leggibilità è influenzata dalla sintassi a cui si è abituati, in base alla diffusione dei linguaggi. Quindi, per me, un linguaggio leggibile, oggi, deve seguire quelle tradizioni sintattiche che permettano a chiunque abbia un minimo di conoscenze informatiche (anche scolastiche) di leggere e capire il senso di un pezzo di codice, senza troppi sforzi mentali (poco importa poi che questi sforzi siano legati ad un'abitudine verso certe consuetudini).
Esistono troppi linguaggi di programmazione: non se ne può prendere uno come "riferimento".
Ad esempio il Pascal è ancora molto diffuso nelle scuole, e gli operatori sono del tutto diversi da quelli del C (a parte quelli "fondamentali").
Non puoi dare per scontato che sia così facile, soprattutto quando sei abituato fin dai tempi della scuola a leggere e scrivere codice in un certo modo, e i codici d'esempio che trovi sulle riviste, su internet, ecc., sono scritti usando i linguaggi classici. ;)
Non lo do per scontato: mi sembra che, a parte l'uso dell'operatore **, la famigerata generator expression sia stata compresa anche da chi non ha mai visto Python.
Inoltre, come faceva notare marco.r, la sua sintassi magari rende più facile la vita a un matematico.
Comunque su Wikipedia ho trovato un link interessante riguardo l'espressività di un linguaggio di programmazione: http://en.wikipedia.org/wiki/Comparison_of_programming_languages#Expressiveness
Manco a dirlo, prendiamolo con le pinze, eh! :p
EDIT: trovato anche TCL con **. :D
Dovrei cercare anch'io. Su Wikipedia ho trovato questo http://en.wikipedia.org/wiki/Operator_(programming) :
"The exponentiation operator (typically written as ^ or **) is often right associative."
ma non ci sono altre indicazioni utili.
In ogni caso, non mi piace. :pCome ti ho detto nel post precedente, l'operatore '%', personalmente non mi piace, ma è diventato d'uso comune, quindi non si può dire che un codice che lo contiene sia poco leggibile (sebbene un'espressione che contenga 'mod' al posto di '%', sia oggettivamente più leggibile).
E' poco leggibile per chi è digiuno di programmazione con linguaggi che non lo usano (ad esempio in Pascal si fa uso di mod).
In Python % viene usato come operatore di sostituzione in una stringa:
print 'Ciao %s, oggi è una %s giornata' % ('Pippo', 'bella')
restituisce:
Ciao Pippo, oggi è una bella giornata
;)
Il punto è che la leggibilità è influenzata dalla sintassi a cui si è abituati, in base alla diffusione dei linguaggi. Quindi, per me, un linguaggio leggibile, oggi, deve seguire quelle tradizioni sintattiche che permettano a chiunque abbia un minimo di conoscenze informatiche (anche scolastiche) di leggere e capire il senso di un pezzo di codice, senza troppi sforzi mentali (poco importa poi che questi sforzi siano legati ad un'abitudine verso certe consuetudini).
Esistono troppi linguaggi di programmazione: non se ne può prendere uno come "riferimento".
Ad esempio il Pascal è ancora molto diffuso nelle scuole, e gli operatori sono del tutto diversi da quelli del C (a parte quelli "fondamentali").
Non puoi dare per scontato che sia così facile, soprattutto quando sei abituato fin dai tempi della scuola a leggere e scrivere codice in un certo modo, e i codici d'esempio che trovi sulle riviste, su internet, ecc., sono scritti usando i linguaggi classici. ;)
Non lo do per scontato: mi sembra che, a parte l'uso dell'operatore **, la famigerata generator expression sia stata compresa anche da chi non ha mai visto Python.
Inoltre, come faceva notare marco.r, la sua sintassi magari rende più facile la vita a un matematico.
Comunque su Wikipedia ho trovato un link interessante riguardo l'espressività di un linguaggio di programmazione: http://en.wikipedia.org/wiki/Comparison_of_programming_languages#Expressiveness
Manco a dirlo, prendiamolo con le pinze, eh! :p
EDIT: trovato anche TCL con **. :D
k0nt3
19-09-2007, 21:22
Meglio s.concat("Pippo"): append in genere lo si usa nelle liste. ;) E poi s.concat() in C non lo puoi rendere: ti servirebbe definire s come istanza di una classe, e ciò non è possibile.
Comunque su s == "Pippo" non hai detto niente, eh! Assumo che tu sia d'accordo con me. :D
in realtà con i puntatori a funzione è sempre possibile, ma non è immediato come avere a disposizione le classi. in C si scrive concat(s, "Pippo") al posto di s.concat("Pippo"), ma in sostanza non crolla il mondo.
se introduci l'overload degli operatori non fai altro che aggiungere un'ulteriore caratteristica ridondante.. programmo in java da un sacco di tempo e non ne ho mai sentito la mancanza (tranne all'inizio che ero abituato al C++)
cosa fa il C che C++ non fa?
è un linguaggio semplice
Il discorso per me è sempre quello: il C ha un ambito sempre più ristretto di applicazione e, tutto sommato, può ringraziare che l'assembly non è proprio immediato....
c'è stato un sondaggio qualche tempo fa.. il C dice ancora la sua. sicuramente verrà usato di meno in futuro, ma per fare certe cose rimarrà una buona scelta ancora per un pò
Comunque su s == "Pippo" non hai detto niente, eh! Assumo che tu sia d'accordo con me. :D
in realtà con i puntatori a funzione è sempre possibile, ma non è immediato come avere a disposizione le classi. in C si scrive concat(s, "Pippo") al posto di s.concat("Pippo"), ma in sostanza non crolla il mondo.
se introduci l'overload degli operatori non fai altro che aggiungere un'ulteriore caratteristica ridondante.. programmo in java da un sacco di tempo e non ne ho mai sentito la mancanza (tranne all'inizio che ero abituato al C++)
cosa fa il C che C++ non fa?
è un linguaggio semplice
Il discorso per me è sempre quello: il C ha un ambito sempre più ristretto di applicazione e, tutto sommato, può ringraziare che l'assembly non è proprio immediato....
c'è stato un sondaggio qualche tempo fa.. il C dice ancora la sua. sicuramente verrà usato di meno in futuro, ma per fare certe cose rimarrà una buona scelta ancora per un pò
atragon
19-09-2007, 21:37
Anche Ruby fa l'elevamento a potenza con **
dupa
19-09-2007, 21:59
Ah, e per te non lo sarebbe? Quindi con un linguaggio io posso fare TUTTO quello che fa un altro linguaggio e qualcosa in più, e per te non sarebbe migliore?
Se la pensi così penso sia inutile continuare la discussione, perché la cosa si commenta da sé... :rolleyes:
con Java si fanno meno cose di C++, ma l'utilizzo di Java è in crescita, quello di C++ in declino.
Se la pensi così penso sia inutile continuare la discussione, perché la cosa si commenta da sé... :rolleyes:
con Java si fanno meno cose di C++, ma l'utilizzo di Java è in crescita, quello di C++ in declino.
marco.r
19-09-2007, 22:06
Ehm... Per curiosità, dopo quanto si ferma?
Quando chi usa la lista finisce di usarla :D.
Haskell e' un linguaggio lazy, ovvero applicazioni di funzioni e strutture dati vengono calcolati "secondo necessità": la suscritta lista non viene elaborata tutta in un colpo ma man mano che i suoi elementi sono necessari. Da questo punto di vista somigliano piu' ai generatori di python che non alle sue liste.
do let x = [ x ^ 3 | x <- [1..] ]
print x
non si ferma mai, ma se io prendo i primi dieci elementi si'
do let x = take 10 $ [ x ^ 3 | x <- [1..] ]
print x
Ora in questo caso prendere 10 elementi da una lista infinita non ha piu' senso che trovare direttamente le potenze dai numeri da 1 a 10... immagina pero' di voler trovare il primo cubo che inizi con 7 e finisca con 4, non puoi sapere a priori quanti ne vuoi, per cui operi nel seguente modo
myCoolNumber = head $ filter ( startsWith 7 ) $ filter ( endsWith 4 ) [ x^3 | x <- [1..]]
where
startsWith n x = (show n) `isPrefixOf` (show x)
endsWith n x = x `mod` 10 == n
Tra l'altro quando "si scopre" che la prima riga va letta da destra a sinistra e' secondo me parecchio leggibile.
Si puo' fare pure in python, anche se non e' cosi' pulito:
def naturals():
n = 1
while True:
yield n
n+=1
cubes = ( x**3 for x in naturals() )
coolNumbers = ( x for x in cubes if str(x)[0] == '7' and str(x)[-1]=='4' )
myCoolNumber = coolNumbers.next()
Per inciso e' proprio questo secondo me uno dei maggiori pregi dei generatori, ovvero l'uso con sequenze indefinite, o che comunque non sono banali da calcolare. (Un altro buon esempio potrebbe essere un analizzatore lessicale).
Nel dei generatori di python pero' devo dire che l'idea di usare le parentesi al posto delle quadre non mi piace molto. Non solo nel 99% dei linguaggi servono solo per definire le precedenze (diciamo tutti tranne lisp e scheme :D), ma qui vengono usate in entrambi i modi, rendendo piu' difficile la lettura del codice.
Quando chi usa la lista finisce di usarla :D.
Haskell e' un linguaggio lazy, ovvero applicazioni di funzioni e strutture dati vengono calcolati "secondo necessità": la suscritta lista non viene elaborata tutta in un colpo ma man mano che i suoi elementi sono necessari. Da questo punto di vista somigliano piu' ai generatori di python che non alle sue liste.
do let x = [ x ^ 3 | x <- [1..] ]
print x
non si ferma mai, ma se io prendo i primi dieci elementi si'
do let x = take 10 $ [ x ^ 3 | x <- [1..] ]
print x
Ora in questo caso prendere 10 elementi da una lista infinita non ha piu' senso che trovare direttamente le potenze dai numeri da 1 a 10... immagina pero' di voler trovare il primo cubo che inizi con 7 e finisca con 4, non puoi sapere a priori quanti ne vuoi, per cui operi nel seguente modo
myCoolNumber = head $ filter ( startsWith 7 ) $ filter ( endsWith 4 ) [ x^3 | x <- [1..]]
where
startsWith n x = (show n) `isPrefixOf` (show x)
endsWith n x = x `mod` 10 == n
Tra l'altro quando "si scopre" che la prima riga va letta da destra a sinistra e' secondo me parecchio leggibile.
Si puo' fare pure in python, anche se non e' cosi' pulito:
def naturals():
n = 1
while True:
yield n
n+=1
cubes = ( x**3 for x in naturals() )
coolNumbers = ( x for x in cubes if str(x)[0] == '7' and str(x)[-1]=='4' )
myCoolNumber = coolNumbers.next()
Per inciso e' proprio questo secondo me uno dei maggiori pregi dei generatori, ovvero l'uso con sequenze indefinite, o che comunque non sono banali da calcolare. (Un altro buon esempio potrebbe essere un analizzatore lessicale).
Nel dei generatori di python pero' devo dire che l'idea di usare le parentesi al posto delle quadre non mi piace molto. Non solo nel 99% dei linguaggi servono solo per definire le precedenze (diciamo tutti tranne lisp e scheme :D), ma qui vengono usate in entrambi i modi, rendendo piu' difficile la lettura del codice.
cdimauro
19-09-2007, 22:24
in realtà con i puntatori a funzione è sempre possibile, ma non è immediato come avere a disposizione le classi. in C si scrive concat(s, "Pippo") al posto di s.concat("Pippo"), ma in sostanza non crolla il mondo.
C'è una bella differenza fra il metodo di una stringa e una chiamata a funzione che accetta eventualmente stringhe come parametri: nel primo caso codice e dati sono "legati", e pure il tipo nei linguaggi fortemente tipizzati (dove non può capitare di passare un puntatore a qualcosa che non sia del tipo che ci si aspetta).
se introduci l'overload degli operatori non fai altro che aggiungere un'ulteriore caratteristica ridondante..
Dipende da quello che devi fare.
programmo in java da un sacco di tempo e non ne ho mai sentito la mancanza (tranne all'inizio che ero abituato al C++)
Io sì.
è un linguaggio semplice
Piuttosto direi che è un linguaggio povero.
C'è una bella differenza fra il metodo di una stringa e una chiamata a funzione che accetta eventualmente stringhe come parametri: nel primo caso codice e dati sono "legati", e pure il tipo nei linguaggi fortemente tipizzati (dove non può capitare di passare un puntatore a qualcosa che non sia del tipo che ci si aspetta).
se introduci l'overload degli operatori non fai altro che aggiungere un'ulteriore caratteristica ridondante..
Dipende da quello che devi fare.
programmo in java da un sacco di tempo e non ne ho mai sentito la mancanza (tranne all'inizio che ero abituato al C++)
Io sì.
è un linguaggio semplice
Piuttosto direi che è un linguaggio povero.
cdimauro
19-09-2007, 22:26
con Java si fanno meno cose di C++, ma l'utilizzo di Java è in crescita, quello di C++ in declino.
Sulla prima frase ci sarebbe non poco da dire: cosa intendi con "meno cose"?
Comunque il confronto in particolare verteva su C e C++, e a quest'ultimo non manca nulla del primo.
Sulla prima frase ci sarebbe non poco da dire: cosa intendi con "meno cose"?
Comunque il confronto in particolare verteva su C e C++, e a quest'ultimo non manca nulla del primo.
marco.r
19-09-2007, 22:31
Io penso che la questione degli operatori e della loro sovrascrittura andrebbe risolta radicalmente introducendo la possibilità di usare qualsiasi carattere come identificatore di un metodo o di una funzione.
Per essere sintatticamente coerente, vale a dire per non introdurre forme diverse per operatori e metodi, noi dovremmo anche avvicinare la sintassi dell'invocazione di funzione/metodo con argomenti a quella degli operatori.
Esempio:
classe Numero
metodo + argomento { corpo del metodo }
metodo somma argomento { corpo del metodo }
la parte che sta tra "metodo" e "argomento" è l'identificatore e il ricevente (l'instanza usata per l'invocazione) è uno degli operandi.
Insomma, posso usare * come nome di un metodo e devo togliere le parentesi che racchiudono la lista di argomenti.
Ci sono lingue che permettono di usare qualsiasi simbolo come identificatore (ad esempio Scala) ma lo fanno introducendo regole in più per la valutazione delle espressioni che invocano metodo, onde evitare cose come:
numero.+(altro numero);
Concordo anche io sul fatto che idealmente gli operatori, se definibili, dovrebbero essere arbitrari. In caso contrario si finisce per riutilizzare quelli disponibili creando molta confusione (il C++ riesce a farlo addirittura nello standard :D).
Sono pero' dell'opinione che gli operatori dovrebbero rimanere sostanzialmente delle funzioni, e non dei metodi visto che in tutti i linguaggi che non forniscono i multimetodi (quindi praticamente tutti :D) esiste una asimmetria arbitraria tra il primo argomento (che e' l'istanza di invocazione) e il secondo (che diventa argomento del metodo ).
Per essere sintatticamente coerente, vale a dire per non introdurre forme diverse per operatori e metodi, noi dovremmo anche avvicinare la sintassi dell'invocazione di funzione/metodo con argomenti a quella degli operatori.
Esempio:
classe Numero
metodo + argomento { corpo del metodo }
metodo somma argomento { corpo del metodo }
la parte che sta tra "metodo" e "argomento" è l'identificatore e il ricevente (l'instanza usata per l'invocazione) è uno degli operandi.
Insomma, posso usare * come nome di un metodo e devo togliere le parentesi che racchiudono la lista di argomenti.
Ci sono lingue che permettono di usare qualsiasi simbolo come identificatore (ad esempio Scala) ma lo fanno introducendo regole in più per la valutazione delle espressioni che invocano metodo, onde evitare cose come:
numero.+(altro numero);
Concordo anche io sul fatto che idealmente gli operatori, se definibili, dovrebbero essere arbitrari. In caso contrario si finisce per riutilizzare quelli disponibili creando molta confusione (il C++ riesce a farlo addirittura nello standard :D).
Sono pero' dell'opinione che gli operatori dovrebbero rimanere sostanzialmente delle funzioni, e non dei metodi visto che in tutti i linguaggi che non forniscono i multimetodi (quindi praticamente tutti :D) esiste una asimmetria arbitraria tra il primo argomento (che e' l'istanza di invocazione) e il secondo (che diventa argomento del metodo ).
Dott.Wisem
19-09-2007, 22:32
[...]E' poco leggibile per chi è digiuno di programmazione con linguaggi che non lo usano (ad esempio in Pascal si fa uso di mod).Ma andiamo... Chi è quel programmatore che oggi non conosce la sintassi C-like (C/C++/Java/C# e tutte le varianti)?
In Python % viene usato come operatore di sostituzione in una stringa:
print 'Ciao %s, oggi è una %s giornata' % ('Pippo', 'bella')
restituisce:
Ciao Pippo, oggi è una bella giornata
E' certamente una questione di abitudine, ma una cosa del tipo:
s1 = "Pippo"
s2 = "bella"
print("Ciao " + s1 + ", oggi è una " + s2 + " giornata")
la capirebbe chiunque a volo, pur non conoscendo la sintassi di questo ipotetico linguaggio. Invece, quello che hai scritto tu richiede un certo sforzo. L'operatore %, ad esempio, viene usato in due modi diversi:
1) nella stringa, seguito da una s, per indicare che in quel punto ci deve andare una stringa;
2) alla fine del rigo, seguito da una coppia di stringhe, per indicare gli elementi da inserire nelle posizioni indicate al punto 1.
Questo già comporta uno sforzo mentale per capire che quell'operatore assume due significati diversi a seconda del contesto. Ciò è già sufficiente a minare la leggibilità.
Esistono troppi linguaggi di programmazione: non se ne può prendere uno come "riferimento".
Ad esempio il Pascal è ancora molto diffuso nelle scuole, e gli operatori sono del tutto diversi da quelli del C (a parte quelli "fondamentali").Se io dovessi creare un linguaggio di programmazione, partirei dalla sintassi del C, magari creando un linguaggio molto dinamico, con garbage collector, con gestione delle stringhe molto semplificata, con delle comode strutture dati per memorizzare degli insiemi anche eterogenei di dati, costrutti per facilitare il debugging ed il testing (Design By Contract), ecc., ovviamente object-oriented (o magari Aspect-Oriented). In questo modo mi attirerei i favori di una caterva enorme di programmatori abituati alla sintassi C-like e, senza eccessivi sforzi, imparerebbero ad apprezzare i costrutti aggiuntivi. ;)
Non lo do per scontato: mi sembra che, a parte l'uso dell'operatore **, la famigerata generator expression sia stata compresa anche da chi non ha mai visto Python.Si, dopo qualche contorsione mentale però, nel senso che non capisci a volo, ma devi rileggere diverse volte. :D
In Python % viene usato come operatore di sostituzione in una stringa:
print 'Ciao %s, oggi è una %s giornata' % ('Pippo', 'bella')
restituisce:
Ciao Pippo, oggi è una bella giornata
E' certamente una questione di abitudine, ma una cosa del tipo:
s1 = "Pippo"
s2 = "bella"
print("Ciao " + s1 + ", oggi è una " + s2 + " giornata")
la capirebbe chiunque a volo, pur non conoscendo la sintassi di questo ipotetico linguaggio. Invece, quello che hai scritto tu richiede un certo sforzo. L'operatore %, ad esempio, viene usato in due modi diversi:
1) nella stringa, seguito da una s, per indicare che in quel punto ci deve andare una stringa;
2) alla fine del rigo, seguito da una coppia di stringhe, per indicare gli elementi da inserire nelle posizioni indicate al punto 1.
Questo già comporta uno sforzo mentale per capire che quell'operatore assume due significati diversi a seconda del contesto. Ciò è già sufficiente a minare la leggibilità.
Esistono troppi linguaggi di programmazione: non se ne può prendere uno come "riferimento".
Ad esempio il Pascal è ancora molto diffuso nelle scuole, e gli operatori sono del tutto diversi da quelli del C (a parte quelli "fondamentali").Se io dovessi creare un linguaggio di programmazione, partirei dalla sintassi del C, magari creando un linguaggio molto dinamico, con garbage collector, con gestione delle stringhe molto semplificata, con delle comode strutture dati per memorizzare degli insiemi anche eterogenei di dati, costrutti per facilitare il debugging ed il testing (Design By Contract), ecc., ovviamente object-oriented (o magari Aspect-Oriented). In questo modo mi attirerei i favori di una caterva enorme di programmatori abituati alla sintassi C-like e, senza eccessivi sforzi, imparerebbero ad apprezzare i costrutti aggiuntivi. ;)
Non lo do per scontato: mi sembra che, a parte l'uso dell'operatore **, la famigerata generator expression sia stata compresa anche da chi non ha mai visto Python.Si, dopo qualche contorsione mentale però, nel senso che non capisci a volo, ma devi rileggere diverse volte. :D
dupa
19-09-2007, 22:35
Sulla prima frase ci sarebbe non poco da dire: cosa intendi con "meno cose"?
overloading operatori, ereditarietà multipla, ...
se il c++ ha più funzionalità del java perchè c'è sempre più gente che usa java e sempre meno che usa c++?
overloading operatori, ereditarietà multipla, ...
se il c++ ha più funzionalità del java perchè c'è sempre più gente che usa java e sempre meno che usa c++?
cdimauro
19-09-2007, 22:37
Quando chi usa la lista finisce di usarla :D.
Haskell e' un linguaggio lazy, ovvero applicazioni di funzioni e strutture dati vengono calcolati "secondo necessità": la suscritta lista non viene elaborata tutta in un colpo ma man mano che i suoi elementi sono necessari.
In questo caso penso non abbia senso estrarre la lunghezza della lista: suppongo che venga generata qualche eccezione a un certo punto.
Da questo punto di vista somigliano piu' ai generatori di python che non alle sue liste.
do let x = [ x ^ 3 | x <- [1..] ]
print x
non si ferma mai, ma se io prendo i primi dieci elementi si'
do let x = take 10 $ [ x ^ 3 | x <- [1..] ]
print x
Ora in questo caso prendere 10 elementi da una lista infinita non ha piu' senso che trovare direttamente le potenze dai numeri da 1 a 10... immagina pero' di voler trovare il primo cubo che inizi con 7 e finisca con 4, non puoi sapere a priori quanti ne vuoi, per cui operi nel seguente modo
myCoolNumber = head $ filter ( startsWith 7 ) $ filter ( startsWith 4 ) [ x^3 | x <- [1..]]
where
startsWith n x = (show n) `isPrefixOf` (show x)
endsWith n x = x `mod` 10 == n
Tra l'altro quando "si scopre" che la prima riga va letta da destra a sinistra e' secondo me parecchio leggibile.
Per un matematico. :p
Comunque non mi sembra difficile da leggere, considerando che in Python, oltre alla generator expression, c'è pure una funzione filter per filtrare i contenuti di una sequenza/lista/iteratore. :)
Si puo' fare pure in python, anche se non e' cosi' pulito:
def naturals():
n = 1
while True:
yield n
n+=1
cubes = ( x**3 for x in naturals() )
coolNumbers = ( x for x in cubes if str(x)[0] == '7' and str(x)[-1]=='4' )
myCoolNumber = coolNumbers.next()
Per inciso e' proprio questo secondo me uno dei maggiori pregi dei generatori, ovvero l'uso con sequenze indefinite, o che comunque non sono banali da calcolare. (Un altro buon esempio potrebbe essere un analizzatore lessicale).
Concordo.
Nel dei generatori di python pero' devo dire che l'idea di usare le parentesi al posto delle quadre non mi piace molto. Non solo nel 99% dei linguaggi servono solo per definire le precedenze (diciamo tutti tranne lisp e scheme :D), ma qui vengono usate in entrambi i modi, rendendo piu' difficile la lettura del codice.
Sarebbe stata necessaria un'altra coppia di simboli ([] sono riservate alle list comprehension e {} per i generatori di dizionario che verranno introdotti con Python 3.0) o un costrutto ad hoc.
In Python si cerca di non introdurre nuovi simboli o keyword nel linguaggio.
In questo caso la scelta delle parentesi tonde è stato un doloroso compromesso.
Haskell e' un linguaggio lazy, ovvero applicazioni di funzioni e strutture dati vengono calcolati "secondo necessità": la suscritta lista non viene elaborata tutta in un colpo ma man mano che i suoi elementi sono necessari.
In questo caso penso non abbia senso estrarre la lunghezza della lista: suppongo che venga generata qualche eccezione a un certo punto.
Da questo punto di vista somigliano piu' ai generatori di python che non alle sue liste.
do let x = [ x ^ 3 | x <- [1..] ]
print x
non si ferma mai, ma se io prendo i primi dieci elementi si'
do let x = take 10 $ [ x ^ 3 | x <- [1..] ]
print x
Ora in questo caso prendere 10 elementi da una lista infinita non ha piu' senso che trovare direttamente le potenze dai numeri da 1 a 10... immagina pero' di voler trovare il primo cubo che inizi con 7 e finisca con 4, non puoi sapere a priori quanti ne vuoi, per cui operi nel seguente modo
myCoolNumber = head $ filter ( startsWith 7 ) $ filter ( startsWith 4 ) [ x^3 | x <- [1..]]
where
startsWith n x = (show n) `isPrefixOf` (show x)
endsWith n x = x `mod` 10 == n
Tra l'altro quando "si scopre" che la prima riga va letta da destra a sinistra e' secondo me parecchio leggibile.
Per un matematico. :p
Comunque non mi sembra difficile da leggere, considerando che in Python, oltre alla generator expression, c'è pure una funzione filter per filtrare i contenuti di una sequenza/lista/iteratore. :)
Si puo' fare pure in python, anche se non e' cosi' pulito:
def naturals():
n = 1
while True:
yield n
n+=1
cubes = ( x**3 for x in naturals() )
coolNumbers = ( x for x in cubes if str(x)[0] == '7' and str(x)[-1]=='4' )
myCoolNumber = coolNumbers.next()
Per inciso e' proprio questo secondo me uno dei maggiori pregi dei generatori, ovvero l'uso con sequenze indefinite, o che comunque non sono banali da calcolare. (Un altro buon esempio potrebbe essere un analizzatore lessicale).
Concordo.
Nel dei generatori di python pero' devo dire che l'idea di usare le parentesi al posto delle quadre non mi piace molto. Non solo nel 99% dei linguaggi servono solo per definire le precedenze (diciamo tutti tranne lisp e scheme :D), ma qui vengono usate in entrambi i modi, rendendo piu' difficile la lettura del codice.
Sarebbe stata necessaria un'altra coppia di simboli ([] sono riservate alle list comprehension e {} per i generatori di dizionario che verranno introdotti con Python 3.0) o un costrutto ad hoc.
In Python si cerca di non introdurre nuovi simboli o keyword nel linguaggio.
In questo caso la scelta delle parentesi tonde è stato un doloroso compromesso.
cdimauro
19-09-2007, 22:46
Ma andiamo... Chi è quel programmatore che oggi non conosce la sintassi C-like (C/C++/Java/C# e tutte le varianti)?
Uno che a scuola ha imparato soltanto il Pascal e non ama smanettare a casa.
E' certamente una questione di abitudine, ma una cosa del tipo:
s1 = "Pippo"
s2 = "bella"
print("Ciao " + s1 + ", oggi è una " + s2 + " giornata")
la capirebbe chiunque a volo, pur non conoscendo la sintassi di questo ipotetico linguaggio.
Mettiamoci d'accordo però: il % come operatore non lo capirebbe nessuno né per il C né per il Python.
Invece, quello che hai scritto tu richiede un certo sforzo. L'operatore %, ad esempio, viene usato in due modi diversi:
1) nella stringa, seguito da una s, per indicare che in quel punto ci deve andare una stringa;
2) alla fine del rigo, seguito da una coppia di stringhe, per indicare gli elementi da inserire nelle posizioni indicate al punto 1.
Questo già comporta uno sforzo mentale per capire che quell'operatore assume due significati diversi a seconda del contesto. Ciò è già sufficiente a minare la leggibilità.
Per chi conosce il C no, perché conosce bene il significato di %s e sa che richiede la sostituzione con un parametro.
Se io dovessi creare un linguaggio di programmazione, partirei dalla sintassi del C, magari creando un linguaggio molto dinamico, con garbage collector, con gestione delle stringhe molto semplificata, con delle comode strutture dati per memorizzare degli insiemi anche eterogenei di dati, costrutti per facilitare il debugging ed il testing (Design By Contract), ecc., ovviamente object-oriented (o magari Aspect-Oriented). In questo modo mi attirerei i favori di una caterva enorme di programmatori abituati alla sintassi C-like e, senza eccessivi sforzi, imparerebbero ad apprezzare i costrutti aggiuntivi. ;)
Io sono un pascaliano, per cui non condivido affatto la scelta del linguaggio. :D
Infatti nei linguaggi che ho creato è evidentissima l'ispirazione di Pascal, Modula-2, ecc. :p
Si, dopo qualche contorsione mentale però, nel senso che non capisci a volo, ma devi rileggere diverse volte. :D
E' una questione personale. Vediamo cosa dicono gli altri in merito. ;)
Uno che a scuola ha imparato soltanto il Pascal e non ama smanettare a casa.
E' certamente una questione di abitudine, ma una cosa del tipo:
s1 = "Pippo"
s2 = "bella"
print("Ciao " + s1 + ", oggi è una " + s2 + " giornata")
la capirebbe chiunque a volo, pur non conoscendo la sintassi di questo ipotetico linguaggio.
Mettiamoci d'accordo però: il % come operatore non lo capirebbe nessuno né per il C né per il Python.
Invece, quello che hai scritto tu richiede un certo sforzo. L'operatore %, ad esempio, viene usato in due modi diversi:
1) nella stringa, seguito da una s, per indicare che in quel punto ci deve andare una stringa;
2) alla fine del rigo, seguito da una coppia di stringhe, per indicare gli elementi da inserire nelle posizioni indicate al punto 1.
Questo già comporta uno sforzo mentale per capire che quell'operatore assume due significati diversi a seconda del contesto. Ciò è già sufficiente a minare la leggibilità.
Per chi conosce il C no, perché conosce bene il significato di %s e sa che richiede la sostituzione con un parametro.
Se io dovessi creare un linguaggio di programmazione, partirei dalla sintassi del C, magari creando un linguaggio molto dinamico, con garbage collector, con gestione delle stringhe molto semplificata, con delle comode strutture dati per memorizzare degli insiemi anche eterogenei di dati, costrutti per facilitare il debugging ed il testing (Design By Contract), ecc., ovviamente object-oriented (o magari Aspect-Oriented). In questo modo mi attirerei i favori di una caterva enorme di programmatori abituati alla sintassi C-like e, senza eccessivi sforzi, imparerebbero ad apprezzare i costrutti aggiuntivi. ;)
Io sono un pascaliano, per cui non condivido affatto la scelta del linguaggio. :D
Infatti nei linguaggi che ho creato è evidentissima l'ispirazione di Pascal, Modula-2, ecc. :p
Si, dopo qualche contorsione mentale però, nel senso che non capisci a volo, ma devi rileggere diverse volte. :D
E' una questione personale. Vediamo cosa dicono gli altri in merito. ;)
k0nt3
19-09-2007, 22:50
io nasco pascaliano (autodidatta) :p ma assicuro tutti che ci vuole veramente poco a passare alla sintassi C-like
ci si abitua in poco tempo
ci si abitua in poco tempo
cdimauro
19-09-2007, 22:57
overloading operatori, ereditarietà multipla, ...
se il c++ ha più funzionalità del java perchè c'è sempre più gente che usa java e sempre meno che usa c++?
Tanto per fare un esempio, non mi sembra che il C++ abbia il supporto ai thread, come avviene in Java. E non è l'unica cosa che manca al C++. ;)
Poi Java si sta diffondendo perché è più semplice e "safe" lavorarci, visto che c'è un garbage collector e una VM che eseguono numerosi controlli.
se il c++ ha più funzionalità del java perchè c'è sempre più gente che usa java e sempre meno che usa c++?
Tanto per fare un esempio, non mi sembra che il C++ abbia il supporto ai thread, come avviene in Java. E non è l'unica cosa che manca al C++. ;)
Poi Java si sta diffondendo perché è più semplice e "safe" lavorarci, visto che c'è un garbage collector e una VM che eseguono numerosi controlli.
k0nt3
19-09-2007, 23:08
java però è senza dubbio più omogeneo del C++.. per ora :D
cdimauro
19-09-2007, 23:19
Mumble. In che senso?
k0nt3
19-09-2007, 23:20
Mumble. In che senso?
non supporta tanti stili e paradigmi diversi come il C++
non supporta tanti stili e paradigmi diversi come il C++
jappilas
19-09-2007, 23:23
Pork. Vabbé, contatto Marco in PVT e vediamo se riesce a recuperarlo.scusa, oggi pomeriggio non ero granchè presente... stavo studiando la documentazione di alcune librerie Boost, per poi capitare sulle novità in arrivo tra un paio d' anni 2009 con il C++0x
garbage collection trasparente, threading e TLS, range nei cicli for, modificatori future (chiamate asincrone di funzioni), volatile (che diventerebbe un metodo di vera e propria sincronizzazione tra thread), atomic (operazioni non preemptable), espressioni lambda e unnamed functions, nonchè un revamping del sistema a template con template aliasing, extern templates, concept con templating ed eredità dei concept, template a numero di parametri variabile con operatore ..., type traits - abbastanza per portare la complessità del nostro linguaggio preferito a nuove vette... :D
comunque venendo temporaneamente a DC, questo il contenuto nel repository attuale su sourceforge
http://diamondcrush.svn.sourceforge.net/viewvc/diamondcrush/branches/ , per quanto ricordo le cartelle sono le stesse presenti sui server NSN prima della migrazione del codice :stordita:
Grazie e scusate l'OT. :Dnon ci sono scuse per un off topic del genere, indi per cui verrai fustigato come si conviene :O
( scherzo :D)
garbage collection trasparente, threading e TLS, range nei cicli for, modificatori future (chiamate asincrone di funzioni), volatile (che diventerebbe un metodo di vera e propria sincronizzazione tra thread), atomic (operazioni non preemptable), espressioni lambda e unnamed functions, nonchè un revamping del sistema a template con template aliasing, extern templates, concept con templating ed eredità dei concept, template a numero di parametri variabile con operatore ..., type traits - abbastanza per portare la complessità del nostro linguaggio preferito a nuove vette... :D
comunque venendo temporaneamente a DC, questo il contenuto nel repository attuale su sourceforge
http://diamondcrush.svn.sourceforge.net/viewvc/diamondcrush/branches/ , per quanto ricordo le cartelle sono le stesse presenti sui server NSN prima della migrazione del codice :stordita:
Grazie e scusate l'OT. :Dnon ci sono scuse per un off topic del genere, indi per cui verrai fustigato come si conviene :O
( scherzo :D)
cdimauro
19-09-2007, 23:25
non supporta tanti stili e paradigmi diversi come il C++
Da questo punto di vista hai ragione. :)
Da questo punto di vista hai ragione. :)
cdimauro
19-09-2007, 23:27
scusa, oggi pomeriggio non ero granchè presente... stavo studiando la documentazione di alcune librerie Boost, per poi capitare sulle novità in arrivo tra un paio d' anni 2009 con il C++0x
garbage collection trasparente, threading e TLS, modficatori future (chiamate asincrone di funzioni), volatile (che diventerebbe un metodo di vera e propria sincronizzazione tra thread), atomic (operazioni non preemptable), espressioni lambda e unnamed functions, nonchè un revamping del sistema a template con template aliasing, extern templates, concept con templating ed eredità dei concept, template a numero di parametri variabile e operatore ... - abbastanza per portare la complessità del linguaggio a nuovi livelli... :D
Un altro buon motivo per NON lavorare con questo linguaggio. :p
non ci sono scuse per un off topic del genere, indi per cui verrai fustigato come si conviene :O
( scherzo :D)
Ci sentiamo via MSN in questi giorni. :)
garbage collection trasparente, threading e TLS, modficatori future (chiamate asincrone di funzioni), volatile (che diventerebbe un metodo di vera e propria sincronizzazione tra thread), atomic (operazioni non preemptable), espressioni lambda e unnamed functions, nonchè un revamping del sistema a template con template aliasing, extern templates, concept con templating ed eredità dei concept, template a numero di parametri variabile e operatore ... - abbastanza per portare la complessità del linguaggio a nuovi livelli... :D
Un altro buon motivo per NON lavorare con questo linguaggio. :p
non ci sono scuse per un off topic del genere, indi per cui verrai fustigato come si conviene :O
( scherzo :D)
Ci sentiamo via MSN in questi giorni. :)
bist
20-09-2007, 00:43
Ma andiamo... Chi è quel programmatore che oggi non conosce la sintassi C-like (C/C++/Java/C# e tutte le varianti)?E' certamente una questione di abitudine, ma una cosa del tipo:
s1 = "Pippo"
s2 = "bella"
print("Ciao " + s1 + ", oggi è una " + s2 + " giornata")
la capirebbe chiunque a volo, pur non conoscendo la sintassi di questo ipotetico linguaggio. Invece, quello che hai scritto tu richiede un certo sforzo.
Sono d'accordo.
Se io dovessi creare un linguaggio di programmazione, partirei dalla sintassi del C, magari creando un linguaggio molto dinamico, con garbage collector, con gestione delle stringhe molto semplificata, con delle comode strutture dati per memorizzare degli insiemi anche eterogenei di dati, costrutti per facilitare il debugging ed il testing (Design By Contract), ecc., ovviamente object-oriented (o magari Aspect-Oriented). In questo modo mi attirerei i favori di una caterva enorme di programmatori abituati alla sintassi C-like e, senza eccessivi sforzi, imparerebbero ad apprezzare i costrutti aggiuntivi. ;)Si, dopo qualche contorsione mentale però, nel senso che non capisci a volo, ma devi rileggere diverse volte. :D
Mi sa che un paio di aziende ti hanno già rubato l'idea : )
s1 = "Pippo"
s2 = "bella"
print("Ciao " + s1 + ", oggi è una " + s2 + " giornata")
la capirebbe chiunque a volo, pur non conoscendo la sintassi di questo ipotetico linguaggio. Invece, quello che hai scritto tu richiede un certo sforzo.
Sono d'accordo.
Se io dovessi creare un linguaggio di programmazione, partirei dalla sintassi del C, magari creando un linguaggio molto dinamico, con garbage collector, con gestione delle stringhe molto semplificata, con delle comode strutture dati per memorizzare degli insiemi anche eterogenei di dati, costrutti per facilitare il debugging ed il testing (Design By Contract), ecc., ovviamente object-oriented (o magari Aspect-Oriented). In questo modo mi attirerei i favori di una caterva enorme di programmatori abituati alla sintassi C-like e, senza eccessivi sforzi, imparerebbero ad apprezzare i costrutti aggiuntivi. ;)Si, dopo qualche contorsione mentale però, nel senso che non capisci a volo, ma devi rileggere diverse volte. :D
Mi sa che un paio di aziende ti hanno già rubato l'idea : )
Dott.Wisem
20-09-2007, 00:47
Uno che a scuola ha imparato soltanto il Pascal e non ama smanettare a casa.Ma è estremamente difficile che un programmatore serio conosca solo il Pascal. Comunque, anche io a scuola ebbi a che fare solo col Pascal, ma all'Università imparai il C, poi il C++ e poi il Java, quindi sono molto abituato alle sintassi C-like...
Mettiamoci d'accordo però: il % come operatore non lo capirebbe nessuno né per il C né per il Python.Infatti ho detto che preferisco 'mod'. ;)
Per chi conosce il C no, perché conosce bene il significato di %s e sa che richiede la sostituzione con un parametro.Beh, chi conosce il C viene un po' intimorito da quel % seguito da una coppia di stringhe racchiusa da parentesi tonde... Poi, ovviamente, capisce.
Io sono un pascaliano, per cui non condivido affatto la scelta del linguaggio. :DNon so perché, ma avevo intuito che lo fossi... :D
Mettiamoci d'accordo però: il % come operatore non lo capirebbe nessuno né per il C né per il Python.Infatti ho detto che preferisco 'mod'. ;)
Per chi conosce il C no, perché conosce bene il significato di %s e sa che richiede la sostituzione con un parametro.Beh, chi conosce il C viene un po' intimorito da quel % seguito da una coppia di stringhe racchiusa da parentesi tonde... Poi, ovviamente, capisce.
Io sono un pascaliano, per cui non condivido affatto la scelta del linguaggio. :DNon so perché, ma avevo intuito che lo fossi... :D
cdimauro
20-09-2007, 08:41
Ma è estremamente difficile che un programmatore serio conosca solo il Pascal.
Infatti un programmatore serio NON dovrebbe conoscere il C. :D
Comunque, anche io a scuola ebbi a che fare solo col Pascal, ma all'Università imparai il C, poi il C++ e poi il Java, quindi sono molto abituato alle sintassi C-like...
Idem. Purtroppo giocoforza prima o poi ci sei costretto a sbattere.
Non so perché, ma avevo intuito che lo fossi... :D
Diciamo che preferisco i linguaggi con sintassi più chiara / autoesplicativa e il C non ci rientra proprio, specialmente per l'elevato numero di operatori che fanno uso di simboli.
Infatti un programmatore serio NON dovrebbe conoscere il C. :D
Comunque, anche io a scuola ebbi a che fare solo col Pascal, ma all'Università imparai il C, poi il C++ e poi il Java, quindi sono molto abituato alle sintassi C-like...
Idem. Purtroppo giocoforza prima o poi ci sei costretto a sbattere.
Non so perché, ma avevo intuito che lo fossi... :D
Diciamo che preferisco i linguaggi con sintassi più chiara / autoesplicativa e il C non ci rientra proprio, specialmente per l'elevato numero di operatori che fanno uso di simboli.
cionci
20-09-2007, 09:17
se introduci l'overload degli operatori non fai altro che aggiungere un'ulteriore caratteristica ridondante.. programmo in java da un sacco di tempo e non ne ho mai sentito la mancanza (tranne all'inizio che ero abituato al C++)
L'overload è uno strumento imho da evitare quando possibile, ma può essere molto utile.
Pensa ad esempio ad un metodo template che mi dice fra due entità quale è la più grande (ad esempio mi può servire in un sort come funzione per ordinare le entità). Se io voglio che la mia classe template mi ordini indistintamente interi, floating point...ma anche matrici (ad esempio per modulo), l'overloading diventa molto utile.
Secondo me è molto utile anche l'overloading dell'operatore <<.
L'overload è uno strumento imho da evitare quando possibile, ma può essere molto utile.
Pensa ad esempio ad un metodo template che mi dice fra due entità quale è la più grande (ad esempio mi può servire in un sort come funzione per ordinare le entità). Se io voglio che la mia classe template mi ordini indistintamente interi, floating point...ma anche matrici (ad esempio per modulo), l'overloading diventa molto utile.
Secondo me è molto utile anche l'overloading dell'operatore <<.
k0nt3
20-09-2007, 10:40
cionci in java non ci sono ne i template (al massimo ci sono i generics ma poi PGI-Bis mi picchia :stordita: ) ne l'overload degli operatori, eppure operazioni come quella che hai descritto sono all'ordine del giorno.
nell'esempio che hai fatto te è sufficiente che tutte le classi ereditino da Number.
nel caso della matrice non ho capito cosa intendi per modulo.. se è il determinante allora è matrice.getDeterminant() che deve essere un'istanza di Number, e se invece vuoi tenere l'informazione che questo numero deriva da una matrice puoi sempre creare una nuova classe che ad esempio si chiama Determinant e eredita da Number. ogni scelta di nome stupido è puramente casuale :D
nell'esempio che hai fatto te è sufficiente che tutte le classi ereditino da Number.
nel caso della matrice non ho capito cosa intendi per modulo.. se è il determinante allora è matrice.getDeterminant() che deve essere un'istanza di Number, e se invece vuoi tenere l'informazione che questo numero deriva da una matrice puoi sempre creare una nuova classe che ad esempio si chiama Determinant e eredita da Number. ogni scelta di nome stupido è puramente casuale :D
Dott.Wisem
20-09-2007, 11:02
Infatti un programmatore serio NON dovrebbe conoscere il C. :DUno che al giorno d'oggi non conosce il C, per me non è neanche definibile 'programmatore'. :D Lo trovi praticamente dappertutto: nelle API dei sistemi operativi (unix-like e windows-like), nei tutorial, nei testi accademici, negli articoli scientifici, ecc., senza contare che la sua sintassi ha ispirato tanti altri linguaggi di successo.
Diciamo che preferisco i linguaggi con sintassi più chiara / autoesplicativa e il C non ci rientra proprio, specialmente per l'elevato numero di operatori che fanno uso di simboli.Anche io la pensavo così, quando non ero abituato alla sua sintassi. Poi, col tempo, si impara ad apprezzarne la sua sinteticità che, paradossalmente, è in grado di aumentare la chiarezza e velocità di comprensione del codice rispetto a linguaggi sintatticamente più prolissi. Ovviamente, in questo, la sua diffusione ha giocato un ruolo fondamentale.
Diciamo che preferisco i linguaggi con sintassi più chiara / autoesplicativa e il C non ci rientra proprio, specialmente per l'elevato numero di operatori che fanno uso di simboli.Anche io la pensavo così, quando non ero abituato alla sua sintassi. Poi, col tempo, si impara ad apprezzarne la sua sinteticità che, paradossalmente, è in grado di aumentare la chiarezza e velocità di comprensione del codice rispetto a linguaggi sintatticamente più prolissi. Ovviamente, in questo, la sua diffusione ha giocato un ruolo fondamentale.
cdimauro
20-09-2007, 11:42
cionci in java non ci sono ne i template (al massimo ci sono i generics ma poi PGI-Bis mi picchia :stordita: ) ne l'overload degli operatori, eppure operazioni come quella che hai descritto sono all'ordine del giorno.
nell'esempio che hai fatto te è sufficiente che tutte le classi ereditino da Number.
nel caso della matrice non ho capito cosa intendi per modulo.. se è il determinante allora è matrice.getDeterminant() che deve essere un'istanza di Number, e se invece vuoi tenere l'informazione che questo numero deriva da una matrice puoi sempre creare una nuova classe che ad esempio si chiama Determinant e eredita da Number. ogni scelta di nome stupido è puramente casuale :D
Ma vuoi mettere scrivere A = B * 5; con B matrice (dello stesso tipo di A)? Mi sembra MOOOOOLTO più facile da capire. ;)
Per il determinante vedrei bene un A.Determinante, visto che il determinante è una proprietà delle matrici (ovviamente se la matrice è quadrata).
nell'esempio che hai fatto te è sufficiente che tutte le classi ereditino da Number.
nel caso della matrice non ho capito cosa intendi per modulo.. se è il determinante allora è matrice.getDeterminant() che deve essere un'istanza di Number, e se invece vuoi tenere l'informazione che questo numero deriva da una matrice puoi sempre creare una nuova classe che ad esempio si chiama Determinant e eredita da Number. ogni scelta di nome stupido è puramente casuale :D
Ma vuoi mettere scrivere A = B * 5; con B matrice (dello stesso tipo di A)? Mi sembra MOOOOOLTO più facile da capire. ;)
Per il determinante vedrei bene un A.Determinante, visto che il determinante è una proprietà delle matrici (ovviamente se la matrice è quadrata).
cdimauro
20-09-2007, 11:47
Uno che al giorno d'oggi non conosce il C, per me non è neanche definibile 'programmatore'. :D Lo trovi praticamente dappertutto: nelle API dei sistemi operativi (unix-like e windows-like), nei tutorial, nei testi accademici, negli articoli scientifici, ecc., senza contare che la sua sintassi ha ispirato tanti altri linguaggi di successo.
Non metto in dubbio che sia molto diffuso e usato.
Anche io la pensavo così, quando non ero abituato alla sua sintassi. Poi, col tempo, si impara ad apprezzarne la sua sinteticità che, paradossalmente, è in grado di aumentare la chiarezza e velocità di comprensione del codice rispetto a linguaggi sintatticamente più prolissi. Ovviamente, in questo, la sua diffusione ha giocato un ruolo fondamentale.
Ho lavorato parecchio tempo col C, più raramente con Java, qualche volta con C++ e PHP, ma non mi sono mai, e dico proprio mai, abituato alla loro orribile sintassi: per i miei gusti è troppo poco leggibile, in particolare a causa degli operatori.
Con Pascal, Delphi et similia, invece, possono passare anche gli anni, ma appena mi trovo davanti a un sorgente scritto con uno di questi linguaggi mi sento a casa mia. Anche didatticamente li trovo di gran lunga preferibili.
Purtroppo sono i linguaggi C-like che si sono diffusi.
Non metto in dubbio che sia molto diffuso e usato.
Anche io la pensavo così, quando non ero abituato alla sua sintassi. Poi, col tempo, si impara ad apprezzarne la sua sinteticità che, paradossalmente, è in grado di aumentare la chiarezza e velocità di comprensione del codice rispetto a linguaggi sintatticamente più prolissi. Ovviamente, in questo, la sua diffusione ha giocato un ruolo fondamentale.
Ho lavorato parecchio tempo col C, più raramente con Java, qualche volta con C++ e PHP, ma non mi sono mai, e dico proprio mai, abituato alla loro orribile sintassi: per i miei gusti è troppo poco leggibile, in particolare a causa degli operatori.
Con Pascal, Delphi et similia, invece, possono passare anche gli anni, ma appena mi trovo davanti a un sorgente scritto con uno di questi linguaggi mi sento a casa mia. Anche didatticamente li trovo di gran lunga preferibili.
Purtroppo sono i linguaggi C-like che si sono diffusi.
cionci
20-09-2007, 11:50
nel caso della matrice non ho capito cosa intendi per modulo..
Sì :doh: Determinante...non perché ho scritto modulo...
Comunque...guarda:
template <class T>
class VectorSorter
{
private:
VectorSorter() {};
static bool descendingCompare(const T &a, const T &b) { return a > b; };
public:
static void sortAscending(vector<T> &v) { sort(v.begin(), v.end(), VectorSorter<T>::descendingCompare); };
static void sortDescending(vector<T> &v) { sort(v.begin(), v.end()); };
};
Questo mi ordina per e mele per peso, tipi base, classi, basta aver definito gli operatori maggiore e minore. Magari lasciate perdere l'utilità dell'avere tutti metodi static...è solo un esempio.
Non dico che in Java non si possa fare, ma hai chiesto a cosa serva la possibilità di fare overloading degli operatori in C++ ed io ti ho risposto.
Sì :doh: Determinante...non perché ho scritto modulo...
Comunque...guarda:
template <class T>
class VectorSorter
{
private:
VectorSorter() {};
static bool descendingCompare(const T &a, const T &b) { return a > b; };
public:
static void sortAscending(vector<T> &v) { sort(v.begin(), v.end(), VectorSorter<T>::descendingCompare); };
static void sortDescending(vector<T> &v) { sort(v.begin(), v.end()); };
};
Questo mi ordina per e mele per peso, tipi base, classi, basta aver definito gli operatori maggiore e minore. Magari lasciate perdere l'utilità dell'avere tutti metodi static...è solo un esempio.
Non dico che in Java non si possa fare, ma hai chiesto a cosa serva la possibilità di fare overloading degli operatori in C++ ed io ti ho risposto.
k0nt3
20-09-2007, 12:11
Ma vuoi mettere scrivere A = B * 5; con B matrice (dello stesso tipo di A)? Mi sembra MOOOOOLTO più facile da capire. ;)
Per il determinante vedrei bene un A.Determinante, visto che il determinante è una proprietà delle matrici (ovviamente se la matrice è quadrata).
non è così semplice.. ci sono vari tipi di moltiplicazione nelle matrici http://en.wikipedia.org/wiki/Matrix_multiplication
a quale si dovrebbe fare riferimento? a quella più comune? e se mi serve un altro tipo di moltiplicazione che simbolo uso? questo è un caso in cui l'overload degli operatori introduce disomogeneità nel linguaggio, non ha senso usare l'operatore * per la moltiplicazione classica tra matrici e poi dei comuni metodi per le altre moltiplicazioni.
ti assicuro che poi A.multiply(B) non ha niente da invidiare a A*B come leggibilità. al massimo è più lungo da scrivere ma finisce lì la questione.
per quanto riguarda le proprietà io continuo a non vederle di buon occhio perchè sono un modo per nascondere l'operato del codice e questo per me è un male. preferisco getters e setters che mi dicono esplicitamente cosa sta succedendo, mi sa che qui sei te che non sei abituato, perchè ti assicuro che la comodità non ne risente minimamente (ma anche la leggibilità)
Per il determinante vedrei bene un A.Determinante, visto che il determinante è una proprietà delle matrici (ovviamente se la matrice è quadrata).
non è così semplice.. ci sono vari tipi di moltiplicazione nelle matrici http://en.wikipedia.org/wiki/Matrix_multiplication
a quale si dovrebbe fare riferimento? a quella più comune? e se mi serve un altro tipo di moltiplicazione che simbolo uso? questo è un caso in cui l'overload degli operatori introduce disomogeneità nel linguaggio, non ha senso usare l'operatore * per la moltiplicazione classica tra matrici e poi dei comuni metodi per le altre moltiplicazioni.
ti assicuro che poi A.multiply(B) non ha niente da invidiare a A*B come leggibilità. al massimo è più lungo da scrivere ma finisce lì la questione.
per quanto riguarda le proprietà io continuo a non vederle di buon occhio perchè sono un modo per nascondere l'operato del codice e questo per me è un male. preferisco getters e setters che mi dicono esplicitamente cosa sta succedendo, mi sa che qui sei te che non sei abituato, perchè ti assicuro che la comodità non ne risente minimamente (ma anche la leggibilità)
cionci
20-09-2007, 12:26
non è così semplice.. ci sono vari tipi di moltiplicazione nelle matrici http://en.wikipedia.org/wiki/Matrix_multiplication
Le altre guarda si usano davvero raramente...
Le altre guarda si usano davvero raramente...
k0nt3
20-09-2007, 12:27
Sì :doh: Determinante...non perché ho scritto modulo...
Comunque...guarda:
template <class T>
class VectorSorter
{
private:
VectorSorter() {};
static bool descendingCompare(const T &a, const T &b) { return a > b; };
public:
static void sortAscending(vector<T> &v) { sort(v.begin(), v.end(), VectorSorter<T>::descendingCompare); };
static void sortDescending(vector<T> &v) { sort(v.begin(), v.end()); };
};
Questo mi ordina per e mele per peso, tipi base, classi, basta aver definito gli operatori maggiore e minore. Magari lasciate perdere l'utilità dell'avere tutti metodi static...è solo un esempio.
Non dico che in Java non si possa fare, ma hai chiesto a cosa serva la possibilità di fare overloading degli operatori in C++ ed io ti ho risposto.
il problema qui è evidente.. C++ con i suoi costrutti ultrapotenti ti spinge a saltare dei passaggi senza però ottenere qualche vantaggio.
con il codice che hai postato potresti ottenere dei risultati non voluti nel caso in cui l'operatore > (in questo esempio) può essere definito in più modi.
java ha il grande pregio di far ragionare di più il programmatore sul design del codice e questo è di valore inestimabile confronto a digitare 4 caratteri in meno.
prendi l'esempio delle mele e pere.. che senso ha dire pera > mela? ha molto più senso dire mela.getWeight() > pera.getWeight() oppure mela.getCalories() > pera.getCalories()
a questo punto è chiaro che è superfluo definire gli operatori.. si tratta sempre di qualcosa che è costruito a partire dagli operatori già esistenti.
per riprendere il tuo esempio basterebbe che tutte le classi ereditassero da un'interfaccia comune che richiede il metodo getValue()
a quel punto si può usare l'operatore > o < come è definito per il tipo che ritorna getValue() che può essere un intero o qualsiasi altro numero.
questo esempio è solo un'idea.. magari qualcuno può avere idee migliori, sta di fatto che ragionandoci un pò l'overload degli operatori ha più svantaggi che vantaggi
Comunque...guarda:
template <class T>
class VectorSorter
{
private:
VectorSorter() {};
static bool descendingCompare(const T &a, const T &b) { return a > b; };
public:
static void sortAscending(vector<T> &v) { sort(v.begin(), v.end(), VectorSorter<T>::descendingCompare); };
static void sortDescending(vector<T> &v) { sort(v.begin(), v.end()); };
};
Questo mi ordina per e mele per peso, tipi base, classi, basta aver definito gli operatori maggiore e minore. Magari lasciate perdere l'utilità dell'avere tutti metodi static...è solo un esempio.
Non dico che in Java non si possa fare, ma hai chiesto a cosa serva la possibilità di fare overloading degli operatori in C++ ed io ti ho risposto.
il problema qui è evidente.. C++ con i suoi costrutti ultrapotenti ti spinge a saltare dei passaggi senza però ottenere qualche vantaggio.
con il codice che hai postato potresti ottenere dei risultati non voluti nel caso in cui l'operatore > (in questo esempio) può essere definito in più modi.
java ha il grande pregio di far ragionare di più il programmatore sul design del codice e questo è di valore inestimabile confronto a digitare 4 caratteri in meno.
prendi l'esempio delle mele e pere.. che senso ha dire pera > mela? ha molto più senso dire mela.getWeight() > pera.getWeight() oppure mela.getCalories() > pera.getCalories()
a questo punto è chiaro che è superfluo definire gli operatori.. si tratta sempre di qualcosa che è costruito a partire dagli operatori già esistenti.
per riprendere il tuo esempio basterebbe che tutte le classi ereditassero da un'interfaccia comune che richiede il metodo getValue()
a quel punto si può usare l'operatore > o < come è definito per il tipo che ritorna getValue() che può essere un intero o qualsiasi altro numero.
questo esempio è solo un'idea.. magari qualcuno può avere idee migliori, sta di fatto che ragionandoci un pò l'overload degli operatori ha più svantaggi che vantaggi
k0nt3
20-09-2007, 12:29
Le altre guarda si usano davvero raramente...
oddio.. e se hai due vettori? usi il classico prodotto o il prodotto vettoriale?
oddio.. e se hai due vettori? usi il classico prodotto o il prodotto vettoriale?
cionci
20-09-2007, 12:30
oddio.. e se hai due vettori? usi il classico prodotto o il prodotto vettoriale?
Si usano simboli diversi anche nello scrivere le operazioni su carta...
Si usano simboli diversi anche nello scrivere le operazioni su carta...
k0nt3
20-09-2007, 12:33
ma non si può fare l'overload dell'operatore x in C++ o si?
e se non si può il codice perde un pò di omogeneità :fagiano:
tutto IMHO ovviamente :p sto solo cercando di capire perchè io da quando uso java non ho mai avuto bisogno di definire un operatore
e se non si può il codice perde un pò di omogeneità :fagiano:
tutto IMHO ovviamente :p sto solo cercando di capire perchè io da quando uso java non ho mai avuto bisogno di definire un operatore
cionci
20-09-2007, 12:36
java ha il grande pregio di far ragionare di più il programmatore sul design del codice e questo è di valore inestimabile confronto a digitare 4 caratteri in meno.
prendi l'esempio delle mele e pere.. che senso ha dire pera > mela? ha molto più senso dire mela.getWeight() > pera.getWeight() oppure mela.getCalories() > pera.getCalories()
Chi ha mai detto di fare pera > mela...io intendevo pera1 > pera2...
Riguardo a come questo confronto con l'operatore venga fatto dobbiamo affidarci a chi ha scritto la classe. Lui ci ha fornito questo metodo di confronto (nella documentazione sicuramente ci sarà scritto), niente vieta, se vogliamo farne un altro, basandoci su nostri metodi di confronto.
a questo punto è chiaro che è superfluo definire gli operatori.. si tratta sempre di qualcosa che è costruito a partire dagli operatori già esistenti.
per riprendere il tuo esempio basterebbe che tutte le classi ereditassero da un'interfaccia comune che richiede il metodo getValue()
Più vantaggi che svantaggi ? In questo caso no, perché non funzionerebbe con i tipi base ;)
Visto che stai ritornando a come è organizzato Java...come lo faresti con Java in modo che sia compatibile anche con i tipi base ?
prendi l'esempio delle mele e pere.. che senso ha dire pera > mela? ha molto più senso dire mela.getWeight() > pera.getWeight() oppure mela.getCalories() > pera.getCalories()
Chi ha mai detto di fare pera > mela...io intendevo pera1 > pera2...
Riguardo a come questo confronto con l'operatore venga fatto dobbiamo affidarci a chi ha scritto la classe. Lui ci ha fornito questo metodo di confronto (nella documentazione sicuramente ci sarà scritto), niente vieta, se vogliamo farne un altro, basandoci su nostri metodi di confronto.
a questo punto è chiaro che è superfluo definire gli operatori.. si tratta sempre di qualcosa che è costruito a partire dagli operatori già esistenti.
per riprendere il tuo esempio basterebbe che tutte le classi ereditassero da un'interfaccia comune che richiede il metodo getValue()
Più vantaggi che svantaggi ? In questo caso no, perché non funzionerebbe con i tipi base ;)
Visto che stai ritornando a come è organizzato Java...come lo faresti con Java in modo che sia compatibile anche con i tipi base ?
cionci
20-09-2007, 12:41
ma non si può fare l'overload dell'operatore x in C++ o si?
e se non si può il codice perde un pò di omogeneità :fagiano:
tutto IMHO ovviamente :p sto solo cercando di capire perchè io da quando uso java non ho mai avuto bisogno di definire un operatore
E che c'entra questo ? Vorresti dire che se avessi un metodo di definire tutti gli operatori che vuoi allora la possibilità di avere l'overloading degli operatori è un bene, mentre se sei limitato agli operatori definiti dal linguaggio è un male ?
Secondo me non è vero che perde di omogeneità, se io faccio:
A = Z.scalarMultiply(B * C + D);
non vedo alcuna perdita di omogenità. Tra l'altro anche Matlab non ha un'operatore per tutte le operazioni permesse con le matrici, si fa uso anche lì di funzioni per gli operatori meno comuni.
e se non si può il codice perde un pò di omogeneità :fagiano:
tutto IMHO ovviamente :p sto solo cercando di capire perchè io da quando uso java non ho mai avuto bisogno di definire un operatore
E che c'entra questo ? Vorresti dire che se avessi un metodo di definire tutti gli operatori che vuoi allora la possibilità di avere l'overloading degli operatori è un bene, mentre se sei limitato agli operatori definiti dal linguaggio è un male ?
Secondo me non è vero che perde di omogeneità, se io faccio:
A = Z.scalarMultiply(B * C + D);
non vedo alcuna perdita di omogenità. Tra l'altro anche Matlab non ha un'operatore per tutte le operazioni permesse con le matrici, si fa uso anche lì di funzioni per gli operatori meno comuni.
k0nt3
20-09-2007, 12:41
Chi ha mai detto di fare pera > mela...io intendevo pera1 > pera2...
Riguardo a come questo confronto con l'operatore venga fatto dobbiamo affidarci a chi ha scritto la classe. Lui ci ha fornito questo metodo di confronto (nella documentazione sicuramente ci sarà scritto), niente vieta, se vogliamo farne un altro, basandoci su nostri metodi di confronto.
si è vero.. ma con il design dell'esempio che ho scritto io non serve creare una classe per ogni significato che assume l'operatore >, ma è sufficiente aggiungere una proprietà all'oggetto.. non so mi sembra più logico
Più vantaggi che svantaggi ? In questo caso no, perché non funzionerebbe con i tipi base ;)
Visto che stai ritornando a come è organizzato Java...come lo faresti con Java in modo che sia compatibile anche con i tipi base ?
mi sa che o ti fai un contenitore oppure usi un contenitore già definito :fagiano:
Riguardo a come questo confronto con l'operatore venga fatto dobbiamo affidarci a chi ha scritto la classe. Lui ci ha fornito questo metodo di confronto (nella documentazione sicuramente ci sarà scritto), niente vieta, se vogliamo farne un altro, basandoci su nostri metodi di confronto.
si è vero.. ma con il design dell'esempio che ho scritto io non serve creare una classe per ogni significato che assume l'operatore >, ma è sufficiente aggiungere una proprietà all'oggetto.. non so mi sembra più logico
Più vantaggi che svantaggi ? In questo caso no, perché non funzionerebbe con i tipi base ;)
Visto che stai ritornando a come è organizzato Java...come lo faresti con Java in modo che sia compatibile anche con i tipi base ?
mi sa che o ti fai un contenitore oppure usi un contenitore già definito :fagiano:
k0nt3
20-09-2007, 12:46
E che c'entra questo ? Vorresti dire che se avessi un metodo di definire tutti gli operatori che vuoi allora la possibilità di avere l'overloading degli operatori è un bene, mentre se sei limitato agli operatori definiti dal linguaggio è un male ?
Secondo me non è vero che perde di omogeneità, se io faccio:
A = Z.scalarMultiply(B * C + D);
non vedo alcuna perdita di omogenità. Tra l'altro anche Matlab non ha un'operatore per tutte le operazioni permesse con le matrici, si fa uso anche lì di funzioni per gli operatori meno comuni.
no io dico che ci sono sempre due modi per fare questa cosa: creare un metodo apposta oppure fare l'overload dell'operatore.
quello più generale è creare un metodo, per cui è l'overload che è superfluo, anche perchè introduce non pochi problemi! adesso stiamo guardando le matrici e già la questione non è banale, pensa che potrebbe essere ancora meno banale :p
per me A = Z x (B * C + D); è omogeneo mentre A = Z.scalarMultiply(B * C + D); un pò meno.. tutta qui.
anche java presenta delle disomogeneità, ma le limita per quanto possibile
Secondo me non è vero che perde di omogeneità, se io faccio:
A = Z.scalarMultiply(B * C + D);
non vedo alcuna perdita di omogenità. Tra l'altro anche Matlab non ha un'operatore per tutte le operazioni permesse con le matrici, si fa uso anche lì di funzioni per gli operatori meno comuni.
no io dico che ci sono sempre due modi per fare questa cosa: creare un metodo apposta oppure fare l'overload dell'operatore.
quello più generale è creare un metodo, per cui è l'overload che è superfluo, anche perchè introduce non pochi problemi! adesso stiamo guardando le matrici e già la questione non è banale, pensa che potrebbe essere ancora meno banale :p
per me A = Z x (B * C + D); è omogeneo mentre A = Z.scalarMultiply(B * C + D); un pò meno.. tutta qui.
anche java presenta delle disomogeneità, ma le limita per quanto possibile
cionci
20-09-2007, 12:47
si è vero.. ma con il design dell'esempio che ho scritto io non serve creare una classe per ogni significato che assume l'operatore >, ma è sufficiente aggiungere una proprietà all'oggetto.. non so mi sembra più logico
Quello che volevo dire è che quello hai scritto te (confronto tramite metodi) si può fare anche con il C++ anche in presenza dell'operatore in overloading.
L'operatore in overloading offre informazioni in più rispetto alla semplice presenza di metodi: ci dice come chi ha implementato la classe vuole che venga effettuato il confronto.
Quello che volevo dire è che quello hai scritto te (confronto tramite metodi) si può fare anche con il C++ anche in presenza dell'operatore in overloading.
L'operatore in overloading offre informazioni in più rispetto alla semplice presenza di metodi: ci dice come chi ha implementato la classe vuole che venga effettuato il confronto.
cionci
20-09-2007, 12:50
, anche perchè introduce non pochi problemi! adesso stiamo guardando le matrici e già la questione non è banale, pensa che potrebbe essere ancora meno banale :p
Guarda...è la prima cosa che ho detto: non bisogna abusarne, ma in alcuni casi è utile. E ti ho anche elencato alcuni dei casi di possibile impiego ;)
E' chiaro che se mi metto a fare l'overloading degli operatori più assurdi diventa un macello, ma ripeto che per alcune cose, come l'ordinamento che ti ho presentato, è utile e permette di fare davvero diverse cose che altri linguaggi non possono fare ed in meno tempo.
Guarda...è la prima cosa che ho detto: non bisogna abusarne, ma in alcuni casi è utile. E ti ho anche elencato alcuni dei casi di possibile impiego ;)
E' chiaro che se mi metto a fare l'overloading degli operatori più assurdi diventa un macello, ma ripeto che per alcune cose, come l'ordinamento che ti ho presentato, è utile e permette di fare davvero diverse cose che altri linguaggi non possono fare ed in meno tempo.
k0nt3
20-09-2007, 12:56
Guarda...è la prima cosa che ho detto: non bisogna abusarne, ma in alcuni casi è utile. E ti ho anche elencato alcuni dei casi di possibile impiego ;)
E' chiaro che se mi metto a fare l'overloading degli operatori più assurdi diventa un macello, ma ripeto che per alcune cose, come l'ordinamento che ti ho presentato, è utile e permette di fare davvero diverse cose che altri linguaggi non possono fare ed in meno tempo.
beh in realtà l'interfaccia Comparable di Java sta lì apposta :D
quello che penso è che è vero che l'overload può servire, ma quando si può è meglio non fare molto affidamento al buon senso di chi scrive. a parte che per me può essere elegante, per te no.. sempre meglio ridurre il campo d'azione così ci si capisce meglio anche tra persone diverse.
per me l'overload rimane una potenziale fonte di casini.. magari quando hai progettato la classe era tutto perfetto e liscio come l'olio, poi devi apportare delle modifiche e l'overload non va più bene. cioè tutto questo per dire che io non vedo questi enormi vantaggi, ma in compenso ci sono molti casi in cui si combinano casini.
la linea tra "abuso" e "non abuso" è molto sottile ;)
E' chiaro che se mi metto a fare l'overloading degli operatori più assurdi diventa un macello, ma ripeto che per alcune cose, come l'ordinamento che ti ho presentato, è utile e permette di fare davvero diverse cose che altri linguaggi non possono fare ed in meno tempo.
beh in realtà l'interfaccia Comparable di Java sta lì apposta :D
quello che penso è che è vero che l'overload può servire, ma quando si può è meglio non fare molto affidamento al buon senso di chi scrive. a parte che per me può essere elegante, per te no.. sempre meglio ridurre il campo d'azione così ci si capisce meglio anche tra persone diverse.
per me l'overload rimane una potenziale fonte di casini.. magari quando hai progettato la classe era tutto perfetto e liscio come l'olio, poi devi apportare delle modifiche e l'overload non va più bene. cioè tutto questo per dire che io non vedo questi enormi vantaggi, ma in compenso ci sono molti casi in cui si combinano casini.
la linea tra "abuso" e "non abuso" è molto sottile ;)
^TiGeRShArK^
20-09-2007, 14:28
overloading operatori, ereditarietà multipla, ...
se il c++ ha più funzionalità del java perchè c'è sempre più gente che usa java e sempre meno che usa c++?
forse xkè l'ereditarietà multipla conduce ad un bad-design e l'overloading degli operatori non è ke serva poi a molto una volta ke ti ci 6 abituato alla sua mancanza? :mbe:
se il c++ ha più funzionalità del java perchè c'è sempre più gente che usa java e sempre meno che usa c++?
forse xkè l'ereditarietà multipla conduce ad un bad-design e l'overloading degli operatori non è ke serva poi a molto una volta ke ti ci 6 abituato alla sua mancanza? :mbe:
cdimauro
20-09-2007, 14:48
non è così semplice.. ci sono vari tipi di moltiplicazione nelle matrici http://en.wikipedia.org/wiki/Matrix_multiplication
a quale si dovrebbe fare riferimento? a quella più comune? e se mi serve un altro tipo di moltiplicazione che simbolo uso? questo è un caso in cui l'overload degli operatori introduce disomogeneità nel linguaggio, non ha senso usare l'operatore * per la moltiplicazione classica tra matrici e poi dei comuni metodi per le altre moltiplicazioni.
La risposta te la sei data da solo: lo usi per le operazioni "classiche", appunto.
Con l'* puoi gestire:
- prodotto fra due matrici;
- prodotto fra matrice e vettore;
- prodotto fra vettore e vettore;
- prodotto fra matrice e scalare;
- prodotto fra vettore e scalare
il tutto in maniera semplice e trasparente, come tra l'altro avresti dovuto imparare a fare quando hai studiato geometria.
ti assicuro che poi A.multiply(B) non ha niente da invidiare a A*B come leggibilità. al massimo è più lungo da scrivere ma finisce lì la questione.
Chiedilo a un matematico o una studente che deve lavorare con matrici et similia quale soluzione preferirebbe e sarebbe più leggibile.
per quanto riguarda le proprietà io continuo a non vederle di buon occhio perchè sono un modo per nascondere l'operato del codice e questo per me è un male. preferisco getters e setters che mi dicono esplicitamente cosa sta succedendo, mi sa che qui sei te che non sei abituato, perchè ti assicuro che la comodità non ne risente minimamente (ma anche la leggibilità)
E io ti continuo a dire che come UTILIZZATORE di una certa classe NON mi serve conoscerne i dettagli implementativi, ma soltanto la sua interfaccia.
Tutt'altra cosa è, invece, andare a LAVORARE sulla classe per modificarne il codice: in questo caso è a dir poco ovvio che mi serva conoscere il dettaglio implementativo.
La divisione fra interfaccia e implementazione nasce dalla notte dei tempi (informatici): non è certo una cosa che mi sto inventando io. Per cui se esiste la possibilità di nascondere dei dettagli implementativi non vedo perché non la si dovrebbe sfruttare.
a quale si dovrebbe fare riferimento? a quella più comune? e se mi serve un altro tipo di moltiplicazione che simbolo uso? questo è un caso in cui l'overload degli operatori introduce disomogeneità nel linguaggio, non ha senso usare l'operatore * per la moltiplicazione classica tra matrici e poi dei comuni metodi per le altre moltiplicazioni.
La risposta te la sei data da solo: lo usi per le operazioni "classiche", appunto.
Con l'* puoi gestire:
- prodotto fra due matrici;
- prodotto fra matrice e vettore;
- prodotto fra vettore e vettore;
- prodotto fra matrice e scalare;
- prodotto fra vettore e scalare
il tutto in maniera semplice e trasparente, come tra l'altro avresti dovuto imparare a fare quando hai studiato geometria.
ti assicuro che poi A.multiply(B) non ha niente da invidiare a A*B come leggibilità. al massimo è più lungo da scrivere ma finisce lì la questione.
Chiedilo a un matematico o una studente che deve lavorare con matrici et similia quale soluzione preferirebbe e sarebbe più leggibile.
per quanto riguarda le proprietà io continuo a non vederle di buon occhio perchè sono un modo per nascondere l'operato del codice e questo per me è un male. preferisco getters e setters che mi dicono esplicitamente cosa sta succedendo, mi sa che qui sei te che non sei abituato, perchè ti assicuro che la comodità non ne risente minimamente (ma anche la leggibilità)
E io ti continuo a dire che come UTILIZZATORE di una certa classe NON mi serve conoscerne i dettagli implementativi, ma soltanto la sua interfaccia.
Tutt'altra cosa è, invece, andare a LAVORARE sulla classe per modificarne il codice: in questo caso è a dir poco ovvio che mi serva conoscere il dettaglio implementativo.
La divisione fra interfaccia e implementazione nasce dalla notte dei tempi (informatici): non è certo una cosa che mi sto inventando io. Per cui se esiste la possibilità di nascondere dei dettagli implementativi non vedo perché non la si dovrebbe sfruttare.
marco.r
20-09-2007, 16:09
non è così semplice.. ci sono vari tipi di moltiplicazione nelle matrici http://en.wikipedia.org/wiki/Matrix_multiplication
a quale si dovrebbe fare riferimento? a quella più comune? e se mi serve un altro tipo di moltiplicazione che simbolo uso?
La moltiplicazione tra matrici è quella "comune", le altre usano operatori diversi dallo standard per cui non c'è motivo di confusione. Moltiplicazione per scalare o per vettore coinvolgono tipi diversi per cui non c'è problema. E' vero che e' un peccato non poter aggiungere nuovi operatori, ma meglio averne pochi in questo caso che nessuno.
ti assicuro che poi A.multiply(B) non ha niente da invidiare a A*B come leggibilità. al massimo è più lungo da scrivere ma finisce lì la questione.
Se non provi ribrezzo nel vedere la prima notazione, vuol dire che nella tua vita hai visto troppo Java e troppa poca matematica :D.
Soprattutto nell'ottica di dover "tradurre" formule come y = A*x + b; o peggio. Non voglio pensarci :D.
Tra l'altro trovo curioso che (in generale) ci si lamenti che altri linguaggi "non somigliano abbastanza" a quelli classici (C++,Java) mentre secondo me e' molto piu' importante che ci si possa esprimere nel dominio in cui si sta programmando (nel caso specifico quello matematico).
a quale si dovrebbe fare riferimento? a quella più comune? e se mi serve un altro tipo di moltiplicazione che simbolo uso?
La moltiplicazione tra matrici è quella "comune", le altre usano operatori diversi dallo standard per cui non c'è motivo di confusione. Moltiplicazione per scalare o per vettore coinvolgono tipi diversi per cui non c'è problema. E' vero che e' un peccato non poter aggiungere nuovi operatori, ma meglio averne pochi in questo caso che nessuno.
ti assicuro che poi A.multiply(B) non ha niente da invidiare a A*B come leggibilità. al massimo è più lungo da scrivere ma finisce lì la questione.
Se non provi ribrezzo nel vedere la prima notazione, vuol dire che nella tua vita hai visto troppo Java e troppa poca matematica :D.
Soprattutto nell'ottica di dover "tradurre" formule come y = A*x + b; o peggio. Non voglio pensarci :D.
Tra l'altro trovo curioso che (in generale) ci si lamenti che altri linguaggi "non somigliano abbastanza" a quelli classici (C++,Java) mentre secondo me e' molto piu' importante che ci si possa esprimere nel dominio in cui si sta programmando (nel caso specifico quello matematico).
k0nt3
20-09-2007, 16:21
l'informatica agli informatici :O
torna subito a studiare gli spazi di Banach :Prrr:
ps. ovviamente scherzavo :p sarà mica andato sul serio a studiare gli spazi di Banach? :mbe:
torna subito a studiare gli spazi di Banach :Prrr:
ps. ovviamente scherzavo :p sarà mica andato sul serio a studiare gli spazi di Banach? :mbe:
k0nt3
21-09-2007, 12:25
sapete che vi dico? a ognuno il suo linguaggio! però non scassate i cosiddetti a Torvalds :read: la sua scelta finora ha pagato, quando non pagherà più si faranno altre scelte :D
cdimauro
21-09-2007, 12:37
Fino a prova contraria è Torvalds che scassa i maroni agli altri con le sue idiozie su C e C++, sulla quale mi sembra che più o meno tutti siamo d'accordo.
Il segreto del successo di Torvalds non è tanto nel linguaggio che ha adottato (su cui vale quanto scritto finora e che è ampiamente provato essere superato da eoni), ma sulla massa di gente, spesso di spessore (come Alan Cox), che lo hanno attorniato.
Con strumenti migliori molto probabilmente si sarebbero ottenuti risultati migliori di quelli finora raccolti.
La dimostrazione che servono strumenti migliori l'abbiamo avuta pure coi programmatori di Gnome, che pur di poter lavorare con gli oggetti si sono inventati una libreria che è un autentico abominio già soltanto a guardarla.
Penso che sia del tutto inutile cercare di screditare un linguaggio come il C++ soltanto per esaltare il C e "salvare il culo" a Linus: non ne vale la pena perché le sue posizioni sono del tutto indifendibili, oltre che incompatibili col logica e razionalità.
Per il resto, i linguaggi sono come le distro: il mio è sempre migliore del tuo. :p
Il segreto del successo di Torvalds non è tanto nel linguaggio che ha adottato (su cui vale quanto scritto finora e che è ampiamente provato essere superato da eoni), ma sulla massa di gente, spesso di spessore (come Alan Cox), che lo hanno attorniato.
Con strumenti migliori molto probabilmente si sarebbero ottenuti risultati migliori di quelli finora raccolti.
La dimostrazione che servono strumenti migliori l'abbiamo avuta pure coi programmatori di Gnome, che pur di poter lavorare con gli oggetti si sono inventati una libreria che è un autentico abominio già soltanto a guardarla.
Penso che sia del tutto inutile cercare di screditare un linguaggio come il C++ soltanto per esaltare il C e "salvare il culo" a Linus: non ne vale la pena perché le sue posizioni sono del tutto indifendibili, oltre che incompatibili col logica e razionalità.
Per il resto, i linguaggi sono come le distro: il mio è sempre migliore del tuo. :p
ramhd
21-09-2007, 12:40
La moltiplicazione tra matrici è quella "comune", le altre usano operatori diversi dallo standard per cui non c'è motivo di confusione. Moltiplicazione per scalare o per vettore coinvolgono tipi diversi per cui non c'è problema. E' vero che e' un peccato non poter aggiungere nuovi operatori, ma meglio averne pochi in questo caso che nessuno.
Se non provi ribrezzo nel vedere la prima notazione, vuol dire che nella tua vita hai visto troppo Java e troppa poca matematica :D.
Soprattutto nell'ottica di dover "tradurre" formule come y = A*x + b; o peggio. Non voglio pensarci :D.
Tra l'altro trovo curioso che (in generale) ci si lamenti che altri linguaggi "non somigliano abbastanza" a quelli classici (C++,Java) mentre secondo me e' molto piu' importante che ci si possa esprimere nel dominio in cui si sta programmando (nel caso specifico quello matematico).
Infatti esiste Octave per questo tipo di programmazione :D
Se non provi ribrezzo nel vedere la prima notazione, vuol dire che nella tua vita hai visto troppo Java e troppa poca matematica :D.
Soprattutto nell'ottica di dover "tradurre" formule come y = A*x + b; o peggio. Non voglio pensarci :D.
Tra l'altro trovo curioso che (in generale) ci si lamenti che altri linguaggi "non somigliano abbastanza" a quelli classici (C++,Java) mentre secondo me e' molto piu' importante che ci si possa esprimere nel dominio in cui si sta programmando (nel caso specifico quello matematico).
Infatti esiste Octave per questo tipo di programmazione :D
k0nt3
21-09-2007, 13:06
Per il resto, i linguaggi sono come le distro: il mio è sempre migliore del tuo. :p
:rotfl: ne consegue che i linguaggi sono come le ragazze :O
e non ho detto io che il C è da porci :mbe: :oink:
:rotfl: ne consegue che i linguaggi sono come le ragazze :O
e non ho detto io che il C è da porci :mbe: :oink:
marco.r
21-09-2007, 14:21
Infatti esiste Octave per questo tipo di programmazione :D
Non sempre e' possibile usare programmi di quel tipo, soprattutto quando il codice generato deve interoperare con altro oppure sottostare ad alcune limitazioni (ambiente real-time ad esempio).
Non sempre e' possibile usare programmi di quel tipo, soprattutto quando il codice generato deve interoperare con altro oppure sottostare ad alcune limitazioni (ambiente real-time ad esempio).
~FullSyst3m~
29-01-2008, 14:09
però uno che scrive un software come git in C per me è un pazzo :asd:
E' anche un genio però...
Esercizion 1.4 di questa guida (grazie cdimauro per avermi salvato dall'altra pseudo-guida!! :asd:) http://www.python.it/doc/Howtothink/Howtothink-html-it/index.htm
Frase 1: Linu$ Torv@ld$ i$.... (continuate voi... fate sbizzarrire la fantasia!)
Frase 2: Torvalds il perde quando controllo... (come sopra!)
E' anche un genio però...
Esercizion 1.4 di questa guida (grazie cdimauro per avermi salvato dall'altra pseudo-guida!! :asd:) http://www.python.it/doc/Howtothink/Howtothink-html-it/index.htm
Frase 1: Linu$ Torv@ld$ i$.... (continuate voi... fate sbizzarrire la fantasia!)
Frase 2: Torvalds il perde quando controllo... (come sopra!)
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.