Th3 Kn0wl3dg3
08-05-2006, 18:07
ragazzi ho una voglia pazzesca di programmare, ma non so da dove iniziare.....e poi ho paura ke ormai essendo maggiorenne non potrò mai arrivare dove desidero....ke devo fare?
View Full Version : consiglio su come iniziare a programmare
Xalexalex
08-05-2006, 18:16
ragazzi ho una voglia pazzesca di programmare, ma non so da dove iniziare.....e poi ho paura ke ormai essendo maggiorenne non potrò mai arrivare dove desidero....ke devo fare?
Intanto comincia col chiarirci le idee sul tuo scopo ultimo.. Siti web?, aplicazioni desktop?, applicazioni server?, nanotecnologie?, controllo del mondo?... Dipende da cosa vuoi fare!!
Intanto comincia col chiarirci le idee sul tuo scopo ultimo.. Siti web?, aplicazioni desktop?, applicazioni server?, nanotecnologie?, controllo del mondo?... Dipende da cosa vuoi fare!!
Th3 Kn0wl3dg3
08-05-2006, 21:00
bè a me piacerebbe imparare a programmare in generale...se uno impara ed entra nell'ottica poi credo ke sappia programmare qualsiasi cosa!!
wisher
08-05-2006, 21:41
prova a cercare qualcosa su python http://www.python.org/
se vuoi partire subito più a basso livello puoi iniziare con il C anche se è leggermente più difficile
se vuoi partire subito più a basso livello puoi iniziare con il C anche se è leggermente più difficile
Pro7on
08-05-2006, 22:37
Io personalmente ho iniziato con il c. e Attualmente sto facendo Java e ti asscicuro che devi farti una base come io con c poi ad es. con JS(javascript) o altre cose devi inparare la sintassi ma la logica ce lai sempre
:D :D
:D :D
wisher
08-05-2006, 23:17
Io personalmente ho iniziato con il c. e Attualmente sto facendo Java e ti asscicuro che devi farti una base come io con c poi ad es. con JS(javascript) o altre cose devi inparare la sintassi ma la logica ce lai sempre
:D :D
questo discorso vale in ogni caso, si impara la logica, poi per la sintassi non è un grandissimo problema, basta un buon manuale e un po di tempo
:D :D
questo discorso vale in ogni caso, si impara la logica, poi per la sintassi non è un grandissimo problema, basta un buon manuale e un po di tempo
Th3 Kn0wl3dg3
08-05-2006, 23:19
allora secondo voi con cosa dovrei cominciare?
shinya
09-05-2006, 09:15
allora secondo voi con cosa dovrei cominciare?
Con qualcosa di semplice. Ti consiglio Python o Ruby.
O Haskell :) *scherzo*
Con qualcosa di semplice. Ti consiglio Python o Ruby.
O Haskell :) *scherzo*
k0nt3
09-05-2006, 10:28
allora secondo voi con cosa dovrei cominciare?
da quello che ti stimola
da quello che ti stimola
h1jack3r
09-05-2006, 19:48
potresti iniziare o con il C o con il java secondo me. Java è adoggetti e molto più semplice del C, dove tutto deve essere perfetto sennò non gira nulla.
Ovvio è che una volta che sai il C hai la mentalità per prendere in mano un qualsiasi linguaggio di programmazione e imparare la sintassi e le principali cose in poco tempo. Farselo da solo però credo sia veramente tosta, io ho iniziato all'uni col C, poi abbiamo fatto un corso di java e altri corsi di C; solo ultimamente scripting lato server.
Detto tutto ciò sei davanti a due opportunità:
vuoi sbatterti e spaccarti la testa per imparare veramente a programmare -----> C
vuoi provare ad iniziare a programmare e vedere se ti piace e poi eventualmente approfondire -------> Java (scaricati Eclipse per scrivere applicazioni)
Ovvio è che una volta che sai il C hai la mentalità per prendere in mano un qualsiasi linguaggio di programmazione e imparare la sintassi e le principali cose in poco tempo. Farselo da solo però credo sia veramente tosta, io ho iniziato all'uni col C, poi abbiamo fatto un corso di java e altri corsi di C; solo ultimamente scripting lato server.
Detto tutto ciò sei davanti a due opportunità:
vuoi sbatterti e spaccarti la testa per imparare veramente a programmare -----> C
vuoi provare ad iniziare a programmare e vedere se ti piace e poi eventualmente approfondire -------> Java (scaricati Eclipse per scrivere applicazioni)
Th3 Kn0wl3dg3
11-05-2006, 13:56
per studiare il C quale buona documentazione mi consigliate?
fek
11-05-2006, 14:06
per studiare il C quale buona documentazione mi consigliate?
Nessuna, inizia da Java :)
vuoi sbatterti e spaccarti la testa per imparare veramente a programmare -----> C
Argomento ricorrente: se vuoi imparare veramente a programmare non iniziare col C. Se impari a programmare in C, poi quando prendi in mano qualunque altro linguaggio di programmazione devi dimenticarti quello che hai imparato e ricominciare daccapo.
Nessuna, inizia da Java :)
vuoi sbatterti e spaccarti la testa per imparare veramente a programmare -----> C
Argomento ricorrente: se vuoi imparare veramente a programmare non iniziare col C. Se impari a programmare in C, poi quando prendi in mano qualunque altro linguaggio di programmazione devi dimenticarti quello che hai imparato e ricominciare daccapo.
k0nt3
11-05-2006, 14:15
Nessuna, inizia da Java :)
Argomento ricorrente: se vuoi imparare veramente a programmare non iniziare col C. Se impari a programmare in C, poi quando prendi in mano qualunque altro linguaggio di programmazione devi dimenticarti quello che hai imparato e ricominciare daccapo.
niente di più falso
per studiare il C quale buona documentazione mi consigliate?
i miei amici che hanno iniziato da zero con il C si sono trovati bene con "Deitel&Deitel, C-Corso completo di programmazione" purtroppo io non l'ho letto e non posso darti un giudizio diretto e poi mi sa che costa un pò.
in mancanza di altro c'è "thinking in C" http://mindview.net/CDs/ThinkingInC/beta3 solo che non è finito come vedi.. è beta :) ma gratis. adesso lo scarico anche io per vedere a che punto è.
Argomento ricorrente: se vuoi imparare veramente a programmare non iniziare col C. Se impari a programmare in C, poi quando prendi in mano qualunque altro linguaggio di programmazione devi dimenticarti quello che hai imparato e ricominciare daccapo.
niente di più falso
per studiare il C quale buona documentazione mi consigliate?
i miei amici che hanno iniziato da zero con il C si sono trovati bene con "Deitel&Deitel, C-Corso completo di programmazione" purtroppo io non l'ho letto e non posso darti un giudizio diretto e poi mi sa che costa un pò.
in mancanza di altro c'è "thinking in C" http://mindview.net/CDs/ThinkingInC/beta3 solo che non è finito come vedi.. è beta :) ma gratis. adesso lo scarico anche io per vedere a che punto è.
h1jack3r
11-05-2006, 14:16
Nessuna, inizia da Java :)
Se impari a programmare in C, poi quando prendi in mano qualunque altro linguaggio di programmazione devi dimenticarti quello che hai imparato e ricominciare daccapo.
Si non hai torto però proprio dimenticare mi sembra eccessivo. La sintassi di Java è molto simile ad esempio, solo che si usano gli oggetti. Col il C capisi meglio la struttura del calcolatre questo è indubbio. Con Java fai prorammi più ad alto livello in maniera più facile e impari sicuramente prima.
Se impari a programmare in C, poi quando prendi in mano qualunque altro linguaggio di programmazione devi dimenticarti quello che hai imparato e ricominciare daccapo.
Si non hai torto però proprio dimenticare mi sembra eccessivo. La sintassi di Java è molto simile ad esempio, solo che si usano gli oggetti. Col il C capisi meglio la struttura del calcolatre questo è indubbio. Con Java fai prorammi più ad alto livello in maniera più facile e impari sicuramente prima.
wisher
11-05-2006, 14:18
il deitel come libro è molto buono e pieno di tutorial
se vuoi qualcosa online prova a cercare tricky c o qualcosa di simile, quando l'ho letto mi è piaciuto molto
se vuoi qualcosa online prova a cercare tricky c o qualcosa di simile, quando l'ho letto mi è piaciuto molto
k0nt3
11-05-2006, 14:23
Si non hai torto però proprio dimenticare mi sembra eccessivo. La sintassi di Java è molto simile ad esempio, solo che si usano gli oggetti. Col il C capisi meglio la struttura del calcolatre questo è indubbio. Con Java fai prorammi più ad alto livello in maniera più facile e impari sicuramente prima.
se impari con il C e passi a java prima di fossilizzarti sulla programmazione strutturata non incontri nessuna difficoltà. certo dipende da cosa uno vuole imparare a fare... se vuoi limitarti a disegnare finestre con tanti bottoni consiglio anche io di iniziare con linguaggi di alto livello come java o c#, ma se vuoi capire qualcosa di più incontri mille difficoltà a passare da java a C. questo perchè con il C hai le basi per capire java, ma non viceversa.
se impari con il C e passi a java prima di fossilizzarti sulla programmazione strutturata non incontri nessuna difficoltà. certo dipende da cosa uno vuole imparare a fare... se vuoi limitarti a disegnare finestre con tanti bottoni consiglio anche io di iniziare con linguaggi di alto livello come java o c#, ma se vuoi capire qualcosa di più incontri mille difficoltà a passare da java a C. questo perchè con il C hai le basi per capire java, ma non viceversa.
0rph3n
11-05-2006, 14:57
scusate, ma perchè molti si ostinano a pensare che se non sai come funziona la macchina non puoi/non sai programmare? :confused:
estremizzando questa linea di pensiero, tutti i programmatori dovrebbero conoscere l'assembly perchè altrimenti non si può capire come funziona il c!
...o no? :mc:
dal mio punto di vista il motivo per il quale non conviene iniziare dal c non è ne più o ne meno lo stesso per cui ora a scuola non insegnano più a calcolare le radici (almeno guardando alla mia esperienza scolastica e a quella di mio fratello) in quanto esistono le calcolatrici che permettono di trovarne il risultato in meno tempo e meno fatica, e soprattutto perchè non è indispensabile saperlo!
adattando l'esempio al contesto: in c ti devi calcolare a mano le radici (che può essere vista come la gestione della memoria) mentre in java e qualsiasi linguaggio di più alto livello non te ne devi preoccupare perchè se ne occupa lui!
detto questo è ovvio che se qualcuno ha ambizione/esigenza di conoscere nei particolari il funzionamento di un pc il c può aiutare, ma non è indispensabile! (ne la conoscenza del funzionamento della macchina - perlomeno non in forma approfondita - ne la conoscenza del c)!
'iao
estremizzando questa linea di pensiero, tutti i programmatori dovrebbero conoscere l'assembly perchè altrimenti non si può capire come funziona il c!
...o no? :mc:
dal mio punto di vista il motivo per il quale non conviene iniziare dal c non è ne più o ne meno lo stesso per cui ora a scuola non insegnano più a calcolare le radici (almeno guardando alla mia esperienza scolastica e a quella di mio fratello) in quanto esistono le calcolatrici che permettono di trovarne il risultato in meno tempo e meno fatica, e soprattutto perchè non è indispensabile saperlo!
adattando l'esempio al contesto: in c ti devi calcolare a mano le radici (che può essere vista come la gestione della memoria) mentre in java e qualsiasi linguaggio di più alto livello non te ne devi preoccupare perchè se ne occupa lui!
detto questo è ovvio che se qualcuno ha ambizione/esigenza di conoscere nei particolari il funzionamento di un pc il c può aiutare, ma non è indispensabile! (ne la conoscenza del funzionamento della macchina - perlomeno non in forma approfondita - ne la conoscenza del c)!
'iao
fek
11-05-2006, 14:57
questo perchè con il C hai le basi per capire java, ma non viceversa.
E' vero il contrario: Java ha le basi sintattiche e logiche per capire il C perche' la sintassi e' molto simile.
Una volta imparato il C anche per fare operazioni semplici e banali, invece, le basi che si sono imparate vanno dimenticate perche' sono deleterie e inutili per programmare in Java.
E' vero il contrario: Java ha le basi sintattiche e logiche per capire il C perche' la sintassi e' molto simile.
Una volta imparato il C anche per fare operazioni semplici e banali, invece, le basi che si sono imparate vanno dimenticate perche' sono deleterie e inutili per programmare in Java.
fek
11-05-2006, 14:59
niente di più falso
Invece e' perfettamente vero.
Invece e' perfettamente vero.
k0nt3
11-05-2006, 15:13
Invece e' perfettamente vero.
continuo a non capire perchè bisogna dimenticare tutto.. le variabili ti servono ancora, le funzioni (chiamali metodi) pure, i cicli anche, gli if-else anche loro... cosa serve di più per imparare? allora direte.. "meglio non vedere nemmeno di striscio i puntatori", ma uno la testa contro i puntatori ce la deve sbattere anche con java altrimenti non capirà alcuni comportamenti strani quando passa come parametro ai metodi degli oggetti, oppure quando clona un oggetto.
comunque sia è stato lui a dire che voleva iniziare dal C e quindi, visto che non ha firmato nessun contratto, se vede che non fa il caso suo può cambiare idea e iniziare con java. intanto consiglia del materiale se lo conosci :)
continuo a non capire perchè bisogna dimenticare tutto.. le variabili ti servono ancora, le funzioni (chiamali metodi) pure, i cicli anche, gli if-else anche loro... cosa serve di più per imparare? allora direte.. "meglio non vedere nemmeno di striscio i puntatori", ma uno la testa contro i puntatori ce la deve sbattere anche con java altrimenti non capirà alcuni comportamenti strani quando passa come parametro ai metodi degli oggetti, oppure quando clona un oggetto.
comunque sia è stato lui a dire che voleva iniziare dal C e quindi, visto che non ha firmato nessun contratto, se vede che non fa il caso suo può cambiare idea e iniziare con java. intanto consiglia del materiale se lo conosci :)
k0nt3
11-05-2006, 15:31
ho dato un'occhiata a thinking in C e mi sembra davvero fatto bene. tra l'altro prevede il passaggio da C a java o da C a C++ a seconda di quello che interessa al lettore. per questo motivo mi sento di consigliarlo a chi vuole iniziare con il C. almeno è guidato nel passaggio a qualcosa di più amichevole.
ps. bisogna sapere l'inglese abbastanza bene... soprattutto parlato :D
ps. bisogna sapere l'inglese abbastanza bene... soprattutto parlato :D
fek
11-05-2006, 16:03
continuo a non capire perchè bisogna dimenticare tutto.. le variabili ti servono ancora, le funzioni (chiamali metodi) pure, i cicli anche, gli if-else anche loro... cosa serve di più per imparare? allora direte.. "meglio non vedere nemmeno di striscio i puntatori", ma uno la testa contro i puntatori ce la deve sbattere anche con java altrimenti non capirà alcuni comportamenti strani quando passa come parametro ai metodi degli oggetti, oppure quando clona un oggetto.
Perche' programmare non vuol dire conoscere cicli, variabili e if-else. Come saper comunicare non vuol dire conoscere come si pronuncia una parola.
Programmare vuol dire sapere come organizzare i costrutti per risolvere un problema nella maniera piu' semplice e meno costosa possibile.
E le soluzioni a questo problema che si imparano programmando in C, vanno dimenticate perche' non sono piu' valide in Java. A imparare un if/else ci vuole un'ora, a imparare a programmare ci vogliono anni, meglio non perdere ulteriore tempo col C.
intanto consiglia del materiale se lo conosci :)
Il titolo del thread e' "Consiglio su come iniziare a programmare" e questo sto consigliando. (Ho iniziato a programmare in C quando tu non eri ancora nato).
Perche' programmare non vuol dire conoscere cicli, variabili e if-else. Come saper comunicare non vuol dire conoscere come si pronuncia una parola.
Programmare vuol dire sapere come organizzare i costrutti per risolvere un problema nella maniera piu' semplice e meno costosa possibile.
E le soluzioni a questo problema che si imparano programmando in C, vanno dimenticate perche' non sono piu' valide in Java. A imparare un if/else ci vuole un'ora, a imparare a programmare ci vogliono anni, meglio non perdere ulteriore tempo col C.
intanto consiglia del materiale se lo conosci :)
Il titolo del thread e' "Consiglio su come iniziare a programmare" e questo sto consigliando. (Ho iniziato a programmare in C quando tu non eri ancora nato).
Starise
11-05-2006, 16:18
Io dico che se vuoi imparare a programmare iniziando dalle basi e studiando per bene cos'è un calcolatore, ti conviene iniziare con un linguaggio di programmazione a basso livello. Il C è l'ideale, perchè anche altri linguaggi potenti sono sintatticamente simili, come il C++, php ecc...
Ti sconsiglio vivamente il java perchè a mio avviso è un casino! Devi dichiarare ogni minima fesseria.
Per esempio questo è un programma che stampa a schermo "hello world" in C.
#include <stdio.h>
main ()
{
printf("Hello World!");
}
Questo invece è lo stesso programma in java:
class Saluto {
public static void main(String args[]) {
System.out.println("Hello World!");
}
}
Se invece ti va di creare applicazioni, sia per hobby che professionalmente, senza interessarti dei lati oscuri del calcolatore, allora punta su linguaggi semplici sintatticamente e livello più alto. In questo caso ti consiglio senza remore il python.
E' senz'altro un linguaggio di Serie A, ha tantissime utili librerie e ti servirà anche per sviluppare applicazioni web.
Questo è il codice in python per scrivere Hello World:
print "Hello World!"
Semplice vero??
PS: Python è stato scritto in C (tanto per farti un'idea! ;) )
Ti sconsiglio vivamente il java perchè a mio avviso è un casino! Devi dichiarare ogni minima fesseria.
Per esempio questo è un programma che stampa a schermo "hello world" in C.
#include <stdio.h>
main ()
{
printf("Hello World!");
}
Questo invece è lo stesso programma in java:
class Saluto {
public static void main(String args[]) {
System.out.println("Hello World!");
}
}
Se invece ti va di creare applicazioni, sia per hobby che professionalmente, senza interessarti dei lati oscuri del calcolatore, allora punta su linguaggi semplici sintatticamente e livello più alto. In questo caso ti consiglio senza remore il python.
E' senz'altro un linguaggio di Serie A, ha tantissime utili librerie e ti servirà anche per sviluppare applicazioni web.
Questo è il codice in python per scrivere Hello World:
print "Hello World!"
Semplice vero??
PS: Python è stato scritto in C (tanto per farti un'idea! ;) )
fek
11-05-2006, 16:21
Ti sconsiglio vivamente il java perchè a mio avviso è un casino! Devi dichiarare ogni minima fesseria.
Appunto per questo deve iniziare in Java, cosi' impara a dichiarare ogni minima fesseria.
Se invece ti va di creare applicazioni, per hobby intendo, senza interessarti dei lati oscuri del calcolatore, allora punta su linguaggi semplici sintatticamente e livello più alto. In questo caso ti consiglio senza remore il python.
Non ho capito, chi crea applicazioni per lavoro e non per hobby invece deve usare il C e interessarsi ai lati oscuri del calcolatore? Non penso, anzi.
Appunto per questo deve iniziare in Java, cosi' impara a dichiarare ogni minima fesseria.
Se invece ti va di creare applicazioni, per hobby intendo, senza interessarti dei lati oscuri del calcolatore, allora punta su linguaggi semplici sintatticamente e livello più alto. In questo caso ti consiglio senza remore il python.
Non ho capito, chi crea applicazioni per lavoro e non per hobby invece deve usare il C e interessarsi ai lati oscuri del calcolatore? Non penso, anzi.
h1jack3r
11-05-2006, 16:29
Io la penso così:
Vuoi imparare a programmare per farti qualche applicazioncina o qualche programma per usare il pc non solo in maniera passiva ma anche attiva------> Java
Non te ne frega nulla di farti un programma visuale ma vuoi capire problemi relativi all'architettura e alla struttura interna del calcolatore andando più a basso livello----> C
Vuoi imparare a programmare per farti qualche applicazioncina o qualche programma per usare il pc non solo in maniera passiva ma anche attiva------> Java
Non te ne frega nulla di farti un programma visuale ma vuoi capire problemi relativi all'architettura e alla struttura interna del calcolatore andando più a basso livello----> C
Starise
11-05-2006, 16:59
Appunto per questo deve iniziare in Java, cosi' impara a dichiarare ogni minima fesseria.
Sarà... ma io credo che il java sia troppo macchinoso per un principiante...
Non ho capito, chi crea applicazioni per lavoro e non per hobby invece deve usare il C e interessarsi ai lati oscuri del calcolatore? Non penso, anzi.
Scusa, errore mio... ora che ho riletto sembra che il python non sia una cosa seria! Hai ragione, il python è potentissimo e sicuramente (come si capiva dalla seconda parte della frase) credo che offra anche professionalmente molte prospettive, proprio grazie alla portabilità, alle tante librerie e alla facilità di sviluppo duvuta a una sintassi incredibilmente semplice! ;)
Sarà... ma io credo che il java sia troppo macchinoso per un principiante...
Non ho capito, chi crea applicazioni per lavoro e non per hobby invece deve usare il C e interessarsi ai lati oscuri del calcolatore? Non penso, anzi.
Scusa, errore mio... ora che ho riletto sembra che il python non sia una cosa seria! Hai ragione, il python è potentissimo e sicuramente (come si capiva dalla seconda parte della frase) credo che offra anche professionalmente molte prospettive, proprio grazie alla portabilità, alle tante librerie e alla facilità di sviluppo duvuta a una sintassi incredibilmente semplice! ;)
k0nt3
11-05-2006, 17:00
Perche' programmare non vuol dire conoscere cicli, variabili e if-else. Come saper comunicare non vuol dire conoscere come si pronuncia una parola.
Programmare vuol dire sapere come organizzare i costrutti per risolvere un problema nella maniera piu' semplice e meno costosa possibile.
concordo. infatti programmare vuol dire sostanzialmente creare algoritmi che risolvono problemi... e questo lo si fa con cicli, variabili e if-else :D sia che programmi in java e sia che programmi in C.
IMHO il vantaggio del C è che è minimale e ti permette di concentrarti su questo aspetto. quando poi gli algoritmi che crei sono molto complessi hai bisogno degli oggetti e allora sarà il momento di imparare java (qui sì che è meglio non ostinarsi con il C perchè può fare danni).
E le soluzioni a questo problema che si imparano programmando in C, vanno dimenticate perche' non sono piu' valide in Java. A imparare un if/else ci vuole un'ora, a imparare a programmare ci vogliono anni, meglio non perdere ulteriore tempo col C.
perchè! il mergesort funziona in maniera diversa su java?
Il titolo del thread e' "Consiglio su come iniziare a programmare" e questo sto consigliando. (Ho iniziato a programmare in C quando tu non eri ancora nato).
è possibile
Programmare vuol dire sapere come organizzare i costrutti per risolvere un problema nella maniera piu' semplice e meno costosa possibile.
concordo. infatti programmare vuol dire sostanzialmente creare algoritmi che risolvono problemi... e questo lo si fa con cicli, variabili e if-else :D sia che programmi in java e sia che programmi in C.
IMHO il vantaggio del C è che è minimale e ti permette di concentrarti su questo aspetto. quando poi gli algoritmi che crei sono molto complessi hai bisogno degli oggetti e allora sarà il momento di imparare java (qui sì che è meglio non ostinarsi con il C perchè può fare danni).
E le soluzioni a questo problema che si imparano programmando in C, vanno dimenticate perche' non sono piu' valide in Java. A imparare un if/else ci vuole un'ora, a imparare a programmare ci vogliono anni, meglio non perdere ulteriore tempo col C.
perchè! il mergesort funziona in maniera diversa su java?
Il titolo del thread e' "Consiglio su come iniziare a programmare" e questo sto consigliando. (Ho iniziato a programmare in C quando tu non eri ancora nato).
è possibile
cdimauro
11-05-2006, 17:11
Io dico che se vuoi imparare a programmare iniziando dalle basi e studiando per bene cos'è un calcolatore, ti conviene iniziare con un linguaggio di programmazione a basso livello. Il C è l'ideale, perchè anche altri linguaggi potenti sono sintatticamente simili, come il C++, php ecc...
In questo caso l'ideale è l'assembly, anzi il linguaggio macchina scrivendo direttamente gli opcode delle istruzioni in esadecimale: si capisce perfettamente come funziona la macchina, fin da subito.
Se invece ti va di creare applicazioni, per hobby intendo, senza interessarti dei lati oscuri del calcolatore, allora punta su linguaggi semplici sintatticamente e livello più alto. In questo caso ti consiglio senza remore il python.
E' da un anno e mezzo che uso Python a lavoro per sviluppare qualunque applicazione, anche "mission critical", e funziona benissimo.
L'unica differenza rispetto a linguaggi come Java, per non parlare di C, è che a sviluppare e mantenere il codice impiego anche 1/10 del tempo. Dici che ho fatto male, perché avrei dovuto usarlo soltanto come passatempo?
E' senz'altro un linguaggio di Serie A, ha tantissime utili librerie e ti servirà anche per sviluppare applicazioni web.
Questo è il codice in python per scrivere Hello World:
print "Hello World!"
Semplice vero??
PS: Python è stato scritto in C (tanto per farti un'idea! ;) )
L'implementazione che viene utilizzata normalmente sì, ma questo non vuol dire niente. Infatti PyPy è un compilatore Python scritto interamente in Python, ad esempio. Quello di scrivere il compilatore di un linguaggio usando lo stesso linguaggio è un esercizio (spesso di stile) che viene fatto.
Comunque, tornando in topic, visto che l'obiettivo è quello di IMPARARE A PROGRAMMARE, non c'è niente di meglio di un linguaggio di alto livello come Python (ma anche Ruby, SmallTalk, ecc.) che ti permette di focalizzarti fin da subito sull'apprendimento dei concetti base, per poi approfondire anche tematiche più complesse (ma sempre rimanendo con lo stesso linguaggio).
Python si può pensare come l'equivalente dello pseudocodice, con la differenza che si può usare benissimo per lavorare per quasi tutto (anche alcuni giochi 3D sono sviluppati usando Python come base, salvo ottimizzare alcune parti critiche).
In questo caso l'ideale è l'assembly, anzi il linguaggio macchina scrivendo direttamente gli opcode delle istruzioni in esadecimale: si capisce perfettamente come funziona la macchina, fin da subito.
Se invece ti va di creare applicazioni, per hobby intendo, senza interessarti dei lati oscuri del calcolatore, allora punta su linguaggi semplici sintatticamente e livello più alto. In questo caso ti consiglio senza remore il python.
E' da un anno e mezzo che uso Python a lavoro per sviluppare qualunque applicazione, anche "mission critical", e funziona benissimo.
L'unica differenza rispetto a linguaggi come Java, per non parlare di C, è che a sviluppare e mantenere il codice impiego anche 1/10 del tempo. Dici che ho fatto male, perché avrei dovuto usarlo soltanto come passatempo?
E' senz'altro un linguaggio di Serie A, ha tantissime utili librerie e ti servirà anche per sviluppare applicazioni web.
Questo è il codice in python per scrivere Hello World:
print "Hello World!"
Semplice vero??
PS: Python è stato scritto in C (tanto per farti un'idea! ;) )
L'implementazione che viene utilizzata normalmente sì, ma questo non vuol dire niente. Infatti PyPy è un compilatore Python scritto interamente in Python, ad esempio. Quello di scrivere il compilatore di un linguaggio usando lo stesso linguaggio è un esercizio (spesso di stile) che viene fatto.
Comunque, tornando in topic, visto che l'obiettivo è quello di IMPARARE A PROGRAMMARE, non c'è niente di meglio di un linguaggio di alto livello come Python (ma anche Ruby, SmallTalk, ecc.) che ti permette di focalizzarti fin da subito sull'apprendimento dei concetti base, per poi approfondire anche tematiche più complesse (ma sempre rimanendo con lo stesso linguaggio).
Python si può pensare come l'equivalente dello pseudocodice, con la differenza che si può usare benissimo per lavorare per quasi tutto (anche alcuni giochi 3D sono sviluppati usando Python come base, salvo ottimizzare alcune parti critiche).
Starise
11-05-2006, 17:16
L'unica differenza rispetto a linguaggi come Java, per non parlare di C, è che a sviluppare e mantenere il codice impiego anche 1/10 del tempo. Dici che ho fatto male, perché avrei dovuto usarlo soltanto come passatempo?
Sono d'accordo con te.. come vedi mi sono corretto nel mio post precedente.
Sono d'accordo con te.. come vedi mi sono corretto nel mio post precedente.
VICIUS
11-05-2006, 17:19
Non aspettarti di riuscire a fare cose mirabolanti da subito. Programmare richiede esperienza e quella puoi acquisirla solo col tempo. Insomma cerca di volare basso, non scoraggiarti mai, ma soprattutto cerca di divertirti :)
Per quanto riguarda il linguaggio io comincerei con ruby. Ha una sintassi molto semplice e in giro si trovano dei libri fatti molto bene come "Programming Ruby: The Pragmatic Programmer's Guide" e questo che è pure gratis: http://poignantguide.net/ruby/
ciao ;)
Per quanto riguarda il linguaggio io comincerei con ruby. Ha una sintassi molto semplice e in giro si trovano dei libri fatti molto bene come "Programming Ruby: The Pragmatic Programmer's Guide" e questo che è pure gratis: http://poignantguide.net/ruby/
ciao ;)
fek
11-05-2006, 17:21
concordo. infatti programmare vuol dire sostanzialmente creare algoritmi che risolvono problemi... e questo lo si fa con cicli, variabili e if-else :D sia che programmi in java e sia che programmi in C.
IMHO il vantaggio del C è che è minimale e ti permette di concentrarti su questo aspetto. quando poi gli algoritmi che crei sono molto complessi hai bisogno degli oggetti e allora sarà il momento di imparare java (qui sì che è meglio non ostinarsi con il C perchè può fare danni).
Evidentemente non sai che facendo buon uso del polimorfismo puoi eliminare il 90% delle catene if-else, eliminare totalmente switch e compagnia, concetti come gli iteratori sostituiscono i cicli. Ecco che puoi letteralmente scrivere un intero programma senza uno switch o un ciclo for in un linguaggio come Ruby o Smalltalk, ad esempio. Saper programmare non vuol dire sapere scrivere un ciclo for.
Imparando prima il C, si deve disimparare tutto per imparare nuovamente a programmare in maniera piu' veloce e produttiva in linguaggi a livello piu' alto.
perchè! il mergesort funziona in maniera diversa su java?
Puo' e deve essere implementato in maniera diversa. Si'.
IMHO il vantaggio del C è che è minimale e ti permette di concentrarti su questo aspetto. quando poi gli algoritmi che crei sono molto complessi hai bisogno degli oggetti e allora sarà il momento di imparare java (qui sì che è meglio non ostinarsi con il C perchè può fare danni).
Evidentemente non sai che facendo buon uso del polimorfismo puoi eliminare il 90% delle catene if-else, eliminare totalmente switch e compagnia, concetti come gli iteratori sostituiscono i cicli. Ecco che puoi letteralmente scrivere un intero programma senza uno switch o un ciclo for in un linguaggio come Ruby o Smalltalk, ad esempio. Saper programmare non vuol dire sapere scrivere un ciclo for.
Imparando prima il C, si deve disimparare tutto per imparare nuovamente a programmare in maniera piu' veloce e produttiva in linguaggi a livello piu' alto.
perchè! il mergesort funziona in maniera diversa su java?
Puo' e deve essere implementato in maniera diversa. Si'.
fek
11-05-2006, 17:22
Scusa, errore mio... ora che ho riletto sembra che il python non sia una cosa seria! Hai ragione, il python è potentissimo e sicuramente (come si capiva dalla seconda parte della frase) credo che offra anche professionalmente molte prospettive, proprio grazie alla portabilità, alle tante librerie e alla facilità di sviluppo duvuta a una sintassi incredibilmente semplice! ;)
Si', sono d'accordo :)
Pensa che linguaggi come Lua e Python ora sono usati per scrivere buona parte di un gioco. Anche su console.
Si', sono d'accordo :)
Pensa che linguaggi come Lua e Python ora sono usati per scrivere buona parte di un gioco. Anche su console.
k0nt3
11-05-2006, 17:27
Evidentemente non sai che facendo buon uso del polimorfismo puoi eliminare il 90% delle catene if-else, eliminare totalmente switch e compagnia, concetti come gli iteratori sostituiscono i cicli. Ecco che puoi letteralmente scrivere un intero programma senza uno switch o un ciclo for in un linguaggio come Ruby o Smalltalk, ad esempio. Saper programmare non vuol dire sapere scrivere un ciclo for.
quindi consigli un buon libro sul polimorfismo per iniziare :asd:
Puo' e deve essere implementato in maniera diversa. Si'.
hai travisato quello che ho detto.. ho funziona nella stessa maniera, non si implementa nella stessa maniera. se sai come funziona un algoritmo lo scrivi in 2 minuti in tutti i linguaggi che conosci, e visto che sono linguaggi diversi che offrono strumenti diversi probabilmente l'implementazione sarà diversa, ma il funzionamente uguale.
quindi consigli un buon libro sul polimorfismo per iniziare :asd:
Puo' e deve essere implementato in maniera diversa. Si'.
hai travisato quello che ho detto.. ho funziona nella stessa maniera, non si implementa nella stessa maniera. se sai come funziona un algoritmo lo scrivi in 2 minuti in tutti i linguaggi che conosci, e visto che sono linguaggi diversi che offrono strumenti diversi probabilmente l'implementazione sarà diversa, ma il funzionamente uguale.
PGI-Bis
11-05-2006, 17:32
Ragazzi ci stiamo rammollendo. Ben 12 risposte prima che degenerasse nella solita scazzottata C non C! Via, avrei giurato che stavolta ci saremmo riusciti in meno di 10. Sarà l'età, sarà lo stress...mah!.
cdimauro
11-05-2006, 17:32
Sono d'accordo con te.. come vedi mi sono corretto nel mio post precedente.
Sì, l'ho visto, ma soltanto dopo aver postato.
Comunque qui http://www.python.it/doc/Howtothink/Howtothink-html-it/index.htm c'è un ottimo manuale introduttivo alla programmazione usando Python, e in generale qui: http://www.python.it/doc/newbie.html ci sono una serie di link, documenti e tutorial su come iniziare a programmare con Python. Tutti in italiano. ;)
Sì, l'ho visto, ma soltanto dopo aver postato.
Comunque qui http://www.python.it/doc/Howtothink/Howtothink-html-it/index.htm c'è un ottimo manuale introduttivo alla programmazione usando Python, e in generale qui: http://www.python.it/doc/newbie.html ci sono una serie di link, documenti e tutorial su come iniziare a programmare con Python. Tutti in italiano. ;)
fek
11-05-2006, 17:58
quindi consigli un buon libro sul polimorfismo per iniziare :asd:
Questo e' ottimo:
http://www.rubycentral.com/book/tut_classes.html
hai travisato quello che ho detto.. ho funziona nella stessa maniera, non si implementa nella stessa maniera. se sai come funziona un algoritmo lo scrivi in 2 minuti in tutti i linguaggi che conosci, e visto che sono linguaggi diversi che offrono strumenti diversi probabilmente l'implementazione sarà diversa, ma il funzionamente uguale.
Credo che sia tu a travisare: non sto solo parlando di semplice implementazione, ma di metodo totalmente diverso nel risolvere lo stesso problema di ordinamento nei due linguaggi.
Questo e' ottimo:
http://www.rubycentral.com/book/tut_classes.html
hai travisato quello che ho detto.. ho funziona nella stessa maniera, non si implementa nella stessa maniera. se sai come funziona un algoritmo lo scrivi in 2 minuti in tutti i linguaggi che conosci, e visto che sono linguaggi diversi che offrono strumenti diversi probabilmente l'implementazione sarà diversa, ma il funzionamente uguale.
Credo che sia tu a travisare: non sto solo parlando di semplice implementazione, ma di metodo totalmente diverso nel risolvere lo stesso problema di ordinamento nei due linguaggi.
fek
11-05-2006, 17:59
Ragazzi ci stiamo rammollendo. Ben 12 risposte prima che degenerasse nella solita scazzottata C non C! Via, avrei giurato che stavolta ci saremmo riusciti in meno di 10. Sarà l'età, sarà lo stress...mah!.
E stavo programmando, non l'ho visto prima :D
E stavo programmando, non l'ho visto prima :D
wingman87
11-05-2006, 21:51
E se iniziassi con Visual Basic? No eh? :cry:
71104
12-05-2006, 02:50
Argomento ricorrente: se vuoi imparare veramente a programmare non iniziare col C. Se impari a programmare in C, poi quando prendi in mano qualunque altro linguaggio di programmazione devi dimenticarti quello che hai imparato e ricominciare daccapo. stai parlando di C o Visual Basic...? :mbe:
71104
12-05-2006, 02:50
E se iniziassi con Visual Basic? No eh? :cry: scordatelo
71104
12-05-2006, 02:59
E' vero il contrario: Java ha le basi sintattiche e logiche per capire il C perche' la sintassi e' molto simile. si, ma Java (imho) dal punto di vista concettuale è un sottoinsieme del C++: se vuoi capire sia C sia Java allora basta che studi C++, il resto sono differenze sintattiche.
Una volta imparato il C anche per fare operazioni semplici e banali, invece, le basi che si sono imparate vanno dimenticate perche' sono deleterie e inutili per programmare in Java. ma perché...? :|
d'accordo che varie cose sono diverse, ma rispetto a tutta la logica che c'è in comune con tantissimi altri linguaggi di programmazione le differenze rimangono in minoranza. tantissimi linguaggi di programmazione hanno le variabili, tantissimi linguaggi hanno i cicli, tantissimi linguaggi hanno blocchi di codice che possiamo chiamare "metodi", "funzioni", o "procedure", tantissimi linguaggi hanno... uff, troppa roba :)
guarda che io capisco benissimo e condivido appieno l'entusiasmo per le tecnologie del futuro ed in particolare per ciò che aumenta la produttività; ma non deve mica trasformarsi in una mistificazione :|
Una volta imparato il C anche per fare operazioni semplici e banali, invece, le basi che si sono imparate vanno dimenticate perche' sono deleterie e inutili per programmare in Java. ma perché...? :|
d'accordo che varie cose sono diverse, ma rispetto a tutta la logica che c'è in comune con tantissimi altri linguaggi di programmazione le differenze rimangono in minoranza. tantissimi linguaggi di programmazione hanno le variabili, tantissimi linguaggi hanno i cicli, tantissimi linguaggi hanno blocchi di codice che possiamo chiamare "metodi", "funzioni", o "procedure", tantissimi linguaggi hanno... uff, troppa roba :)
guarda che io capisco benissimo e condivido appieno l'entusiasmo per le tecnologie del futuro ed in particolare per ciò che aumenta la produttività; ma non deve mica trasformarsi in una mistificazione :|
71104
12-05-2006, 03:02
scusate, ma perchè molti si ostinano a pensare che se non sai come funziona la macchina non puoi/non sai programmare? :confused: se ti può consolare io non la penso affatto così :)
anzi, la penso precisamente all'opposto.
anzi, la penso precisamente all'opposto.
cdimauro
12-05-2006, 08:27
scordatelo
BASIC è un acronimo per Beginner's All purpose Symbolic Instruction Code, "Codice di istruzioni simboliche di uso generale per principianti".
Adesso ci spieghi i motivi del tuo astio contro questo linguaggio, che PER DEFINIZIONE è nato proprio per avvicinare all'informatica, e che comunque non ha nulla da invidiare agli altri (ma non ti starò qui a fare un corso di linguaggi di programmazione e dimostrarti che tutti sono equipotenti). ;)
BASIC è un acronimo per Beginner's All purpose Symbolic Instruction Code, "Codice di istruzioni simboliche di uso generale per principianti".
Adesso ci spieghi i motivi del tuo astio contro questo linguaggio, che PER DEFINIZIONE è nato proprio per avvicinare all'informatica, e che comunque non ha nulla da invidiare agli altri (ma non ti starò qui a fare un corso di linguaggi di programmazione e dimostrarti che tutti sono equipotenti). ;)
VICIUS
12-05-2006, 09:16
BASIC è un acronimo per Beginner's All purpose Symbolic Instruction Code, "Codice di istruzioni simboliche di uso generale per principianti".
Adesso ci spieghi i motivi del tuo astio contro questo linguaggio, che PER DEFINIZIONE è nato proprio per avvicinare all'informatica, e che comunque non ha nulla da invidiare agli altri (ma non ti starò qui a fare un corso di linguaggi di programmazione e dimostrarti che tutti sono equipotenti). ;)
Perché altrimenti è troppo facile :D
ciao ;)
Adesso ci spieghi i motivi del tuo astio contro questo linguaggio, che PER DEFINIZIONE è nato proprio per avvicinare all'informatica, e che comunque non ha nulla da invidiare agli altri (ma non ti starò qui a fare un corso di linguaggi di programmazione e dimostrarti che tutti sono equipotenti). ;)
Perché altrimenti è troppo facile :D
ciao ;)
VICIUS
12-05-2006, 09:17
si, ma Java (imho) dal punto di vista concettuale è un sottoinsieme del C++: se vuoi capire sia C sia Java allora basta che studi C++, il resto sono differenze sintattiche.
Non scherziamo. Il c++ è tropo esteso come linguaggio per un principiante. In genere lo si consiglia a chi si vuole vedere soffrire.
ciao ;)
Non scherziamo. Il c++ è tropo esteso come linguaggio per un principiante. In genere lo si consiglia a chi si vuole vedere soffrire.
ciao ;)
fek
12-05-2006, 10:09
ma perché...? :|
d'accordo che varie cose sono diverse, ma rispetto a tutta la logica che c'è in comune con tantissimi altri linguaggi di programmazione le differenze rimangono in minoranza. tantissimi linguaggi di programmazione hanno le variabili, tantissimi linguaggi hanno i cicli, tantissimi linguaggi hanno blocchi di codice che possiamo chiamare "metodi", "funzioni", o "procedure", tantissimi linguaggi hanno... uff, troppa roba :)
Invece no, Alberto. Guarda anche un'idioma semplicissimo e comune nella programmazione: selezionare il comportamento in base al tipo di dato.
In C la prima cosa che ti insegnano per risolvere il problema e':
if (data.type == SOMETHING)
{
doSomething(data);
}
else
if (data.type == SOMETHING_ESE)
{
doSomethingElse(data);
}
I piu' smaliziati useranno uno switch. Dopo un paio d'anni imperai a maneggiare i puntatori a funzione e creerai una tabella di funzioni. Ricorda che non parliamo di me e di te ma di un principiante e cogliere le sottigliezze dietro ad una tabella di funzioni non e' banale.
Scriverai:
fillDispatchTable(dispatch_table);
dispatch_table[data.type](data);
In Java, invece, il primo giorno ti insegnano che il problema si risolve cosi':
data.Do();
Non dovrebbero insegnare il polimorfismo come primo concetto perche' poi se ne abusa e va disimparato, non totalmente, ma questo e' un altro discorso.
Per il principiante quello e' il modo di risolvere il problema, modella molto da vicino cio' a cui e' abituato nel mondo reale, e' un'astrazione naturale, e' facile da imparare e puo' essere usata fin da subito.
Dopod due anni il principiante di cui sopra impara che quello che ha scritto in Java non e' altro che una tabella di puntatori a funzione in C e se mai scrivera' due righe di codice in C quella sara' subito la sua soluzione, non passera' neppure dalla catena di if e dagli switch, perche' saranno innaturali per lui e saranno meno produttivi. Ed ignoro qui tutti gli idiomi legati alla gestione della memoria, del ciclo di vita delle allocazioni, le stringhe come array di caratteri.
Io e te abbiamo fatto il percorso inverso e sappiamo quanta fatica e' costata passare da anni di programmazione strutturata a concetti quali il polimorfismo che dovrebbero essere naturali. Ti senti di consigliarlo ad un principiante?
d'accordo che varie cose sono diverse, ma rispetto a tutta la logica che c'è in comune con tantissimi altri linguaggi di programmazione le differenze rimangono in minoranza. tantissimi linguaggi di programmazione hanno le variabili, tantissimi linguaggi hanno i cicli, tantissimi linguaggi hanno blocchi di codice che possiamo chiamare "metodi", "funzioni", o "procedure", tantissimi linguaggi hanno... uff, troppa roba :)
Invece no, Alberto. Guarda anche un'idioma semplicissimo e comune nella programmazione: selezionare il comportamento in base al tipo di dato.
In C la prima cosa che ti insegnano per risolvere il problema e':
if (data.type == SOMETHING)
{
doSomething(data);
}
else
if (data.type == SOMETHING_ESE)
{
doSomethingElse(data);
}
I piu' smaliziati useranno uno switch. Dopo un paio d'anni imperai a maneggiare i puntatori a funzione e creerai una tabella di funzioni. Ricorda che non parliamo di me e di te ma di un principiante e cogliere le sottigliezze dietro ad una tabella di funzioni non e' banale.
Scriverai:
fillDispatchTable(dispatch_table);
dispatch_table[data.type](data);
In Java, invece, il primo giorno ti insegnano che il problema si risolve cosi':
data.Do();
Non dovrebbero insegnare il polimorfismo come primo concetto perche' poi se ne abusa e va disimparato, non totalmente, ma questo e' un altro discorso.
Per il principiante quello e' il modo di risolvere il problema, modella molto da vicino cio' a cui e' abituato nel mondo reale, e' un'astrazione naturale, e' facile da imparare e puo' essere usata fin da subito.
Dopod due anni il principiante di cui sopra impara che quello che ha scritto in Java non e' altro che una tabella di puntatori a funzione in C e se mai scrivera' due righe di codice in C quella sara' subito la sua soluzione, non passera' neppure dalla catena di if e dagli switch, perche' saranno innaturali per lui e saranno meno produttivi. Ed ignoro qui tutti gli idiomi legati alla gestione della memoria, del ciclo di vita delle allocazioni, le stringhe come array di caratteri.
Io e te abbiamo fatto il percorso inverso e sappiamo quanta fatica e' costata passare da anni di programmazione strutturata a concetti quali il polimorfismo che dovrebbero essere naturali. Ti senti di consigliarlo ad un principiante?
k0nt3
12-05-2006, 10:55
BASIC è un acronimo per Beginner's All purpose Symbolic Instruction Code, "Codice di istruzioni simboliche di uso generale per principianti".
Adesso ci spieghi i motivi del tuo astio contro questo linguaggio, che PER DEFINIZIONE è nato proprio per avvicinare all'informatica, e che comunque non ha nulla da invidiare agli altri (ma non ti starò qui a fare un corso di linguaggi di programmazione e dimostrarti che tutti sono equipotenti). ;)
non c'è neppure bisogno di spiegarlo.. visual basic fa male alla preparazione di un programmatore. basic ancora ancora per iniziare può andare, ma visual basic è totalmente da sconsigliare a chiunque (VB.NET dicono sia molto meglio).
Io e te abbiamo fatto il percorso inverso e sappiamo quanta fatica e' costata passare da anni di programmazione strutturata a concetti quali il polimorfismo che dovrebbero essere naturali. Ti senti di consigliarlo ad un principiante?
anche io ho fatto il percorso inverso e mi sento di consigliare a tutti di farlo. il problema di te e di altri che odiano il C è che non sono passati a java (o simili) nel momento giusto, cioè prima che la programmazione strutturata si fossilizzasse nel cervello :)
poi ti assicuro che passare da java a C non è affatto banale
riguardo al polimorfismo penso che per un principiante sia più facile pensare a un "se .. allora .. altrimenti" (va ricordato che i principianti affrontano problemi semplici e quindi non si complica troppo il codice) piuttosto che a un polimorfismo che può creare problemi anche a uno che programma da anni.. pensa a uno che inizia! è vero che come astrazione della realtà è molto più facile da capire, peccato che in realtà le cose sono più complicate e i problemi riguardanti il polimorfismo, l'ereditarietà (ecc..) stanno in libroni che più o meno pesano 6kg, è inutile che la fai facile. se uno impara la programmazione a oggetti in qualche modo grossolano deve poi dimenticarla del tutto e riniziare da zero.
Adesso ci spieghi i motivi del tuo astio contro questo linguaggio, che PER DEFINIZIONE è nato proprio per avvicinare all'informatica, e che comunque non ha nulla da invidiare agli altri (ma non ti starò qui a fare un corso di linguaggi di programmazione e dimostrarti che tutti sono equipotenti). ;)
non c'è neppure bisogno di spiegarlo.. visual basic fa male alla preparazione di un programmatore. basic ancora ancora per iniziare può andare, ma visual basic è totalmente da sconsigliare a chiunque (VB.NET dicono sia molto meglio).
Io e te abbiamo fatto il percorso inverso e sappiamo quanta fatica e' costata passare da anni di programmazione strutturata a concetti quali il polimorfismo che dovrebbero essere naturali. Ti senti di consigliarlo ad un principiante?
anche io ho fatto il percorso inverso e mi sento di consigliare a tutti di farlo. il problema di te e di altri che odiano il C è che non sono passati a java (o simili) nel momento giusto, cioè prima che la programmazione strutturata si fossilizzasse nel cervello :)
poi ti assicuro che passare da java a C non è affatto banale
riguardo al polimorfismo penso che per un principiante sia più facile pensare a un "se .. allora .. altrimenti" (va ricordato che i principianti affrontano problemi semplici e quindi non si complica troppo il codice) piuttosto che a un polimorfismo che può creare problemi anche a uno che programma da anni.. pensa a uno che inizia! è vero che come astrazione della realtà è molto più facile da capire, peccato che in realtà le cose sono più complicate e i problemi riguardanti il polimorfismo, l'ereditarietà (ecc..) stanno in libroni che più o meno pesano 6kg, è inutile che la fai facile. se uno impara la programmazione a oggetti in qualche modo grossolano deve poi dimenticarla del tutto e riniziare da zero.
k0nt3
12-05-2006, 11:03
scusate, ma perchè molti si ostinano a pensare che se non sai come funziona la macchina non puoi/non sai programmare? :confused:
estremizzando questa linea di pensiero, tutti i programmatori dovrebbero conoscere l'assembly perchè altrimenti non si può capire come funziona il c!
...o no? :mc:
dal mio punto di vista il motivo per il quale non conviene iniziare dal c non è ne più o ne meno lo stesso per cui ora a scuola non insegnano più a calcolare le radici (almeno guardando alla mia esperienza scolastica e a quella di mio fratello) in quanto esistono le calcolatrici che permettono di trovarne il risultato in meno tempo e meno fatica, e soprattutto perchè non è indispensabile saperlo!
adattando l'esempio al contesto: in c ti devi calcolare a mano le radici (che può essere vista come la gestione della memoria) mentre in java e qualsiasi linguaggio di più alto livello non te ne devi preoccupare perchè se ne occupa lui!
detto questo è ovvio che se qualcuno ha ambizione/esigenza di conoscere nei particolari il funzionamento di un pc il c può aiutare, ma non è indispensabile! (ne la conoscenza del funzionamento della macchina - perlomeno non in forma approfondita - ne la conoscenza del c)!
'iao
non è vero che il C implica la conoscenza approfondita del calcolatore.. l'unica cosa è quando arrivi ai puntatori e devi capire come funziona a grandi linee la memoria. ma pensa a uno che non sa come funziona la memoria e programma a oggetti! è inutile il concetto di puntatore serve lo stesso, altrimenti fai danni e non capisci nemmeno perchè.
il fatto della radice quadrata non è un esempio azzeccato, infatti spero che sai cos'è la radice quadrata (cioè numero il cui quadrato fa x) e se ti chiedo la radice di 16 sai rispondermi senza la calcolatrice. lo stesso deve accadere con la programmazione. cioè uno che impara il C (calcolo a mano) e poi java (calcolatrice) è anche in grado di capire se la "calcolatrice" sta sparando stronzate e perchè. se tu non sapessi fare la radice quadrata e per un qualsiasi motivo sbagli a scrivere il numero nella calcolatrice (ti assicuro che gli errori nel codice sono più frequenti e maggiormente tra i principianti) non te ne rendi conto e vai avanti con il risultato sbagliato.
estremizzando questa linea di pensiero, tutti i programmatori dovrebbero conoscere l'assembly perchè altrimenti non si può capire come funziona il c!
...o no? :mc:
dal mio punto di vista il motivo per il quale non conviene iniziare dal c non è ne più o ne meno lo stesso per cui ora a scuola non insegnano più a calcolare le radici (almeno guardando alla mia esperienza scolastica e a quella di mio fratello) in quanto esistono le calcolatrici che permettono di trovarne il risultato in meno tempo e meno fatica, e soprattutto perchè non è indispensabile saperlo!
adattando l'esempio al contesto: in c ti devi calcolare a mano le radici (che può essere vista come la gestione della memoria) mentre in java e qualsiasi linguaggio di più alto livello non te ne devi preoccupare perchè se ne occupa lui!
detto questo è ovvio che se qualcuno ha ambizione/esigenza di conoscere nei particolari il funzionamento di un pc il c può aiutare, ma non è indispensabile! (ne la conoscenza del funzionamento della macchina - perlomeno non in forma approfondita - ne la conoscenza del c)!
'iao
non è vero che il C implica la conoscenza approfondita del calcolatore.. l'unica cosa è quando arrivi ai puntatori e devi capire come funziona a grandi linee la memoria. ma pensa a uno che non sa come funziona la memoria e programma a oggetti! è inutile il concetto di puntatore serve lo stesso, altrimenti fai danni e non capisci nemmeno perchè.
il fatto della radice quadrata non è un esempio azzeccato, infatti spero che sai cos'è la radice quadrata (cioè numero il cui quadrato fa x) e se ti chiedo la radice di 16 sai rispondermi senza la calcolatrice. lo stesso deve accadere con la programmazione. cioè uno che impara il C (calcolo a mano) e poi java (calcolatrice) è anche in grado di capire se la "calcolatrice" sta sparando stronzate e perchè. se tu non sapessi fare la radice quadrata e per un qualsiasi motivo sbagli a scrivere il numero nella calcolatrice (ti assicuro che gli errori nel codice sono più frequenti e maggiormente tra i principianti) non te ne rendi conto e vai avanti con il risultato sbagliato.
fek
12-05-2006, 11:14
anche io ho fatto il percorso inverso e mi sento di consigliare a tutti di farlo. il problema di te e di altri che odiano il C è che non sono passati a java (o simili) nel momento giusto, cioè prima che la programmazione strutturata si fossilizzasse nel cervello :)
Come spesso accade parli di cose che non sai. Non programmo mai in Java. Il 90% del tempo programmo in C++ o C o simil-C. Io non odio, io uso gli strumenti piu' adatti per il problema che devo risolvere.
riguardo al polimorfismo penso che per un principiante sia più facile pensare a un "se .. allora .. altrimenti" (va ricordato che i principianti affrontano problemi semplici e quindi non si complica troppo il codice)
Pensi male. Il polimorfismo e' un'astrazione naturale per l'uomo. Non lo e' una catena di if-else.
Come spesso accade parli di cose che non sai. Non programmo mai in Java. Il 90% del tempo programmo in C++ o C o simil-C. Io non odio, io uso gli strumenti piu' adatti per il problema che devo risolvere.
riguardo al polimorfismo penso che per un principiante sia più facile pensare a un "se .. allora .. altrimenti" (va ricordato che i principianti affrontano problemi semplici e quindi non si complica troppo il codice)
Pensi male. Il polimorfismo e' un'astrazione naturale per l'uomo. Non lo e' una catena di if-else.
cdimauro
12-05-2006, 13:05
non c'è neppure bisogno di spiegarlo.. visual basic fa male alla preparazione di un programmatore. basic ancora ancora per iniziare può andare, ma visual basic è totalmente da sconsigliare a chiunque (VB.NET dicono sia molto meglio).
Continui a parlare di cose che non conosci assolutamente (non a caso hai scritto "dicono", perché non ne sai niente): il VisualBasic non ha nulla da invidiare a tanti altri linguaggi, tantomeno al C (un linguaggio che deve usare #DEFINE per definire le costanti o che è ancora fermo agli #include anziché adottare il concetto di modulo/unit/package, è semplicemente da trogloditi informatici), e ha una sintassi molto semplice ed elegante.
L'ultima incarnazione, in particolare, gli consente di consumare tranquillamente classi scritte in C#, C++/CLI, Delphi.NET e chi più ne ha più ne metta. Se conosci minimamente .NET dovresti già capire cosa significa tutto ciò.
Basta con le leggende metropolitane spiattellate ogni momento: informarsi prima di sputare sentenze sarebbe cosa assai gradita.
Continui a parlare di cose che non conosci assolutamente (non a caso hai scritto "dicono", perché non ne sai niente): il VisualBasic non ha nulla da invidiare a tanti altri linguaggi, tantomeno al C (un linguaggio che deve usare #DEFINE per definire le costanti o che è ancora fermo agli #include anziché adottare il concetto di modulo/unit/package, è semplicemente da trogloditi informatici), e ha una sintassi molto semplice ed elegante.
L'ultima incarnazione, in particolare, gli consente di consumare tranquillamente classi scritte in C#, C++/CLI, Delphi.NET e chi più ne ha più ne metta. Se conosci minimamente .NET dovresti già capire cosa significa tutto ciò.
Basta con le leggende metropolitane spiattellate ogni momento: informarsi prima di sputare sentenze sarebbe cosa assai gradita.
shinya
12-05-2006, 14:11
I miei 2 cent sulla questione...
Premetto che mi trovo assolutamente concorde alle posizioni di fek; inoltre aggiungo che la mentalità del tipo "comincia dal basso" è tipica dell'università e della scuola italiana, ed è naturale che gli studenti vengano contagiati da questo tipo di ragionamento.
Il modus operandi si basa sul concetto che una volta imparato a salire le scale sulle mani, sia banale passare ad usare i piedi per farlo.
E qui si aprono due questioni: 1- è vero? e 2 - è utile?
Che sia vero ho i miei dubbi, e concordo con fek quando dice che "dopo due anni devi disimparare ...". Che sia utile...boh, se vuoi essere un giocoliere e passare dal salire le scale dai piedi alle mani o se vuoi conoscere tutti i più oscuri segreti di come funzioni il meccanismo di salire le scale a basso livello, si è utile. Altrimenti è una perdita di tempo, soprattutto se non sai salire le scale in nessun modo.
Tornando al discorso della mentalità, la colpa è dei professori che nella maggior parte dei casi sono dei raccomandati, messi lì perchè hanno tirato il bavero della giacca giusta, senza un reale interesse al miglioramento personale e professionale. Il che si traduce in una fossilizzazione culturale che ha questi risvolti, e che si tramanda agli studenti che poi pensano "se non sai scrivere su carta un gestore di liste in C in 10 minuti fai schifo".
Ergo, la colpa è del sistema all'italiana, ed è bene cominciare a salire le scale con i piedi.
E poi se dovessimo sempre partire dal basso, alle elementari si dovrebbe insegnare Goedel e i Principia Mathematica di Russell invece dell'aritmetica. Il che potrebbe anche essere interessante :help:
ps. ovviamente anch'io ho cominciato dal C. :)
Premetto che mi trovo assolutamente concorde alle posizioni di fek; inoltre aggiungo che la mentalità del tipo "comincia dal basso" è tipica dell'università e della scuola italiana, ed è naturale che gli studenti vengano contagiati da questo tipo di ragionamento.
Il modus operandi si basa sul concetto che una volta imparato a salire le scale sulle mani, sia banale passare ad usare i piedi per farlo.
E qui si aprono due questioni: 1- è vero? e 2 - è utile?
Che sia vero ho i miei dubbi, e concordo con fek quando dice che "dopo due anni devi disimparare ...". Che sia utile...boh, se vuoi essere un giocoliere e passare dal salire le scale dai piedi alle mani o se vuoi conoscere tutti i più oscuri segreti di come funzioni il meccanismo di salire le scale a basso livello, si è utile. Altrimenti è una perdita di tempo, soprattutto se non sai salire le scale in nessun modo.
Tornando al discorso della mentalità, la colpa è dei professori che nella maggior parte dei casi sono dei raccomandati, messi lì perchè hanno tirato il bavero della giacca giusta, senza un reale interesse al miglioramento personale e professionale. Il che si traduce in una fossilizzazione culturale che ha questi risvolti, e che si tramanda agli studenti che poi pensano "se non sai scrivere su carta un gestore di liste in C in 10 minuti fai schifo".
Ergo, la colpa è del sistema all'italiana, ed è bene cominciare a salire le scale con i piedi.
E poi se dovessimo sempre partire dal basso, alle elementari si dovrebbe insegnare Goedel e i Principia Mathematica di Russell invece dell'aritmetica. Il che potrebbe anche essere interessante :help:
ps. ovviamente anch'io ho cominciato dal C. :)
k0nt3
12-05-2006, 19:26
Continui a parlare di cose che non conosci assolutamente (non a caso hai scritto "dicono", perché non ne sai niente): il VisualBasic non ha nulla da invidiare a tanti altri linguaggi, tantomeno al C (un linguaggio che deve usare #DEFINE per definire le costanti o che è ancora fermo agli #include anziché adottare il concetto di modulo/unit/package, è semplicemente da trogloditi informatici), e ha una sintassi molto semplice ed elegante.
tu parli senza sapere! ho detto che non conosco VB.NET se leggi bene quello che ho scritto. BASIC l'ho usato e ho detto che per iniziare può essere un'alternativa, ma non si va lontano. VisualBasic lo conosco anche quello e sono stato obbligato a usarlo un paio di volte scoprendo che ha una sintassi orrenda, disordinata e che quando hai scritto un programma con più di 6 bottoni non ci capisci già più niente... alla faccia della mantenibilità :muro:
ps. è un caso che anche MS ha abbandonato VB quando si è messa a scrivere windows defender? se ti interessa ritrovo l'intervista che avevo letto :asd:
L'ultima incarnazione, in particolare, gli consente di consumare tranquillamente classi scritte in C#, C++/CLI, Delphi.NET e chi più ne ha più ne metta. Se conosci minimamente .NET dovresti già capire cosa significa tutto ciò.
lo spero che VB.NET sia meglio!
Basta con le leggende metropolitane spiattellate ogni momento: informarsi prima di sputare sentenze sarebbe cosa assai gradita.
appunto
@shinya: sono assolutamente daccordo con te per quello che riguarda i professori.. ho sempre ignorato quello che pensano, credo sia meglio sperimentare di persona e valutare da sè. ho un odio particolare per la categoria :) ma non generalizzo perchè ne ho incontrati alcuni veramente preparati e che ringrazio per il bagaglio culturale che mi hanno lasciato :sofico:
poi il tuo paragone con la matematica lo riproporrei in questo modo:
Goedel e i Principia Mathematica di Russell -> assembler
aritmetica -> C
come vedi nessuno di noi si è mai sognato di iniziare dall'assembler come mai nessuno si sognerà di iniziare da Goedel :D
per il resto in generale penso che il C insegnato bene non è affatto così complicato come dite. capire le liste è una delle cose più costruttive che uno possa fare quando impara a programmare (ed è anche una soddisfazione :p ).
tu parli senza sapere! ho detto che non conosco VB.NET se leggi bene quello che ho scritto. BASIC l'ho usato e ho detto che per iniziare può essere un'alternativa, ma non si va lontano. VisualBasic lo conosco anche quello e sono stato obbligato a usarlo un paio di volte scoprendo che ha una sintassi orrenda, disordinata e che quando hai scritto un programma con più di 6 bottoni non ci capisci già più niente... alla faccia della mantenibilità :muro:
ps. è un caso che anche MS ha abbandonato VB quando si è messa a scrivere windows defender? se ti interessa ritrovo l'intervista che avevo letto :asd:
L'ultima incarnazione, in particolare, gli consente di consumare tranquillamente classi scritte in C#, C++/CLI, Delphi.NET e chi più ne ha più ne metta. Se conosci minimamente .NET dovresti già capire cosa significa tutto ciò.
lo spero che VB.NET sia meglio!
Basta con le leggende metropolitane spiattellate ogni momento: informarsi prima di sputare sentenze sarebbe cosa assai gradita.
appunto
@shinya: sono assolutamente daccordo con te per quello che riguarda i professori.. ho sempre ignorato quello che pensano, credo sia meglio sperimentare di persona e valutare da sè. ho un odio particolare per la categoria :) ma non generalizzo perchè ne ho incontrati alcuni veramente preparati e che ringrazio per il bagaglio culturale che mi hanno lasciato :sofico:
poi il tuo paragone con la matematica lo riproporrei in questo modo:
Goedel e i Principia Mathematica di Russell -> assembler
aritmetica -> C
come vedi nessuno di noi si è mai sognato di iniziare dall'assembler come mai nessuno si sognerà di iniziare da Goedel :D
per il resto in generale penso che il C insegnato bene non è affatto così complicato come dite. capire le liste è una delle cose più costruttive che uno possa fare quando impara a programmare (ed è anche una soddisfazione :p ).
71104
12-05-2006, 19:34
BASIC è un acronimo per Beginner's All purpose Symbolic Instruction Code, "Codice di istruzioni simboliche di uso generale per principianti".
Adesso ci spieghi i motivi del tuo astio contro questo linguaggio, che PER DEFINIZIONE è nato proprio per avvicinare all'informatica, e che comunque non ha nulla da invidiare agli altri (ma non ti starò qui a fare un corso di linguaggi di programmazione e dimostrarti che tutti sono equipotenti). ;) ma io mica ho nulla contro BASIC, tant'è vero che QBasic è stato il secondo linguaggio che ho imparato :p
il mio è odio razziale verso VISUAL Basic... e non penso ci voglia molto a capire perché :D
se fek sconsiglia addirittura il C solamente perché ci sono gli if anziché i metodi virtuali allora chissà cosa ne pensa di Visual Basic... :rolleyes:
cionci, preparati a censurare fek :D
Adesso ci spieghi i motivi del tuo astio contro questo linguaggio, che PER DEFINIZIONE è nato proprio per avvicinare all'informatica, e che comunque non ha nulla da invidiare agli altri (ma non ti starò qui a fare un corso di linguaggi di programmazione e dimostrarti che tutti sono equipotenti). ;) ma io mica ho nulla contro BASIC, tant'è vero che QBasic è stato il secondo linguaggio che ho imparato :p
il mio è odio razziale verso VISUAL Basic... e non penso ci voglia molto a capire perché :D
se fek sconsiglia addirittura il C solamente perché ci sono gli if anziché i metodi virtuali allora chissà cosa ne pensa di Visual Basic... :rolleyes:
cionci, preparati a censurare fek :D
71104
12-05-2006, 19:36
Perché altrimenti è troppo facile :D a essere facile è facile, il difficile viene dopo, quando da VB devi passare a un vero linguaggio di programmazione moderno... ;)
71104
12-05-2006, 19:52
Invece no, Alberto. Guarda anche un'idioma semplicissimo e comune nella programmazione: selezionare il comportamento in base al tipo di dato.[...] d'accordo, questo concetto l'ho capito benissimo e lo condivido (quando inizi a tagliare via gli if la complessità ciclomatica si riduce che è un piacere, e l'efficienza non ne soffre per nulla), ma ripeto che imho è una delle pochissime cose che devi rasare via dalla tua testa nel passaggio da C ad un linguaggio Object Oriented. ci sono tantissime altre cose che uno che non ha mai studiato la programmazione non sa e che impara col C e gli rimangono anche quando passa a Java; intendo roba stupidissima (per noi) come i concetti di variabile, di for, di ciclo in generale, di funzione (che poi diventerà metodo), e così via; e anche il concetto di branch e l'if ovviamente, perché comunque non è che quando programmi a oggetti tutti gli if se ne vanno... :)
insomma, dire: Argomento ricorrente: se vuoi imparare veramente a programmare non iniziare col C. Se impari a programmare in C, poi quando prendi in mano qualunque altro linguaggio di programmazione devi dimenticarti quello che hai imparato e ricominciare daccapo. mi sembra esagerato, quando prendi in mano un altro linguaggio di programmazione, però a oggetti, tante cose restano.
Io e te abbiamo fatto il percorso inverso e sappiamo quanta fatica e' costata passare da anni di programmazione strutturata a concetti quali il polimorfismo che dovrebbero essere naturali. Ti senti di consigliarlo ad un principiante? dipende dal principiante: se al principiante interessa solo avere il risultato e il prima possibile allora no, ma se il principiante fossi io da piccolo allora mille volte si: a me è sempre piaciuto capire cosa c'è "under the hood". alcuni lo chiamano masochismo, altri sete di cultura :)
insomma, dire: Argomento ricorrente: se vuoi imparare veramente a programmare non iniziare col C. Se impari a programmare in C, poi quando prendi in mano qualunque altro linguaggio di programmazione devi dimenticarti quello che hai imparato e ricominciare daccapo. mi sembra esagerato, quando prendi in mano un altro linguaggio di programmazione, però a oggetti, tante cose restano.
Io e te abbiamo fatto il percorso inverso e sappiamo quanta fatica e' costata passare da anni di programmazione strutturata a concetti quali il polimorfismo che dovrebbero essere naturali. Ti senti di consigliarlo ad un principiante? dipende dal principiante: se al principiante interessa solo avere il risultato e il prima possibile allora no, ma se il principiante fossi io da piccolo allora mille volte si: a me è sempre piaciuto capire cosa c'è "under the hood". alcuni lo chiamano masochismo, altri sete di cultura :)
Th3 Kn0wl3dg3
12-05-2006, 22:13
mi state facendo confondere ancora di più!
wisher
12-05-2006, 22:15
mi state facendo confondere ancora di più!
in effetti hai ragione, ormai si capisce poco
in effetti hai ragione, ormai si capisce poco
h1jack3r
13-05-2006, 01:04
adesso mi spiegate anche come con la programmazione ad oggetti spariscono magicamente gli if però! :)
Ho fatto solo un corso all'uni e mi ha dato un'infarinatura generale ma non ho mai approfondito veramente.
Ho fatto solo un corso all'uni e mi ha dato un'infarinatura generale ma non ho mai approfondito veramente.
71104
13-05-2006, 02:16
adesso mi spiegate anche come con la programmazione ad oggetti spariscono magicamente gli if però! :)
Ho fatto solo un corso all'uni e mi ha dato un'infarinatura generale ma non ho mai approfondito veramente. l'ha spiegato fek molto chiaramente più su; approccio in C:
struct A
{
int nType;
...
} a;
.
.
.
if (a.nType == SOMETHING) {
DoSomething(&a);
}
else if (a.nType == SOMETHING_ELSE) {
DoSomethingElse(&a);
}
approccio C++ Object-Oriented:
class I
{
public:
virtual Do() = 0;
};
class SomeType : public I
{
public:
virtual Do();
};
class SomeOtherType : public I
{
public:
virtual Do();
};
I *pInstance = ... ;
.
.
.
pInstance->Do();
:)
Ho fatto solo un corso all'uni e mi ha dato un'infarinatura generale ma non ho mai approfondito veramente. l'ha spiegato fek molto chiaramente più su; approccio in C:
struct A
{
int nType;
...
} a;
.
.
.
if (a.nType == SOMETHING) {
DoSomething(&a);
}
else if (a.nType == SOMETHING_ELSE) {
DoSomethingElse(&a);
}
approccio C++ Object-Oriented:
class I
{
public:
virtual Do() = 0;
};
class SomeType : public I
{
public:
virtual Do();
};
class SomeOtherType : public I
{
public:
virtual Do();
};
I *pInstance = ... ;
.
.
.
pInstance->Do();
:)
71104
13-05-2006, 02:35
il VisualBasic non ha nulla da invidiare a tanti altri linguaggi, ciò che ha da invidiare cambia da versione a versione; la 6 ad esempio ha da invidiare una OOP decente.
secondo me il BASIC è un linguaggio del passato forzato nel presente da quell'obbrobbrio di VB; può darsi che le versioni più recenti .NET siano migliori della 6, non saprei... ma ad ogni modo secondo me il BASIC nel 2006 può avere soltanto scopi didattici, niente più; le interfacce grafiche nel 2006 richiedono la OOP, e BASIC non è assolutamente nato per essere OO, quindi non è assolutamente in linea con essa.
tantomeno al C (un linguaggio che deve usare #DEFINE per definire le costanti il C99 non più! ;)
è stato introdotto const, a quanto ne so. se ne sentiva veramente il bisogno, anche le estensioni del compilatore Microsoft (che di base è C89) includono const.
o che è ancora fermo agli #include anziché adottare il concetto di modulo/unit/package, hum, su questo posso anche essere d'accordo: a causa dell'inclusione manuale il programmatore è sempre costretto a proteggere gli headers dall'inclusione multipla; ma bisognerebbe anche vedere se sia possibile realizzare in C/C++ un sistema di packages (stile Java) che non tolga potenza e controllo al programmatore: più automatizzi meno dai la possibilità di controllare. su certe cose il controllo non serve, ma in C il controllo di ogni minimo aspetto della situazione serve sempre perché il C è il linguaggio usato ad esempio per programmare i kernel dei sistemi operativi e altri componenti di sistema.
è semplicemente da trogloditi informatici), certe volte è ancora necessario usare questi linguaggi ormai relativamente vecchi. e potremo evolverci quanto ci pare, potranno arrivare interi sistemi operativi in Java, ma il layer scritto in C e assembly ci sarà sempre, o comunque ancora per molto; trovo molto improbabile che il futuro abbia in serbo macchine con JVM firmware, almeno non quello immediato.
L'ultima incarnazione, in particolare, gli consente di consumare tranquillamente classi scritte in C#, C++/CLI, Delphi.NET e chi più ne ha più ne metta. Se conosci minimamente .NET dovresti già capire cosa significa tutto ciò. infatti, nonostante questo Visual Basic sia quello che è, è stato un indubbio successo per Microsoft. la solita storia.
Basta con le leggende metropolitane spiattellate ogni momento: informarsi prima di sputare sentenze sarebbe cosa assai gradita. io non son proprio il tipo sai :)
tutto quello che ho appena scritto lo affermo perché l'ho provato sulla mia pelle (ebbene si: ho provato a programmare in Visual Basic qualche volta).
secondo me il BASIC è un linguaggio del passato forzato nel presente da quell'obbrobbrio di VB; può darsi che le versioni più recenti .NET siano migliori della 6, non saprei... ma ad ogni modo secondo me il BASIC nel 2006 può avere soltanto scopi didattici, niente più; le interfacce grafiche nel 2006 richiedono la OOP, e BASIC non è assolutamente nato per essere OO, quindi non è assolutamente in linea con essa.
tantomeno al C (un linguaggio che deve usare #DEFINE per definire le costanti il C99 non più! ;)
è stato introdotto const, a quanto ne so. se ne sentiva veramente il bisogno, anche le estensioni del compilatore Microsoft (che di base è C89) includono const.
o che è ancora fermo agli #include anziché adottare il concetto di modulo/unit/package, hum, su questo posso anche essere d'accordo: a causa dell'inclusione manuale il programmatore è sempre costretto a proteggere gli headers dall'inclusione multipla; ma bisognerebbe anche vedere se sia possibile realizzare in C/C++ un sistema di packages (stile Java) che non tolga potenza e controllo al programmatore: più automatizzi meno dai la possibilità di controllare. su certe cose il controllo non serve, ma in C il controllo di ogni minimo aspetto della situazione serve sempre perché il C è il linguaggio usato ad esempio per programmare i kernel dei sistemi operativi e altri componenti di sistema.
è semplicemente da trogloditi informatici), certe volte è ancora necessario usare questi linguaggi ormai relativamente vecchi. e potremo evolverci quanto ci pare, potranno arrivare interi sistemi operativi in Java, ma il layer scritto in C e assembly ci sarà sempre, o comunque ancora per molto; trovo molto improbabile che il futuro abbia in serbo macchine con JVM firmware, almeno non quello immediato.
L'ultima incarnazione, in particolare, gli consente di consumare tranquillamente classi scritte in C#, C++/CLI, Delphi.NET e chi più ne ha più ne metta. Se conosci minimamente .NET dovresti già capire cosa significa tutto ciò. infatti, nonostante questo Visual Basic sia quello che è, è stato un indubbio successo per Microsoft. la solita storia.
Basta con le leggende metropolitane spiattellate ogni momento: informarsi prima di sputare sentenze sarebbe cosa assai gradita. io non son proprio il tipo sai :)
tutto quello che ho appena scritto lo affermo perché l'ho provato sulla mia pelle (ebbene si: ho provato a programmare in Visual Basic qualche volta).
wingman87
13-05-2006, 15:13
Secondo me il VB x iniziare va bene, perchè uno che vuole avvicinarsi alla programmazione forse ha anche bisogno di vedere dei risultati nell'immediato, x non smaronarsi subito..
Una volta visto ciò che si può fare si può passare a linguaggi + completi (ma anche più complicati)..
Io ho iniziato con il Turbo Pascal (da solo tanti anni fa), poi ho fatto una lunga pausa, poi ho usato il C (a scuola), e adesso uso VB e C++ (a scuola). Non mi sono rotto subito xk l'informatica mi è sempre piaciuta. Cmq fino ad ora il VB è il linguaggio che mi ha dato maggiori soddisfazioni, sicuramente xk x imparare il c++ ci vuole molto più tempo e anche più pazienza, comunque piano piano lo imparerò.
Una volta visto ciò che si può fare si può passare a linguaggi + completi (ma anche più complicati)..
Io ho iniziato con il Turbo Pascal (da solo tanti anni fa), poi ho fatto una lunga pausa, poi ho usato il C (a scuola), e adesso uso VB e C++ (a scuola). Non mi sono rotto subito xk l'informatica mi è sempre piaciuta. Cmq fino ad ora il VB è il linguaggio che mi ha dato maggiori soddisfazioni, sicuramente xk x imparare il c++ ci vuole molto più tempo e anche più pazienza, comunque piano piano lo imparerò.
71104
13-05-2006, 15:30
fidati, il C++ lo impareresti molto prima se non avessi studiato Visual Basic. fek non può che essere d'accordo con me, almeno se ti riferisci alla versione 6 di VB.
e arifidati, che c'è modo anche in C++ di ottenere risultati velocemente; altrimenti se proprio è di primaria importanza che l'informatica ti gratifichi il prima possibile, spostati su un linguaggio più semplice come Java o C#, ma VB è da rimuovere.
e arifidati, che c'è modo anche in C++ di ottenere risultati velocemente; altrimenti se proprio è di primaria importanza che l'informatica ti gratifichi il prima possibile, spostati su un linguaggio più semplice come Java o C#, ma VB è da rimuovere.
k0nt3
13-05-2006, 15:56
e arifidati, che c'è modo anche in C++ di ottenere risultati velocemente;
parli di questo? http://www.trolltech.com/products/qt/learnmore/video/demos/browser
ps. mamma mia quanto mi diverto a cospargere i forum pieni di fans di VB con questo video :rotfl: :sofico: :ciapet:
parli di questo? http://www.trolltech.com/products/qt/learnmore/video/demos/browser
ps. mamma mia quanto mi diverto a cospargere i forum pieni di fans di VB con questo video :rotfl: :sofico: :ciapet:
PGI-Bis
13-05-2006, 16:35
A me Visual Basic piace, m'è sempre piaciuto e credo che sia un sistema come un'altro per iniziare a programmare. Credo anche che si possa usare per approfondire le proprie capacità di programmatore, ci si può costruire una bellissima carriera professionale e concluderla in piena e pari dignità.
fek
14-05-2006, 10:26
A me Visual Basic piace, m'è sempre piaciuto e credo che sia un sistema come un'altro per iniziare a programmare. Credo anche che si possa usare per approfondire le proprie capacità di programmatore, ci si può costruire una bellissima carriera professionale e concluderla in piena e pari dignità.
Infatti e' diventato con le ultime versioni un ottimo linguaggio, molto semplice da usare. Perfetto per principianti e per determinati compiti, come scrivere interfacce a database.
Come sempre, chi denigra un linguaggio di programmazione per partito preso, lo fa per ignoranza e perche' non sa che un linguaggio e' solo uno strumento adatto ad un compito.
Infatti e' diventato con le ultime versioni un ottimo linguaggio, molto semplice da usare. Perfetto per principianti e per determinati compiti, come scrivere interfacce a database.
Come sempre, chi denigra un linguaggio di programmazione per partito preso, lo fa per ignoranza e perche' non sa che un linguaggio e' solo uno strumento adatto ad un compito.
fek
14-05-2006, 10:35
dipende dal principiante: se al principiante interessa solo avere il risultato e il prima possibile allora no, ma se il principiante fossi io da piccolo allora mille volte si: a me è sempre piaciuto capire cosa c'è "under the hood". alcuni lo chiamano masochismo, altri sete di cultura :)
Tu sei pazzo e non conti :D
Qui si parla di un ragazzo che non ha mai programmato prima e che immagino voglia ottenere qualche risultato presto, e, soprattutto, imparare al meglio le basi.
Ripeto la mia affermazione: devi disimparare tutto. Guarda l'ultimo task sui menu di Diamonds, e' scritto in C. Lo leggi e te ne accorgi subito. Il design del codice e' C. Con un piccolo refactoring di venti minuti, sono saltate via meta' delle righe di codice, il design e' diventato piu' orientato agli oggetti, non c'e' neppure un metodo virtuale (niente polimorfismo). Meta' delle righe di codice, solo per aver programmato in Java piuttosto che in C. Ecco il mio discorso sul disimparare quello che hai imparato in C, non parlo degli if e dei for, parlo della mentalita' che ti porta a risolvere i problemi in C in un modo e in Java/C#/Ruby/etc in un modo diverso, piu' naturale, piu' semplice.
Fai unit testing in C ;)
hum, su questo posso anche essere d'accordo: a causa dell'inclusione manuale il programmatore è sempre costretto a proteggere gli headers dall'inclusione multipla; ma bisognerebbe anche vedere se sia possibile realizzare in C/C++ un sistema di packages (stile Java) che non tolga potenza e controllo al programmatore: più automatizzi meno dai la possibilità di controllare. su certe cose il controllo non serve, ma in C il controllo di ogni minimo aspetto della situazione serve sempre perché il C è il linguaggio usato ad esempio per programmare i kernel dei sistemi operativi e altri componenti di sistema.
Su Design And Evolution of C++ di Stroustrup c'e' una descrizione di una possibile estensione del C++ che aggiunga il concetto di include al linguaggio e non via direttiva di preprocessing. E' molto interessante. Per altro, e' un libro che DEVI leggere.
Tu sei pazzo e non conti :D
Qui si parla di un ragazzo che non ha mai programmato prima e che immagino voglia ottenere qualche risultato presto, e, soprattutto, imparare al meglio le basi.
Ripeto la mia affermazione: devi disimparare tutto. Guarda l'ultimo task sui menu di Diamonds, e' scritto in C. Lo leggi e te ne accorgi subito. Il design del codice e' C. Con un piccolo refactoring di venti minuti, sono saltate via meta' delle righe di codice, il design e' diventato piu' orientato agli oggetti, non c'e' neppure un metodo virtuale (niente polimorfismo). Meta' delle righe di codice, solo per aver programmato in Java piuttosto che in C. Ecco il mio discorso sul disimparare quello che hai imparato in C, non parlo degli if e dei for, parlo della mentalita' che ti porta a risolvere i problemi in C in un modo e in Java/C#/Ruby/etc in un modo diverso, piu' naturale, piu' semplice.
Fai unit testing in C ;)
hum, su questo posso anche essere d'accordo: a causa dell'inclusione manuale il programmatore è sempre costretto a proteggere gli headers dall'inclusione multipla; ma bisognerebbe anche vedere se sia possibile realizzare in C/C++ un sistema di packages (stile Java) che non tolga potenza e controllo al programmatore: più automatizzi meno dai la possibilità di controllare. su certe cose il controllo non serve, ma in C il controllo di ogni minimo aspetto della situazione serve sempre perché il C è il linguaggio usato ad esempio per programmare i kernel dei sistemi operativi e altri componenti di sistema.
Su Design And Evolution of C++ di Stroustrup c'e' una descrizione di una possibile estensione del C++ che aggiunga il concetto di include al linguaggio e non via direttiva di preprocessing. E' molto interessante. Per altro, e' un libro che DEVI leggere.
fek
14-05-2006, 10:40
Secondo me il VB x iniziare va bene, perchè uno che vuole avvicinarsi alla programmazione forse ha anche bisogno di vedere dei risultati nell'immediato, x non smaronarsi subito..
Una volta visto ciò che si può fare si può passare a linguaggi + completi (ma anche più complicati)..
Io ho iniziato con il Turbo Pascal (da solo tanti anni fa), poi ho fatto una lunga pausa, poi ho usato il C (a scuola), e adesso uso VB e C++ (a scuola). Non mi sono rotto subito xk l'informatica mi è sempre piaciuta. Cmq fino ad ora il VB è il linguaggio che mi ha dato maggiori soddisfazioni, sicuramente xk x imparare il c++ ci vuole molto più tempo e anche più pazienza, comunque piano piano lo imparerò.
Io non inizierei con VB solo perche' e' un linguaggio totalmente proprietario e ti lega ad una sola piattaforma hardware/software (PC + .NET). All'inizio e' facile pensare che la programmazione sia solo quella, perche' non si conoscono alternative.
Java e' comunque proprietario, ma c'e' un'amplissima comunita' open source e molte delle idee piu' innovative sulla costruzione del software vengono da questa comunita'.
Io consiglierei, avendone il tempo, di affiancare a Java un linguaggio non C-like come Ruby o Python: anche con due linguaggi sarebbe molto piu' semplice che provare a imparare solo il C, infinitamente piu' semplice che imparare quella bestia del C++ e si avrebbe una visione davvero molto completa della programmazione, da un punto di vista molto alto.
Da li' a imparare linguaggi a basso livello come il C e bestie come il C++ il passo e' davvero minimo, perche' le basi sono molto solide. Il percorso inverso dura invece una decina d'anni abbondanti.
Una volta visto ciò che si può fare si può passare a linguaggi + completi (ma anche più complicati)..
Io ho iniziato con il Turbo Pascal (da solo tanti anni fa), poi ho fatto una lunga pausa, poi ho usato il C (a scuola), e adesso uso VB e C++ (a scuola). Non mi sono rotto subito xk l'informatica mi è sempre piaciuta. Cmq fino ad ora il VB è il linguaggio che mi ha dato maggiori soddisfazioni, sicuramente xk x imparare il c++ ci vuole molto più tempo e anche più pazienza, comunque piano piano lo imparerò.
Io non inizierei con VB solo perche' e' un linguaggio totalmente proprietario e ti lega ad una sola piattaforma hardware/software (PC + .NET). All'inizio e' facile pensare che la programmazione sia solo quella, perche' non si conoscono alternative.
Java e' comunque proprietario, ma c'e' un'amplissima comunita' open source e molte delle idee piu' innovative sulla costruzione del software vengono da questa comunita'.
Io consiglierei, avendone il tempo, di affiancare a Java un linguaggio non C-like come Ruby o Python: anche con due linguaggi sarebbe molto piu' semplice che provare a imparare solo il C, infinitamente piu' semplice che imparare quella bestia del C++ e si avrebbe una visione davvero molto completa della programmazione, da un punto di vista molto alto.
Da li' a imparare linguaggi a basso livello come il C e bestie come il C++ il passo e' davvero minimo, perche' le basi sono molto solide. Il percorso inverso dura invece una decina d'anni abbondanti.
PGI-Bis
14-05-2006, 11:08
Ora faccio la solita figura di quello strano, ma volendo bazzicare sul piano dell'orientamento agli oggetti si potrebbe anche dare un'occhiata a Squeak, che è una piattaforma in stile Visual Works, basata su Smalltalk80.
A mio giudizio è un po' carente la documentazione sulle librerie a corredo. In compenso il manuali sul linguaggio e sull'ambiente (visivamente uguale a VisualWorks, di cui parla ogni manuale su Smalltalk) abbondano.
Dico Squeak/Smalltalk perchè nella costruzione di un oggetto esiste una separazione "fisica" tra dichiarazione delle capacità e definizione delle capacità che potrebbe anche agevolare l'apprendimento.
Ritengo che quel particolare genere di piattaforma offra l'occasione di toccare con mano il concetto di "ambiente in cui esistono gli oggetti", caratteristica simulabile (vedi i server J2EE) ma non direttamente accessibile nella piattaforma Java.
Smalltalk è poi una lingua non fortemente tipizzata (o tipata?) il che, a mio avviso, aiuta a comprendere come la comunicazione tra oggetti sia un che di più articolato dell'invocazione di un metodo (in particolare sottolinea la convenzionalità del protocollo di comunicazione).
A mio giudizio è un po' carente la documentazione sulle librerie a corredo. In compenso il manuali sul linguaggio e sull'ambiente (visivamente uguale a VisualWorks, di cui parla ogni manuale su Smalltalk) abbondano.
Dico Squeak/Smalltalk perchè nella costruzione di un oggetto esiste una separazione "fisica" tra dichiarazione delle capacità e definizione delle capacità che potrebbe anche agevolare l'apprendimento.
Ritengo che quel particolare genere di piattaforma offra l'occasione di toccare con mano il concetto di "ambiente in cui esistono gli oggetti", caratteristica simulabile (vedi i server J2EE) ma non direttamente accessibile nella piattaforma Java.
Smalltalk è poi una lingua non fortemente tipizzata (o tipata?) il che, a mio avviso, aiuta a comprendere come la comunicazione tra oggetti sia un che di più articolato dell'invocazione di un metodo (in particolare sottolinea la convenzionalità del protocollo di comunicazione).
fek
14-05-2006, 11:42
Programmare senza if? Si' si puo', tratto da una storia vera, Diamonds, in Java.
Prima del refactoring:
public void selectNextItem()
{
int selectedActionIndex = selectedMenuItem.index();
if (selectedActionIndex == currentMenuLevelTop)
{
selectedActionIndex = currentMenuLevelBase;
}
else
{
++selectedActionIndex;
}
moveMenuSprite(selectedActionIndex);
selectedMenuItem = menuItems[selectedActionIndex];
}
Dopo il refactoring:
public void selectNextItem()
{
selectedMenuItem = selectedMenuItem.nextItem();
moveMenuSprite(selectedMenuItem.index());
}
PGI, questo refactoring e' stato fatto quasi interamente usando i comandi di refactoring di Eclipse, quelli implementati secondo i passi del libro di Fowler, e dimmi che non funziona :)
Prima del refactoring:
public void selectNextItem()
{
int selectedActionIndex = selectedMenuItem.index();
if (selectedActionIndex == currentMenuLevelTop)
{
selectedActionIndex = currentMenuLevelBase;
}
else
{
++selectedActionIndex;
}
moveMenuSprite(selectedActionIndex);
selectedMenuItem = menuItems[selectedActionIndex];
}
Dopo il refactoring:
public void selectNextItem()
{
selectedMenuItem = selectedMenuItem.nextItem();
moveMenuSprite(selectedMenuItem.index());
}
PGI, questo refactoring e' stato fatto quasi interamente usando i comandi di refactoring di Eclipse, quelli implementati secondo i passi del libro di Fowler, e dimmi che non funziona :)
k0nt3
14-05-2006, 11:48
Infatti e' diventato con le ultime versioni un ottimo linguaggio, molto semplice da usare. Perfetto per principianti e per determinati compiti, come scrivere interfacce a database.
con le ultime versioni includi anche VB6? (voglio sentirtelo dire :asd: )
Come sempre, chi denigra un linguaggio di programmazione per partito preso, lo fa per ignoranza e perche' non sa che un linguaggio e' solo uno strumento adatto ad un compito.
non lo denigro per partito preso e infatti non ho niente contro VB.NET che non conosco bene, ma essendo nell'ottica .NET non può che essere molto meglio di VB.
detto ciò credo che VB (non .NET) sia adatto solo allo scopo di disegnare interfaccie grafiche neanche molto eleganti senza imparare veramente a programmare. e per carità.. soddisfa i bisogni di qualcuno, ma in questo thread non va bene.
io non inizierei con VB solo perche' e' un linguaggio totalmente proprietario e ti lega ad una sola piattaforma hardware/software (PC + .NET). All'inizio e' facile pensare che la programmazione sia solo quella, perche' non si conoscono alternative.
per fortuna c'è mono http://www.mono-project.com/VisualBasic.NET_support
Da li' a imparare linguaggi a basso livello come il C e bestie come il C++ il passo e' davvero minimo, perche' le basi sono molto solide. Il percorso inverso dura invece una decina d'anni abbondanti.
quindi io non dovrei saper programmare a oggetti perchè è meno di 10 che sono passato agli oggetti... mi sembra che esageri un tantino. e soprattutto minimizzi il passaggio da java a C che secondo me è pieno di complicazioni.
con le ultime versioni includi anche VB6? (voglio sentirtelo dire :asd: )
Come sempre, chi denigra un linguaggio di programmazione per partito preso, lo fa per ignoranza e perche' non sa che un linguaggio e' solo uno strumento adatto ad un compito.
non lo denigro per partito preso e infatti non ho niente contro VB.NET che non conosco bene, ma essendo nell'ottica .NET non può che essere molto meglio di VB.
detto ciò credo che VB (non .NET) sia adatto solo allo scopo di disegnare interfaccie grafiche neanche molto eleganti senza imparare veramente a programmare. e per carità.. soddisfa i bisogni di qualcuno, ma in questo thread non va bene.
io non inizierei con VB solo perche' e' un linguaggio totalmente proprietario e ti lega ad una sola piattaforma hardware/software (PC + .NET). All'inizio e' facile pensare che la programmazione sia solo quella, perche' non si conoscono alternative.
per fortuna c'è mono http://www.mono-project.com/VisualBasic.NET_support
Da li' a imparare linguaggi a basso livello come il C e bestie come il C++ il passo e' davvero minimo, perche' le basi sono molto solide. Il percorso inverso dura invece una decina d'anni abbondanti.
quindi io non dovrei saper programmare a oggetti perchè è meno di 10 che sono passato agli oggetti... mi sembra che esageri un tantino. e soprattutto minimizzi il passaggio da java a C che secondo me è pieno di complicazioni.
k0nt3
14-05-2006, 11:53
Programmare senza if? Si' si puo', tratto da una storia vera, Diamonds, in Java.
Prima del refactoring:
public void selectNextItem()
{
int selectedActionIndex = selectedMenuItem.index();
if (selectedActionIndex == currentMenuLevelTop)
{
selectedActionIndex = currentMenuLevelBase;
}
else
{
++selectedActionIndex;
}
moveMenuSprite(selectedActionIndex);
selectedMenuItem = menuItems[selectedActionIndex];
}
Dopo il refactoring:
public void selectNextItem()
{
selectedMenuItem = selectedMenuItem.nextItem();
moveMenuSprite(selectedMenuItem.index());
}
PGI, questo refactoring e' stato fatto quasi interamente usando i comandi di refactoring di Eclipse, quelli implementati secondo i passi del libro di Fowler, e dimmi che non funziona :)
e il codice di selectedMenuItem.nextItem() non contiene un if?
Prima del refactoring:
public void selectNextItem()
{
int selectedActionIndex = selectedMenuItem.index();
if (selectedActionIndex == currentMenuLevelTop)
{
selectedActionIndex = currentMenuLevelBase;
}
else
{
++selectedActionIndex;
}
moveMenuSprite(selectedActionIndex);
selectedMenuItem = menuItems[selectedActionIndex];
}
Dopo il refactoring:
public void selectNextItem()
{
selectedMenuItem = selectedMenuItem.nextItem();
moveMenuSprite(selectedMenuItem.index());
}
PGI, questo refactoring e' stato fatto quasi interamente usando i comandi di refactoring di Eclipse, quelli implementati secondo i passi del libro di Fowler, e dimmi che non funziona :)
e il codice di selectedMenuItem.nextItem() non contiene un if?
fek
14-05-2006, 12:00
e il codice di selectedMenuItem.nextItem() non contiene un if?
public final MenuItem nextItem()
{
return nextItem;
}
E' per queste domande sciocche che e' evidente che tu non sappia programmare ne' ad oggetti ne' in altro modo :)
public final MenuItem nextItem()
{
return nextItem;
}
E' per queste domande sciocche che e' evidente che tu non sappia programmare ne' ad oggetti ne' in altro modo :)
PGI-Bis
14-05-2006, 12:04
PGI, questo refactoring e' stato fatto quasi interamente usando i comandi di refactoring di Eclipse, quelli implementati secondo i passi del libro di Fowler, e dimmi che non funziona :)
:D Di la verità, ti diverti a punzecchiarmi, eh? :D
Seriamente, sai che il mio "problema" non è osservare o meno il raggiungimento dello scopo ma capire perchè questo o quel refactoring consentano di raggiungerlo.
Nel codice che hai incollato io vedo (e credo che tutti vedano) due diverse definizioni dello stesso metodo delle quali una è più breve dell'altra.
Ora, la domanda è certamente: breve è meglio? Converrai che dipenda non solo dalla quantità di sintesi (1 parole in meno è meglio di 1 una parola in più) ma soprattutto dalla sua qualità.
Ad esempio, per restare in topic, tutti i linguaggi che adottano una convenzione numerica per significare gli stati VERO/FALSO hanno una potenzialità sintetica maggiore dal punto di vista quantitativo di quelli che dedichino agli stessi stati due letterali.
Probabilmente è una sintesi qualitativamente peggiore perchè il significato espresso in forma numerica è implicito o, ancora meglio/peggio, alcuni interi hanno due significati, che variano a seconda del contesto. Si tratterebbe quindi di elaborare, ad opera del lettore, due informazioni anzichè una (vero è vero ma 0 è vero solo se sia il risultato di un'espressione valutata da un'istruzione condizionale).
Io dico che la faccenda del refactoring è molto più complessa di quanto non la faccia il buon Fowler e che il fatto di trascurare questa complessità, specialmente in un libro di grande impatto sulla comunità degli sviluppatori, è almeno rischioso.
Rischioso nello stesso modo in cui è stato rischioso dire "gli oggetti comunicano scambiandosi un messaggio" al tempo della creazione della metafora dell'orientamento agli oggetti perchè è un motto che dice meno di quanto sottacia (la comunicazione è fatta di sette "pezzi" e lì ce ne sono al massimo tre, di cui due impliciti).
:D Di la verità, ti diverti a punzecchiarmi, eh? :D
Seriamente, sai che il mio "problema" non è osservare o meno il raggiungimento dello scopo ma capire perchè questo o quel refactoring consentano di raggiungerlo.
Nel codice che hai incollato io vedo (e credo che tutti vedano) due diverse definizioni dello stesso metodo delle quali una è più breve dell'altra.
Ora, la domanda è certamente: breve è meglio? Converrai che dipenda non solo dalla quantità di sintesi (1 parole in meno è meglio di 1 una parola in più) ma soprattutto dalla sua qualità.
Ad esempio, per restare in topic, tutti i linguaggi che adottano una convenzione numerica per significare gli stati VERO/FALSO hanno una potenzialità sintetica maggiore dal punto di vista quantitativo di quelli che dedichino agli stessi stati due letterali.
Probabilmente è una sintesi qualitativamente peggiore perchè il significato espresso in forma numerica è implicito o, ancora meglio/peggio, alcuni interi hanno due significati, che variano a seconda del contesto. Si tratterebbe quindi di elaborare, ad opera del lettore, due informazioni anzichè una (vero è vero ma 0 è vero solo se sia il risultato di un'espressione valutata da un'istruzione condizionale).
Io dico che la faccenda del refactoring è molto più complessa di quanto non la faccia il buon Fowler e che il fatto di trascurare questa complessità, specialmente in un libro di grande impatto sulla comunità degli sviluppatori, è almeno rischioso.
Rischioso nello stesso modo in cui è stato rischioso dire "gli oggetti comunicano scambiandosi un messaggio" al tempo della creazione della metafora dell'orientamento agli oggetti perchè è un motto che dice meno di quanto sottacia (la comunicazione è fatta di sette "pezzi" e lì ce ne sono al massimo tre, di cui due impliciti).
k0nt3
14-05-2006, 12:08
public final MenuItem nextItem()
{
return nextItem;
}
E' per queste domande sciocche che e' evidente che tu non sappia programmare ne' ad oggetti ne' in altro modo :)
ho fatto una domanda perchè non conosco il codice e non credo che questo significhi che non so programmare a oggetti :)
se non mi sbaglio l'if di prima serviva solo a ottenere un comportamento ciclico delle azioni.. quindi ci sono varie possibilità:
- il nuovo codice non ha più il comportamento ciclico
- è moveMenuSprite(); che gestisce il comportamento ciclico
- al posto dell'if si usa il resto della divisione per il valore massimo dell'indice (da qualche parte nel codice a noi ignoto)
mi sfuggono altre alternative al momento :p
{
return nextItem;
}
E' per queste domande sciocche che e' evidente che tu non sappia programmare ne' ad oggetti ne' in altro modo :)
ho fatto una domanda perchè non conosco il codice e non credo che questo significhi che non so programmare a oggetti :)
se non mi sbaglio l'if di prima serviva solo a ottenere un comportamento ciclico delle azioni.. quindi ci sono varie possibilità:
- il nuovo codice non ha più il comportamento ciclico
- è moveMenuSprite(); che gestisce il comportamento ciclico
- al posto dell'if si usa il resto della divisione per il valore massimo dell'indice (da qualche parte nel codice a noi ignoto)
mi sfuggono altre alternative al momento :p
fek
14-05-2006, 12:09
:D Di la verità, ti diverti a punzecchiarmi, eh? :D
Si', perche' tiri fuori sempre argomenti molto interessanti :)
Ora, la domanda è certamente: breve è meglio? Converrai che dipenda non solo dalla quantità di sintesi (1 parole in meno è meglio di 1 una parola in più) ma soprattutto dalla sua qualità.
Assolutamente. La riga di codice senza bug e' quella che non scrivi. Anche quelle eseguita piu' velocemente e' quella che non hai scritto. La semplicita', lo diceva un certo Einstein, e' l'obiettivo primario quando si risolve un problema. "Make it as simple as possible but not simpler", e' un concetto potentissimo. Ovviamente si parla di qualita' di cio' che hai scritto: comprimere un'intero programma in una sola riga di codice incomprensibile non lo rende piu' semplice, ma piu' complesso.
Se osservi attentamente il codice, la seconda versione non solo e' piu' breve, e' piu' leggibile, e' praticamente scritta in inglese: che devo fare per andare al prossimo menu item? Prendi quello successivo di quello corrente e quello diventa il nuovo elemento corrente. E' scritto li' nel codice. Prima era descritto in una decina di righe di codice, con un paio di if di mezzo: il comportamento era offuscato, non era possibile coglierlo con un semplice sguardo.
Dico sempre che si diventa ottimi programmatori nel momento in cui si riesce a scrivere cose semplici, non cose complesse; quelle sono capaci tutti. E ci vogliono anni, secondo me, per imparare a fare le cose semplici.
Si', perche' tiri fuori sempre argomenti molto interessanti :)
Ora, la domanda è certamente: breve è meglio? Converrai che dipenda non solo dalla quantità di sintesi (1 parole in meno è meglio di 1 una parola in più) ma soprattutto dalla sua qualità.
Assolutamente. La riga di codice senza bug e' quella che non scrivi. Anche quelle eseguita piu' velocemente e' quella che non hai scritto. La semplicita', lo diceva un certo Einstein, e' l'obiettivo primario quando si risolve un problema. "Make it as simple as possible but not simpler", e' un concetto potentissimo. Ovviamente si parla di qualita' di cio' che hai scritto: comprimere un'intero programma in una sola riga di codice incomprensibile non lo rende piu' semplice, ma piu' complesso.
Se osservi attentamente il codice, la seconda versione non solo e' piu' breve, e' piu' leggibile, e' praticamente scritta in inglese: che devo fare per andare al prossimo menu item? Prendi quello successivo di quello corrente e quello diventa il nuovo elemento corrente. E' scritto li' nel codice. Prima era descritto in una decina di righe di codice, con un paio di if di mezzo: il comportamento era offuscato, non era possibile coglierlo con un semplice sguardo.
Dico sempre che si diventa ottimi programmatori nel momento in cui si riesce a scrivere cose semplici, non cose complesse; quelle sono capaci tutti. E ci vogliono anni, secondo me, per imparare a fare le cose semplici.
fek
14-05-2006, 12:10
mi sfuggono altre alternative al momento :p
Non faccio alcuna fatica a crederti :)
Guarda mamma, senza if:
MenuItem.STORY_MODE.previousItem = MenuItem.QUIT;
MenuItem.STORY_MODE.nextItem = MenuItem.VERSUS_MODE;
Non faccio alcuna fatica a crederti :)
Guarda mamma, senza if:
MenuItem.STORY_MODE.previousItem = MenuItem.QUIT;
MenuItem.STORY_MODE.nextItem = MenuItem.VERSUS_MODE;
k0nt3
14-05-2006, 12:17
Dico sempre che si diventa ottimi programmatori nel momento in cui si riesce a scrivere cose semplici, non cose complesse; quelle sono capaci tutti. E ci vogliono anni, secondo me, per imparare a fare le cose semplici.
beh su questo credo che non si può non essere d'accordo. io personalmente (per quanto possa valere la mia opinione) penso che in generale "divide&conquer" sia la filosofia che da risultati migliori, cioè scomporre un problema complesso in problemi semplici e risolvere questi problemi semplici nella maniera migliore (dove il concetto di migliore è soggetto a interpretazione di volta in volta).
beh su questo credo che non si può non essere d'accordo. io personalmente (per quanto possa valere la mia opinione) penso che in generale "divide&conquer" sia la filosofia che da risultati migliori, cioè scomporre un problema complesso in problemi semplici e risolvere questi problemi semplici nella maniera migliore (dove il concetto di migliore è soggetto a interpretazione di volta in volta).
k0nt3
14-05-2006, 12:47
Non faccio alcuna fatica a crederti :)
Guarda mamma, senza if:
MenuItem.STORY_MODE.previousItem = MenuItem.QUIT;
MenuItem.STORY_MODE.nextItem = MenuItem.VERSUS_MODE;
grazie ora ho capito come funziona. anche se non mi sembra bellissimo per menu di certe dimensioni (non è il vostro caso) io ad esempio l'avrei fatto con un iteratore (ma sicuramente dirai che sbaglio :asd: )
ps. aggiungo che secondo me dovreste mettere il sorgente di diamond nel vostro sito (e se c'è già dovreste metterlo più visibile perchè io non l'ho visto)
Guarda mamma, senza if:
MenuItem.STORY_MODE.previousItem = MenuItem.QUIT;
MenuItem.STORY_MODE.nextItem = MenuItem.VERSUS_MODE;
grazie ora ho capito come funziona. anche se non mi sembra bellissimo per menu di certe dimensioni (non è il vostro caso) io ad esempio l'avrei fatto con un iteratore (ma sicuramente dirai che sbaglio :asd: )
ps. aggiungo che secondo me dovreste mettere il sorgente di diamond nel vostro sito (e se c'è già dovreste metterlo più visibile perchè io non l'ho visto)
PGI-Bis
14-05-2006, 13:29
e il codice di selectedMenuItem.nextItem() non contiene un if?
E' per queste domande sciocche che e' evidente che tu non sappia programmare ne' ad oggetti ne' in altro modo :)
Adessa vi faccio la paternale, fate finta che sia molto più vecchio di voi (cosa per'altro anche possibile :cry: )
Un buon modo per discutere senza venire alle mani, virtuali e non, è spiegarsi. Spiegarsi e lasciare che gli altri concordino o no.
Concretamente il codice di selectedMenuItem.nextItem() non contiene un if. Ma il punto è che è indifferente che lo contenga o meno, nel contesto della definizione di selectNextItem().
Al che bisognerebbe cercare di capire perchè (lo so, sono ossessivo :D) quel piccolo "if" sia così cattivo.
Non stupirà nessuno sapere che l'if non sia affatto cattivo in sè. Il problema è che sembra avvezzo, per la sua natura "ramificante", a generare strutture di controllo particolarmente "profonde", dove la profondità è misurata nel numero di controlli che devono essere verificati affinchè si giunga ad un'istruzione che non scaturisca in un altra "decisione".
A parità d'effetto, minore è il numero di decisioni da prendere per produrlo, migliore è la struttura di controllo.
Perchè? Be', intorno al 1950 un tal Miller pubblicò un saggio dal titolo "The Magical Number Seven, Plus Minus Two". Il Nostro teorizzava l'esistenza di un limite alla capacità della memoria di lavoro di trattenere informazioni sulla base delle quali prendere una decisione. Il limite era quantitativo e, sperimentalmente, Miller ricavò il valore medio (per essere umano medio) 7 con uno scarto di 2, da cui il titolo del suo lavoro.
Cosa capitava quando la quantità di informazioni (per noi, il numero di controlli) superava il limite di 7? Una cosa fenomenale: il cervello iniziava ad impacchettare le informazioni in super strutture, in modo tale che il numero totale di informazioni fosse sempre 7 più o meno 2.
A mo' di inciso, credo sia curioso notare come uno strumento quale la valutazione di complessità ciclomatica si attesti all'incirca sullo stesso numero (in verità 1-10) per ripartire il buono dal meno buono (cattivo e pessimo stanno un po' più in là).
Appariva chiaro, a questo punto, che dovesse esistere anche un'idoneità delle informazioni ad essere raggruppate affinchè il meccanismo del numero magico potesse realizzarsi.
E' qui che entra in gioco il:
selectedMenuItem.nextItem();
Quell'espressione è il raggruppamento di una struttura di controllo decisionale più profonda: è come aver detto al proprio cervello "guarda, rilassati che ghe pensi mi" :D.
Circa i principi del raggruppamento, cioè quali caratteri devano avere le informazioni per essere "ragguppabili" dal cervello e, quindi, quale tipo di raggruppamento esplicito possa effettivamente essere percepito come tale, direi, da quello che ho letto, potremmo dilungarci per millenni (è il segno che ancora la faccenda non è del tutto chiara).
Nel caso di specie il raggruppamento è dato da una espressione di regolarità logica. Ne esiste almeno un altro tipo, che è l'espressione di regolarità formale (c.d. percezione di pattern): è possibile suggerire al cervello un raggruppamento distribuendo la "forma" della struttura di controllo in modo tale che sia evidenziata una regolarità.
Nota curiosa (e giuro che poi non parlo per un po' :D) è che Miller avesse in parte torto. Meglio, aveva ragione ma non aveva pienamente compreso perchè. Circa 30 anni dopo altri tre tizi scoprirono lo straordinario effetto dell'addestramento al raggruppamento. Se le informazioni sono presentate come appartenenti ad un contesto familiare per l'osservatore e l'osservatore ha un addestramento minimo al raggrupamento (cioè è consapevole della possibilità di avvalersene) il suo cervello parte per la Milano Sanremo: dai 7 più o meno due, Ericcson, Chase e Fallon arrivarono a 80 e passa.
Questo ci dice che il primo elemento per giudicare la maggiore o minore semplicità della seconda definizione del metodo selectNextItem rispetto alla prima è la familiarità dell'osservatore con il contesto: ad esempio, sapendo a cosa serva selectNextItem la seconda versione sarà meno "eclatante" rispetto alla prima perchè la riduzione di quantità di informazioni ha un minore impatto.
Come dire che se dovessimo considerare solo la teoria dei raggruppamenti, la semplificazione del refactoring (raggruppare gli "if" e quindi più decisioni attraverso un'espressione di regolarità) sarebbe massimamente efficace a fronte di un lettore totalmente ignaro dello scopo, del linguaggio e del contesto di quell'insieme di informazioni.
E' per queste domande sciocche che e' evidente che tu non sappia programmare ne' ad oggetti ne' in altro modo :)
Adessa vi faccio la paternale, fate finta che sia molto più vecchio di voi (cosa per'altro anche possibile :cry: )
Un buon modo per discutere senza venire alle mani, virtuali e non, è spiegarsi. Spiegarsi e lasciare che gli altri concordino o no.
Concretamente il codice di selectedMenuItem.nextItem() non contiene un if. Ma il punto è che è indifferente che lo contenga o meno, nel contesto della definizione di selectNextItem().
Al che bisognerebbe cercare di capire perchè (lo so, sono ossessivo :D) quel piccolo "if" sia così cattivo.
Non stupirà nessuno sapere che l'if non sia affatto cattivo in sè. Il problema è che sembra avvezzo, per la sua natura "ramificante", a generare strutture di controllo particolarmente "profonde", dove la profondità è misurata nel numero di controlli che devono essere verificati affinchè si giunga ad un'istruzione che non scaturisca in un altra "decisione".
A parità d'effetto, minore è il numero di decisioni da prendere per produrlo, migliore è la struttura di controllo.
Perchè? Be', intorno al 1950 un tal Miller pubblicò un saggio dal titolo "The Magical Number Seven, Plus Minus Two". Il Nostro teorizzava l'esistenza di un limite alla capacità della memoria di lavoro di trattenere informazioni sulla base delle quali prendere una decisione. Il limite era quantitativo e, sperimentalmente, Miller ricavò il valore medio (per essere umano medio) 7 con uno scarto di 2, da cui il titolo del suo lavoro.
Cosa capitava quando la quantità di informazioni (per noi, il numero di controlli) superava il limite di 7? Una cosa fenomenale: il cervello iniziava ad impacchettare le informazioni in super strutture, in modo tale che il numero totale di informazioni fosse sempre 7 più o meno 2.
A mo' di inciso, credo sia curioso notare come uno strumento quale la valutazione di complessità ciclomatica si attesti all'incirca sullo stesso numero (in verità 1-10) per ripartire il buono dal meno buono (cattivo e pessimo stanno un po' più in là).
Appariva chiaro, a questo punto, che dovesse esistere anche un'idoneità delle informazioni ad essere raggruppate affinchè il meccanismo del numero magico potesse realizzarsi.
E' qui che entra in gioco il:
selectedMenuItem.nextItem();
Quell'espressione è il raggruppamento di una struttura di controllo decisionale più profonda: è come aver detto al proprio cervello "guarda, rilassati che ghe pensi mi" :D.
Circa i principi del raggruppamento, cioè quali caratteri devano avere le informazioni per essere "ragguppabili" dal cervello e, quindi, quale tipo di raggruppamento esplicito possa effettivamente essere percepito come tale, direi, da quello che ho letto, potremmo dilungarci per millenni (è il segno che ancora la faccenda non è del tutto chiara).
Nel caso di specie il raggruppamento è dato da una espressione di regolarità logica. Ne esiste almeno un altro tipo, che è l'espressione di regolarità formale (c.d. percezione di pattern): è possibile suggerire al cervello un raggruppamento distribuendo la "forma" della struttura di controllo in modo tale che sia evidenziata una regolarità.
Nota curiosa (e giuro che poi non parlo per un po' :D) è che Miller avesse in parte torto. Meglio, aveva ragione ma non aveva pienamente compreso perchè. Circa 30 anni dopo altri tre tizi scoprirono lo straordinario effetto dell'addestramento al raggruppamento. Se le informazioni sono presentate come appartenenti ad un contesto familiare per l'osservatore e l'osservatore ha un addestramento minimo al raggrupamento (cioè è consapevole della possibilità di avvalersene) il suo cervello parte per la Milano Sanremo: dai 7 più o meno due, Ericcson, Chase e Fallon arrivarono a 80 e passa.
Questo ci dice che il primo elemento per giudicare la maggiore o minore semplicità della seconda definizione del metodo selectNextItem rispetto alla prima è la familiarità dell'osservatore con il contesto: ad esempio, sapendo a cosa serva selectNextItem la seconda versione sarà meno "eclatante" rispetto alla prima perchè la riduzione di quantità di informazioni ha un minore impatto.
Come dire che se dovessimo considerare solo la teoria dei raggruppamenti, la semplificazione del refactoring (raggruppare gli "if" e quindi più decisioni attraverso un'espressione di regolarità) sarebbe massimamente efficace a fronte di un lettore totalmente ignaro dello scopo, del linguaggio e del contesto di quell'insieme di informazioni.
fek
14-05-2006, 13:42
Concretamente il codice di selectedMenuItem.nextItem() non contiene un if. Ma il punto è che è indifferente che lo contenga o meno, nel contesto della definizione di selectNextItem().
Al che bisognerebbe cercare di capire perchè (lo so, sono ossessivo :D) quel piccolo "if" sia così cattivo.
[snip]
Sai perche' senza if e' migliore? Perche' hai scritto 50 righe di testo, giustissime, quando pero' il concetto era solo: e' migliore perche' e' piu' semplice e chiaro. Bastavano tre parole: sintesi, semplicita' e chiarezza :)
Al che bisognerebbe cercare di capire perchè (lo so, sono ossessivo :D) quel piccolo "if" sia così cattivo.
[snip]
Sai perche' senza if e' migliore? Perche' hai scritto 50 righe di testo, giustissime, quando pero' il concetto era solo: e' migliore perche' e' piu' semplice e chiaro. Bastavano tre parole: sintesi, semplicita' e chiarezza :)
fek
14-05-2006, 13:44
ps. aggiungo che secondo me dovreste mettere il sorgente di diamond nel vostro sito (e se c'è già dovreste metterlo più visibile perchè io non l'ho visto)
http://fcarucci.homeip.net:8080/cruisecontrol/buildresults/diamonds
Sotto Build Artifacts trovi l'eseguibile e tutti i sorgenti dopo ogni commit.
http://fcarucci.homeip.net:8080/cruisecontrol/buildresults/diamonds
Sotto Build Artifacts trovi l'eseguibile e tutti i sorgenti dopo ogni commit.
PGI-Bis
14-05-2006, 13:50
Sai perche' senza if e' migliore? Perche' hai scritto 50 righe di testo, giustissime, quando pero' il concetto era solo: e' migliore perche' e' piu' semplice e chiaro. Bastavano tre parole: sintesi, semplicita' e chiarezza :)
Solo Fowler (tiè :D) può ritenere che basti dire "sintesi, semplicità e chiarezza" e voltar l'angolo. Perchè se io dico che
strigapumpamphlet()
è più sintetico semplice e chiaro di
leggiIlFile()
hai voglia a dire "non è vero" se non sai perchè o quantomeno se non cerchi di dare un possibile perchè.
Ma ho il sentore che ci stiamo avventurando in una discussione già tentata :D.
Solo Fowler (tiè :D) può ritenere che basti dire "sintesi, semplicità e chiarezza" e voltar l'angolo. Perchè se io dico che
strigapumpamphlet()
è più sintetico semplice e chiaro di
leggiIlFile()
hai voglia a dire "non è vero" se non sai perchè o quantomeno se non cerchi di dare un possibile perchè.
Ma ho il sentore che ci stiamo avventurando in una discussione già tentata :D.
k0nt3
14-05-2006, 13:50
http://fcarucci.homeip.net:8080/cruisecontrol/buildresults/diamonds
Sotto Build Artifacts trovi l'eseguibile e tutti i sorgenti dopo ogni commit.
ormai l'ho scaricato via SVN :fagiano:
Sotto Build Artifacts trovi l'eseguibile e tutti i sorgenti dopo ogni commit.
ormai l'ho scaricato via SVN :fagiano:
fek
14-05-2006, 13:57
Non stupirà nessuno sapere che l'if non sia affatto cattivo in sè. Il problema è che sembra avvezzo, per la sua natura "ramificante", a generare strutture di controllo particolarmente "profonde", dove la profondità è misurata nel numero di controlli che devono essere verificati affinchè si giunga ad un'istruzione che non scaturisca in un altra "decisione".
Ti do' una risposta piu' articolata perche' comunque il discorso e' interessante. Quell'if e' cattivo perche' aumenta la complessita' ciclomatica del codice. La complessita' ciclomatica, detto alla buona, misura il numero di test necessari a percorrere tutti i control flow di un metodo, per coprirlo interamente.
Per una formulazione piu' rigorosa, puoi partire da Wikipedia che contiene i link ai paper di McCabe:
http://en.wikipedia.org/wiki/Cyclomatic_complexity
Detto ancora piu' alla buona, la complessita' ciclomatica e' una misura della complessita del codice che si scrive. E' dimostrato empiricamente che il numero di difetti nel codice e' direttamente proporzionale alla sua complessita' ciclomatica. Intuitivamente, codice meno complesso e' piu' facile da mantenere e gestire.
Qui un paper che affronta questa proporzione diretta in maniera piu' rigorosa:
http://www.cs.umd.edu/users/mvz/pub/tian95.pdf
Un modo veloce per misurare la complessita' ciclomatica del codice e' contare il numero di if/for/switch/while. In sintesi: se tolgo quell'if diminuisco la complessita' ciclomatica della mia soluzione, quindi diminuisco la complessita' del codice, quindi diminuisco il numero di test necessari per testarlo e diminuisco la probabilita' di avere difetti nel codice che ho scritto. Lo scopo di molti dei Refactoring di Fowler e' diminuire la complessita' ciclomatica.
Ecco un altro motivo per il quale Java e' preferibile al C per un principiante: e' piu' facile scrivere codice con complessita' ciclomatica bassa.
Ti do' una risposta piu' articolata perche' comunque il discorso e' interessante. Quell'if e' cattivo perche' aumenta la complessita' ciclomatica del codice. La complessita' ciclomatica, detto alla buona, misura il numero di test necessari a percorrere tutti i control flow di un metodo, per coprirlo interamente.
Per una formulazione piu' rigorosa, puoi partire da Wikipedia che contiene i link ai paper di McCabe:
http://en.wikipedia.org/wiki/Cyclomatic_complexity
Detto ancora piu' alla buona, la complessita' ciclomatica e' una misura della complessita del codice che si scrive. E' dimostrato empiricamente che il numero di difetti nel codice e' direttamente proporzionale alla sua complessita' ciclomatica. Intuitivamente, codice meno complesso e' piu' facile da mantenere e gestire.
Qui un paper che affronta questa proporzione diretta in maniera piu' rigorosa:
http://www.cs.umd.edu/users/mvz/pub/tian95.pdf
Un modo veloce per misurare la complessita' ciclomatica del codice e' contare il numero di if/for/switch/while. In sintesi: se tolgo quell'if diminuisco la complessita' ciclomatica della mia soluzione, quindi diminuisco la complessita' del codice, quindi diminuisco il numero di test necessari per testarlo e diminuisco la probabilita' di avere difetti nel codice che ho scritto. Lo scopo di molti dei Refactoring di Fowler e' diminuire la complessita' ciclomatica.
Ecco un altro motivo per il quale Java e' preferibile al C per un principiante: e' piu' facile scrivere codice con complessita' ciclomatica bassa.
k0nt3
14-05-2006, 13:58
molto interessante questo discorso di 7-+2 e anche di 80 e passa :eek:
fek
14-05-2006, 14:00
Solo Fowler (tiè :D) può ritenere che basti dire "sintesi, semplicità e chiarezza" e voltar l'angolo. Perchè se io dico che
strigapumpamphlet()
è più sintetico semplice e chiaro di
leggiIlFile()
hai voglia a dire "non è vero" se non sai perchè o quantomeno se non cerchi di dare un possibile perchè.
Ma ho il sentore che ci stiamo avventurando in una discussione già tentata :D.
Risposta facile: strigapumpamphlet non descrive quello che il codice fa come leggiIlFile e non fa parte del dominio del problema :)
strigapumpamphlet()
è più sintetico semplice e chiaro di
leggiIlFile()
hai voglia a dire "non è vero" se non sai perchè o quantomeno se non cerchi di dare un possibile perchè.
Ma ho il sentore che ci stiamo avventurando in una discussione già tentata :D.
Risposta facile: strigapumpamphlet non descrive quello che il codice fa come leggiIlFile e non fa parte del dominio del problema :)
fek
14-05-2006, 14:04
E infine, gli if sono una brutta cosa nelle architetture in-order come il Cell o l'XCPU, prenche' introducono branch nel codice e la CPU non puo' riordinare le istruzioni da eseguire o fare esecuzione speculativa. I branch sono dei killer di performance su queste CPU. Si', sto lottando contro gli if al lavoro perche' l'XCPU e' un chiodo altrimenti :(
71104
14-05-2006, 15:40
Tu sei pazzo e non conti :D sono in tanti, mica solo io :D
di tanto in tanto all'università la gente mi viene a chiedere spiegazioni su come funzionano cose che i professori non spiegano (che ovviamente sono tante); particolarmente gettonate sono le interfacce grafiche (visto che all'università in C si fanno solo programmi CUI), ma non sono assolutamente l'unico argomento.
a certa gente piace capire molto in dettaglio il funzionamento delle cose, è naturale curiosità e in me è sempre stata particolarmente sviluppata; ricordo ancora quando a 14 anni col debugger entravo nella VCL di Delphi e analizzavo il codice passo-passo perché volevo ASSOLUTAMENTE capire come faceva un programma Delphi a disegnare la GUI... :cry:
bei tempi :')
con questo sistema scoprii le API Win32 :cool:
Fai unit testing in C ;) domanda non provocatoria: quali sarebbero le difficoltà?
Su Design And Evolution of C++ di Stroustrup c'e' una descrizione di una possibile estensione del C++ che aggiunga il concetto di include al linguaggio e non via direttiva di preprocessing. E' molto interessante. Per altro, e' un libro che DEVI leggere. ok, lo aggiungo alla wishlist :p
di tanto in tanto all'università la gente mi viene a chiedere spiegazioni su come funzionano cose che i professori non spiegano (che ovviamente sono tante); particolarmente gettonate sono le interfacce grafiche (visto che all'università in C si fanno solo programmi CUI), ma non sono assolutamente l'unico argomento.
a certa gente piace capire molto in dettaglio il funzionamento delle cose, è naturale curiosità e in me è sempre stata particolarmente sviluppata; ricordo ancora quando a 14 anni col debugger entravo nella VCL di Delphi e analizzavo il codice passo-passo perché volevo ASSOLUTAMENTE capire come faceva un programma Delphi a disegnare la GUI... :cry:
bei tempi :')
con questo sistema scoprii le API Win32 :cool:
Fai unit testing in C ;) domanda non provocatoria: quali sarebbero le difficoltà?
Su Design And Evolution of C++ di Stroustrup c'e' una descrizione di una possibile estensione del C++ che aggiunga il concetto di include al linguaggio e non via direttiva di preprocessing. E' molto interessante. Per altro, e' un libro che DEVI leggere. ok, lo aggiungo alla wishlist :p
fek
14-05-2006, 16:20
domanda non provocatoria: quali sarebbero le difficoltà?
Non e' banale ad esempio scrivere un Mock... quando il linguaggio non ha il concetto di classe o interfaccia :D
Non e' banale ad esempio scrivere un Mock... quando il linguaggio non ha il concetto di classe o interfaccia :D
marco.r
14-05-2006, 19:10
Sulla questione sono fondamentalmente d'accordo con fek (a parte la scelta del linguaggio, visto che preferisco Python, ma de gustibus... ).
Imparare a programmare è come imparare a girare una grossa città. Si può cominciare dalle basi, girandola a piedi, e nel corso degli anni imparare a menadito tutti i vicoli, i sottoscala e le gradinate per arrivare prima a destinazione. Poi pero' quando finalmente cominci a girarla in macchina devi imparare che nonostante lo scopo sia lo stesso, e il metodo fondamentalmente uguale, la strada da percorrere per arrivare all'altro capo della città non sono le viette del centro ma la tangenziale :p .
Imparare a programmare è come imparare a girare una grossa città. Si può cominciare dalle basi, girandola a piedi, e nel corso degli anni imparare a menadito tutti i vicoli, i sottoscala e le gradinate per arrivare prima a destinazione. Poi pero' quando finalmente cominci a girarla in macchina devi imparare che nonostante lo scopo sia lo stesso, e il metodo fondamentalmente uguale, la strada da percorrere per arrivare all'altro capo della città non sono le viette del centro ma la tangenziale :p .
k0nt3
14-05-2006, 22:18
Imparare a programmare è come imparare a girare una grossa città. Si può cominciare dalle basi, girandola a piedi, e nel corso degli anni imparare a menadito tutti i vicoli, i sottoscala e le gradinate per arrivare prima a destinazione. Poi pero' quando finalmente cominci a girarla in macchina devi imparare che nonostante lo scopo sia lo stesso, e il metodo fondamentalmente uguale, la strada da percorrere per arrivare all'altro capo della città non sono le viette del centro ma la tangenziale :p .
infatti la macchina te la danno a 18 anni per cui non puoi iniziare in macchina :Prrr: :D
infatti la macchina te la danno a 18 anni per cui non puoi iniziare in macchina :Prrr: :D
wingman87
14-05-2006, 22:47
fidati, il C++ lo impareresti molto prima se non avessi studiato Visual Basic. fek non può che essere d'accordo con me, almeno se ti riferisci alla versione 6 di VB.
Sì, mi riferisco al 6, comunque anche se non stessi studiando VB andrei alla stessa velocità xk sto semplicemente seguendo il corso di scuola, tempo di lavorare da solo a casa non ne ho molto purtroppo, quindi in fondo mi va bene che stia imparando il VB6, in fondo è sempre un linguaggio in +..
Riguardo al filmato del browser è molto carino, ma pensavo, avendo a disposizione gli stessi oggetti non si potrebbe fare la stessa cosa anche in VB?
Sì, mi riferisco al 6, comunque anche se non stessi studiando VB andrei alla stessa velocità xk sto semplicemente seguendo il corso di scuola, tempo di lavorare da solo a casa non ne ho molto purtroppo, quindi in fondo mi va bene che stia imparando il VB6, in fondo è sempre un linguaggio in +..
Riguardo al filmato del browser è molto carino, ma pensavo, avendo a disposizione gli stessi oggetti non si potrebbe fare la stessa cosa anche in VB?
71104
15-05-2006, 00:04
Non e' banale ad esempio scrivere un Mock... quando il linguaggio non ha il concetto di classe o interfaccia :D se facciamo finta che una "translation unit" sia l'analogo di una classe, per crearne un mock basta creare il file contenente le stesse funzioni in versione mock, poi per compilare usando il mock al posto del file vero basta lavorare di path nei makefiles ;)
esempio: nei makefiles puoi definire una macro $(MOCK_PATH) che in configurazione "Run" (per così dire) sia nulla, mentre in configurazione "Test" sia uguale a "Mock/" se per esempio tutti i mock li hai messi in una directory di nome "Mock"; se poi nei makefiles usi questa macro nei path, le translation unit cambiano a seconda che compili in "configurazione Run" o "Test". ti assicuro che si perde molto meno tempo a farlo che a dirlo, sebbene io rimanga d'accordo che con istanze di classi sia tutto più semplice; volevo solo dire che non è impossibile :)
EDIT: in alternativa, in caso nel testing di certi programmi si debbano usare le versioni mock di alcune translation units in certi test e le versioni originali in altri test, la cosa si complica un po' ma anche qui nulla è impossibile e si fa prima a farlo che a spiegarlo.
sempre agendo nei makefiles, si potrebbe richiedere al compilatore la generazione di tutti i file oggetto, sia originali che mock, e poi si potrebbe effettuare un linking diverso a seconda del test; naturalmente nella configurazione "Run" i mock non sarebbero mai linkati.
il tutto viene molto più efficiente di quello che sembra visto che il make richiama solo le regole le cui dipendenze si risolvono in files con data di modifica anteriore a quella in cui si risolve la regola stessa.
esempio: nei makefiles puoi definire una macro $(MOCK_PATH) che in configurazione "Run" (per così dire) sia nulla, mentre in configurazione "Test" sia uguale a "Mock/" se per esempio tutti i mock li hai messi in una directory di nome "Mock"; se poi nei makefiles usi questa macro nei path, le translation unit cambiano a seconda che compili in "configurazione Run" o "Test". ti assicuro che si perde molto meno tempo a farlo che a dirlo, sebbene io rimanga d'accordo che con istanze di classi sia tutto più semplice; volevo solo dire che non è impossibile :)
EDIT: in alternativa, in caso nel testing di certi programmi si debbano usare le versioni mock di alcune translation units in certi test e le versioni originali in altri test, la cosa si complica un po' ma anche qui nulla è impossibile e si fa prima a farlo che a spiegarlo.
sempre agendo nei makefiles, si potrebbe richiedere al compilatore la generazione di tutti i file oggetto, sia originali che mock, e poi si potrebbe effettuare un linking diverso a seconda del test; naturalmente nella configurazione "Run" i mock non sarebbero mai linkati.
il tutto viene molto più efficiente di quello che sembra visto che il make richiama solo le regole le cui dipendenze si risolvono in files con data di modifica anteriore a quella in cui si risolve la regola stessa.
cdimauro
15-05-2006, 08:23
ma io mica ho nulla contro BASIC, tant'è vero che QBasic è stato il secondo linguaggio che ho imparato :p
Per me è stato il primo, seguito poco dopo l'assembly (6502 :D).
il mio è odio razziale verso VISUAL Basic... e non penso ci voglia molto a capire perché :D
Sinceramente ho difficoltà a capirlo, visto che per parecchio tempo ho sviluppato applicazioni (commercializzate) in VisualBasic. L'ho abbandonato alla versione 6 (sono passato del tutto a Delphi :D), ma ho continuato a seguirne l'evoluzione.
Per me è stato il primo, seguito poco dopo l'assembly (6502 :D).
il mio è odio razziale verso VISUAL Basic... e non penso ci voglia molto a capire perché :D
Sinceramente ho difficoltà a capirlo, visto che per parecchio tempo ho sviluppato applicazioni (commercializzate) in VisualBasic. L'ho abbandonato alla versione 6 (sono passato del tutto a Delphi :D), ma ho continuato a seguirne l'evoluzione.
cdimauro
15-05-2006, 08:35
mi state facendo confondere ancora di più!
Quel che avevo da dire l'ho già detto. Ti riporto l'introduzione del primo link che t'ho segnalato (evidenziandone alcune parti), che non è strettamente tecnica, per farti capire il perché della scelta di Python (o comunque di altri linguaggi di alto livello) nel tuo caso sarebbe l'ideale:
Introduzione
Di David Beazley
In qualità di educatore, ricercatore e autore di libri, sono lieto di assistere alla conclusione della stesura di questo testo. Python è un linguaggio di programmazione divertente e semplice da usare, la cui popolarità è andata via via crescendo nel corso degli ultimi anni. Python è stato sviluppato più di dieci anni fa da Guido van Rossum che ne ha derivato semplicità di sintassi e facilità d'uso in gran parte da ABC, un linguaggio dedicato all'insegnamento sviluppato negli anni '80. Oltre che per questo specifico contesto, Python è stato creato per risolvere problemi reali, dimostrando di possedere un'ampia varietà di caratteristiche tipiche di linguaggi di programmazione quali C++, Java, Modula-3 e Scheme. Questo giustifica una delle sue più rimarchevoli caratteristiche: l'ampio consenso nell'ambito degli sviluppatori professionisti di software, in ambiente scientifico e di ricerca, tra i creativi e gli educatori.
Nonostante l'interesse riscosso da Python in ambienti così disparati, potresti ancora chiederti "Perché Python?" o "Perché insegnare la programmazione con Python?". Rispondere a queste domande non è cosa semplice, specialmente quando l'interesse generale è rivolto ad alternative più masochistiche quali C++ e Java. Penso comunque che la risposta più diretta sia che la programmazione in Python è semplice, divertente e più produttiva.
Quando tengo corsi di informatica, il mio intento è quello di spiegare concetti importanti interessando ed intrattenendo nel contempo gli studenti. Sfortunatamente nei corsi introduttivi c'è la tendenza a focalizzare troppo l'attenzione sull'astrazione matematica e nel caso degli studenti a sentirsi frustrati a causa di fastidiosi problemi legati a dettagli di basso livello della sintassi, della compilazione e dall'imposizione di regole poco intuitive. Sebbene questa astrazione e questo formalismo siano importanti per il progettista di software professionale e per gli studenti che hanno intenzione di proseguire i loro studi di informatica, questo approccio in un corso introduttivo porta solitamente a rendere l'informatica noiosa. Quando tengo un corso non voglio avere davanti una classe di studenti annoiati: preferirei piuttosto vederli impegnati a risolvere problemi interessanti esplorando idee diverse, approcci non convenzionali, infrangendo le regole e imparando dai loro stessi errori.
Inoltre non voglio sprecare mezzo semestre a risolvere oscuri problemi di sintassi, cercando di capire messaggi del compilatore generalmente incomprensibili o di far fronte al centinaio di modi in cui un programma può generare un "general protection fault".
Una delle ragioni per cui mi piace Python è che esso permette un ottimo equilibrio tra l'aspetto pratico e quello concettuale. Dato che Python è interpretato, gli studenti possono fare qualcosa quasi subito senza perdersi in problemi di compilazione e link. Inoltre Python è fornito di un'ampia libreria di moduli che possono essere usati in ogni sorta di contesto, dalla programmazione web alla grafica. Questo aspetto pratico è un ottimo sistema per impegnare gli studenti e permette loro di portare a termine progetti non banali. Python può anche servire come eccellente punto di partenza per introdurre importanti concetti di informatica: dato che supporta procedure e classi, possono essere gradualmente introdotti argomenti quali l'astrazione procedurale, le strutture di dati e la programmazione ad oggetti, tutti solitamente relegati a corsi avanzati di Java o C++. Python prende a prestito un certo numero di caratteristiche da linguaggi di programmazione funzionali e può essere quindi usato per introdurre concetti che sarebbero normalmente trattati in dettaglio in corsi di Scheme o di Lisp.
Leggendo la prefazione di Jeffrey sono rimasto colpito da un suo commento: Python gli ha permesso di ottenere "un livello generale di successo più elevato ed un minore livello di frustrazione", e gli è stato possibile muoversi "con maggiore velocità e con risultati migliori". Questi commenti si riferiscono al suo corso introduttivo: io uso Python per queste stesse ragioni in corsi di informatica avanzata all'Università di Chicago. In questi corsi sono costantemente messo di fronte alla difficoltà di dover coprire molti argomenti complessi in un periodo di appena nove settimane. Sebbene sia certamente possibile per me infliggere un bel po' di sofferenza usando un linguaggio come il C++, ho spesso trovato che questo approccio è controproducente, specialmente nel caso di corsi riguardanti la semplice programmazione. Ritengo che usare Python mi permetta di focalizzare meglio l'attenzione sull'argomento reale della lezione, consentendo nel contempo agli studenti di completare progetti concreti.
Sebbene Python sia un linguaggio ancora giovane ed in continua evoluzione, credo che esso abbia un futuro nel campo dell'insegnamento. Questo libro è un passo importante in questa direzione.
David Beazley, autore di Python Essential Reference
Università di Chicago
T'invito anche a leggere la prefazione dell'autore del libro, anch'essa non strettamente tecnica, in cui spiega com'è arrivato a usare Python, perché lo usa nel corso e perché lo consiglia.
Quel che avevo da dire l'ho già detto. Ti riporto l'introduzione del primo link che t'ho segnalato (evidenziandone alcune parti), che non è strettamente tecnica, per farti capire il perché della scelta di Python (o comunque di altri linguaggi di alto livello) nel tuo caso sarebbe l'ideale:
Introduzione
Di David Beazley
In qualità di educatore, ricercatore e autore di libri, sono lieto di assistere alla conclusione della stesura di questo testo. Python è un linguaggio di programmazione divertente e semplice da usare, la cui popolarità è andata via via crescendo nel corso degli ultimi anni. Python è stato sviluppato più di dieci anni fa da Guido van Rossum che ne ha derivato semplicità di sintassi e facilità d'uso in gran parte da ABC, un linguaggio dedicato all'insegnamento sviluppato negli anni '80. Oltre che per questo specifico contesto, Python è stato creato per risolvere problemi reali, dimostrando di possedere un'ampia varietà di caratteristiche tipiche di linguaggi di programmazione quali C++, Java, Modula-3 e Scheme. Questo giustifica una delle sue più rimarchevoli caratteristiche: l'ampio consenso nell'ambito degli sviluppatori professionisti di software, in ambiente scientifico e di ricerca, tra i creativi e gli educatori.
Nonostante l'interesse riscosso da Python in ambienti così disparati, potresti ancora chiederti "Perché Python?" o "Perché insegnare la programmazione con Python?". Rispondere a queste domande non è cosa semplice, specialmente quando l'interesse generale è rivolto ad alternative più masochistiche quali C++ e Java. Penso comunque che la risposta più diretta sia che la programmazione in Python è semplice, divertente e più produttiva.
Quando tengo corsi di informatica, il mio intento è quello di spiegare concetti importanti interessando ed intrattenendo nel contempo gli studenti. Sfortunatamente nei corsi introduttivi c'è la tendenza a focalizzare troppo l'attenzione sull'astrazione matematica e nel caso degli studenti a sentirsi frustrati a causa di fastidiosi problemi legati a dettagli di basso livello della sintassi, della compilazione e dall'imposizione di regole poco intuitive. Sebbene questa astrazione e questo formalismo siano importanti per il progettista di software professionale e per gli studenti che hanno intenzione di proseguire i loro studi di informatica, questo approccio in un corso introduttivo porta solitamente a rendere l'informatica noiosa. Quando tengo un corso non voglio avere davanti una classe di studenti annoiati: preferirei piuttosto vederli impegnati a risolvere problemi interessanti esplorando idee diverse, approcci non convenzionali, infrangendo le regole e imparando dai loro stessi errori.
Inoltre non voglio sprecare mezzo semestre a risolvere oscuri problemi di sintassi, cercando di capire messaggi del compilatore generalmente incomprensibili o di far fronte al centinaio di modi in cui un programma può generare un "general protection fault".
Una delle ragioni per cui mi piace Python è che esso permette un ottimo equilibrio tra l'aspetto pratico e quello concettuale. Dato che Python è interpretato, gli studenti possono fare qualcosa quasi subito senza perdersi in problemi di compilazione e link. Inoltre Python è fornito di un'ampia libreria di moduli che possono essere usati in ogni sorta di contesto, dalla programmazione web alla grafica. Questo aspetto pratico è un ottimo sistema per impegnare gli studenti e permette loro di portare a termine progetti non banali. Python può anche servire come eccellente punto di partenza per introdurre importanti concetti di informatica: dato che supporta procedure e classi, possono essere gradualmente introdotti argomenti quali l'astrazione procedurale, le strutture di dati e la programmazione ad oggetti, tutti solitamente relegati a corsi avanzati di Java o C++. Python prende a prestito un certo numero di caratteristiche da linguaggi di programmazione funzionali e può essere quindi usato per introdurre concetti che sarebbero normalmente trattati in dettaglio in corsi di Scheme o di Lisp.
Leggendo la prefazione di Jeffrey sono rimasto colpito da un suo commento: Python gli ha permesso di ottenere "un livello generale di successo più elevato ed un minore livello di frustrazione", e gli è stato possibile muoversi "con maggiore velocità e con risultati migliori". Questi commenti si riferiscono al suo corso introduttivo: io uso Python per queste stesse ragioni in corsi di informatica avanzata all'Università di Chicago. In questi corsi sono costantemente messo di fronte alla difficoltà di dover coprire molti argomenti complessi in un periodo di appena nove settimane. Sebbene sia certamente possibile per me infliggere un bel po' di sofferenza usando un linguaggio come il C++, ho spesso trovato che questo approccio è controproducente, specialmente nel caso di corsi riguardanti la semplice programmazione. Ritengo che usare Python mi permetta di focalizzare meglio l'attenzione sull'argomento reale della lezione, consentendo nel contempo agli studenti di completare progetti concreti.
Sebbene Python sia un linguaggio ancora giovane ed in continua evoluzione, credo che esso abbia un futuro nel campo dell'insegnamento. Questo libro è un passo importante in questa direzione.
David Beazley, autore di Python Essential Reference
Università di Chicago
T'invito anche a leggere la prefazione dell'autore del libro, anch'essa non strettamente tecnica, in cui spiega com'è arrivato a usare Python, perché lo usa nel corso e perché lo consiglia.
cdimauro
15-05-2006, 08:53
ciò che ha da invidiare cambia da versione a versione; la 6 ad esempio ha da invidiare una OOP decente.
La 6 è una versione vecchia di 10 anni, Alberto! :p
secondo me il BASIC è un linguaggio del passato forzato nel presente da quell'obbrobbrio di VB; può darsi che le versioni più recenti .NET siano migliori della 6, non saprei... ma ad ogni modo secondo me il BASIC nel 2006 può avere soltanto scopi didattici, niente più; le interfacce grafiche nel 2006 richiedono la OOP, e BASIC non è assolutamente nato per essere OO, quindi non è assolutamente in linea con essa.
Sei rimasto LEGGERMENTE indietro. :p Ripeto: VB(nella sua ultima incarnazione, .NET) non ha nulla da invidiare ad altri linguaggi blasonati. ;)
Dai un'occhiata a questo link: http://msdn.microsoft.com/vbasic/default.aspx?pull=/library/en-us/dnvs05/html/vb2005_overview.asp da cui ti estraggo un esempietto:
Public Class TypedVector(Of T)
' Create a one-dimensional array of
' the specified type.
Private arrayValue() As T
Public Sub New(ByVal Size As Integer)
ReDim arrayValue(Size - 1)
End Sub
Default Public Property Item(ByVal Index As Integer) As T
Get
Return arrayValue(Index)
End Get
Set(ByVal Value As T)
arrayValue(Index) = Value
End Set
End Property
End Class
...
Dim myVector As New TypedVector(Of Integer)(4)
myVector(0) = 73
myVector(1) = 27
Un esempio d'uso dei generics. ;)
il C99 non più! ;)
è stato introdotto const, a quanto ne so. se ne sentiva veramente il bisogno, anche le estensioni del compilatore Microsoft (che di base è C89) includono const.
Complimenti: ci sono voluti 35 anni per introdurre questo concetto. :asd:
Il problema, Alberto, è che il C è un linguaggio lasciato nel dimenticatoio, la cui evoluzione è stata soffocata dal C++.
Tutto ciò ha portato all'uso e alla richiesta di usare quasi sempre la versione ANSI, ma non la 99.
hum, su questo posso anche essere d'accordo: a causa dell'inclusione manuale il programmatore è sempre costretto a proteggere gli headers dall'inclusione multipla; ma bisognerebbe anche vedere se sia possibile realizzare in C/C++ un sistema di packages (stile Java) che non tolga potenza e controllo al programmatore: più automatizzi meno dai la possibilità di controllare.
E' una cosa che hanno fatto da decenni altri linguaggi, senza per questo intaccare la loro efficienza / potenzialità. Tutt'altro. ;)
Un modulo/unit/package diciamo che è un contenitore di simboli, riferimenti e codice: è qualcosa di più di un semplice file oggetto, insomma, ma NIENTE DI MENO.
A te cambia qualcosa se dentro al .o, oltre ai simboli e al codice, infilano altro? Nulla. In fase di compilazione dell'eseguibile, verranno del tutto rimosse.
E' una grossa mancanza che i produttori di compilatori hanno cercato di sopperire con gli header precompilati, ma non è certo la stessa cosa.
su certe cose il controllo non serve, ma in C il controllo di ogni minimo aspetto della situazione serve sempre perché il C è il linguaggio usato ad esempio per programmare i kernel dei sistemi operativi e altri componenti di sistema.
Il C non è condizione necessaria per sviluppare questo tipo di applicazioni. ;)
http://www.petros-project.com/pages/info.htm
"PETROS® has been designed and built from first principles using a high level language based on Object Pascal. The emphasis at all stages of the PETROS® project has been to apply the KISS principle (Keep It Small and Simple)
Some of the primary features of PETROS® include:
A micro kernel of about 190K, allowing much more memory for applications.
A full working TCP system can be achieved in approximately 300 K
It is fast loading, fast and easy to run.
It runs on 486 and above level of processor.
It has a minimum memory requirement of 2 MB.
Standard peripherals are built in.
It is fully multitasking.
It has loadable driver modules
It has virtual paged memory
It will allow continued use of superceded machine configurations.
It contains industry standard disk structures and executable formats."
;)
certe volte è ancora necessario usare questi linguaggi ormai relativamente vecchi. e potremo evolverci quanto ci pare, potranno arrivare interi sistemi operativi in Java, ma il layer scritto in C e assembly ci sarà sempre, o comunque ancora per molto; trovo molto improbabile che il futuro abbia in serbo macchine con JVM firmware, almeno non quello immediato.
Vedi sopra. Il fatto che vengano COMUNEMENTE usati C e assembly (quest'ultimo è strettamente necessario soltanto per alcuni dettagli) NON vuol dire che siano gli UNICI linguaggi che permettono di realizzare questo tipo di applicazioni.
infatti, nonostante questo Visual Basic sia quello che è, è stato un indubbio successo per Microsoft. la solita storia.
io non son proprio il tipo sai :)
tutto quello che ho appena scritto lo affermo perché l'ho provato sulla mia pelle (ebbene si: ho provato a programmare in Visual Basic qualche volta).
Allora scaricati VB.NET 2005, che è COMPLETAMENTE GRATUITO per uso personale, e dai un'occhiata a come si è evoluto il linguaggio (e l'IDE). ;)
La 6 è una versione vecchia di 10 anni, Alberto! :p
secondo me il BASIC è un linguaggio del passato forzato nel presente da quell'obbrobbrio di VB; può darsi che le versioni più recenti .NET siano migliori della 6, non saprei... ma ad ogni modo secondo me il BASIC nel 2006 può avere soltanto scopi didattici, niente più; le interfacce grafiche nel 2006 richiedono la OOP, e BASIC non è assolutamente nato per essere OO, quindi non è assolutamente in linea con essa.
Sei rimasto LEGGERMENTE indietro. :p Ripeto: VB(nella sua ultima incarnazione, .NET) non ha nulla da invidiare ad altri linguaggi blasonati. ;)
Dai un'occhiata a questo link: http://msdn.microsoft.com/vbasic/default.aspx?pull=/library/en-us/dnvs05/html/vb2005_overview.asp da cui ti estraggo un esempietto:
Public Class TypedVector(Of T)
' Create a one-dimensional array of
' the specified type.
Private arrayValue() As T
Public Sub New(ByVal Size As Integer)
ReDim arrayValue(Size - 1)
End Sub
Default Public Property Item(ByVal Index As Integer) As T
Get
Return arrayValue(Index)
End Get
Set(ByVal Value As T)
arrayValue(Index) = Value
End Set
End Property
End Class
...
Dim myVector As New TypedVector(Of Integer)(4)
myVector(0) = 73
myVector(1) = 27
Un esempio d'uso dei generics. ;)
il C99 non più! ;)
è stato introdotto const, a quanto ne so. se ne sentiva veramente il bisogno, anche le estensioni del compilatore Microsoft (che di base è C89) includono const.
Complimenti: ci sono voluti 35 anni per introdurre questo concetto. :asd:
Il problema, Alberto, è che il C è un linguaggio lasciato nel dimenticatoio, la cui evoluzione è stata soffocata dal C++.
Tutto ciò ha portato all'uso e alla richiesta di usare quasi sempre la versione ANSI, ma non la 99.
hum, su questo posso anche essere d'accordo: a causa dell'inclusione manuale il programmatore è sempre costretto a proteggere gli headers dall'inclusione multipla; ma bisognerebbe anche vedere se sia possibile realizzare in C/C++ un sistema di packages (stile Java) che non tolga potenza e controllo al programmatore: più automatizzi meno dai la possibilità di controllare.
E' una cosa che hanno fatto da decenni altri linguaggi, senza per questo intaccare la loro efficienza / potenzialità. Tutt'altro. ;)
Un modulo/unit/package diciamo che è un contenitore di simboli, riferimenti e codice: è qualcosa di più di un semplice file oggetto, insomma, ma NIENTE DI MENO.
A te cambia qualcosa se dentro al .o, oltre ai simboli e al codice, infilano altro? Nulla. In fase di compilazione dell'eseguibile, verranno del tutto rimosse.
E' una grossa mancanza che i produttori di compilatori hanno cercato di sopperire con gli header precompilati, ma non è certo la stessa cosa.
su certe cose il controllo non serve, ma in C il controllo di ogni minimo aspetto della situazione serve sempre perché il C è il linguaggio usato ad esempio per programmare i kernel dei sistemi operativi e altri componenti di sistema.
Il C non è condizione necessaria per sviluppare questo tipo di applicazioni. ;)
http://www.petros-project.com/pages/info.htm
"PETROS® has been designed and built from first principles using a high level language based on Object Pascal. The emphasis at all stages of the PETROS® project has been to apply the KISS principle (Keep It Small and Simple)
Some of the primary features of PETROS® include:
A micro kernel of about 190K, allowing much more memory for applications.
A full working TCP system can be achieved in approximately 300 K
It is fast loading, fast and easy to run.
It runs on 486 and above level of processor.
It has a minimum memory requirement of 2 MB.
Standard peripherals are built in.
It is fully multitasking.
It has loadable driver modules
It has virtual paged memory
It will allow continued use of superceded machine configurations.
It contains industry standard disk structures and executable formats."
;)
certe volte è ancora necessario usare questi linguaggi ormai relativamente vecchi. e potremo evolverci quanto ci pare, potranno arrivare interi sistemi operativi in Java, ma il layer scritto in C e assembly ci sarà sempre, o comunque ancora per molto; trovo molto improbabile che il futuro abbia in serbo macchine con JVM firmware, almeno non quello immediato.
Vedi sopra. Il fatto che vengano COMUNEMENTE usati C e assembly (quest'ultimo è strettamente necessario soltanto per alcuni dettagli) NON vuol dire che siano gli UNICI linguaggi che permettono di realizzare questo tipo di applicazioni.
infatti, nonostante questo Visual Basic sia quello che è, è stato un indubbio successo per Microsoft. la solita storia.
io non son proprio il tipo sai :)
tutto quello che ho appena scritto lo affermo perché l'ho provato sulla mia pelle (ebbene si: ho provato a programmare in Visual Basic qualche volta).
Allora scaricati VB.NET 2005, che è COMPLETAMENTE GRATUITO per uso personale, e dai un'occhiata a come si è evoluto il linguaggio (e l'IDE). ;)
cdimauro
15-05-2006, 08:56
fidati, il C++ lo impareresti molto prima se non avessi studiato Visual Basic. fek non può che essere d'accordo con me, almeno se ti riferisci alla versione 6 di VB.
e arifidati, che c'è modo anche in C++ di ottenere risultati velocemente; altrimenti se proprio è di primaria importanza che l'informatica ti gratifichi il prima possibile, spostati su un linguaggio più semplice come Java o C#, ma VB è da rimuovere.
Sono assolutamente in disaccordo, per quanto scritto sopra: è come se, parlando del Turbo Pascal, dovessi restare fermo alla versione 3.0, ignorando gli ENORMI miglioramenti apportati al linguaggio e all'IDE in questi ultimi vent'anni.
e arifidati, che c'è modo anche in C++ di ottenere risultati velocemente; altrimenti se proprio è di primaria importanza che l'informatica ti gratifichi il prima possibile, spostati su un linguaggio più semplice come Java o C#, ma VB è da rimuovere.
Sono assolutamente in disaccordo, per quanto scritto sopra: è come se, parlando del Turbo Pascal, dovessi restare fermo alla versione 3.0, ignorando gli ENORMI miglioramenti apportati al linguaggio e all'IDE in questi ultimi vent'anni.
cdimauro
15-05-2006, 08:59
beh su questo credo che non si può non essere d'accordo. io personalmente (per quanto possa valere la mia opinione) penso che in generale "divide&conquer" sia la filosofia che da risultati migliori, cioè scomporre un problema complesso in problemi semplici e risolvere questi problemi semplici nella maniera migliore (dove il concetto di migliore è soggetto a interpretazione di volta in volta).
Quella che hai dato è la definizione di approccio top down.
Divide & conqueror si applica in altri contesti.
Quella che hai dato è la definizione di approccio top down.
Divide & conqueror si applica in altri contesti.
cdimauro
15-05-2006, 09:10
E infine, gli if sono una brutta cosa nelle architetture in-order come il Cell o l'XCPU, prenche' introducono branch nel codice e la CPU non puo' riordinare le istruzioni da eseguire o fare esecuzione speculativa. I branch sono dei killer di performance su queste CPU. Si', sto lottando contro gli if al lavoro perche' l'XCPU e' un chiodo altrimenti :(
Concordo.
Tra l'altro, parlando di eliminazione di if, da quando lavoro con linguaggi ad alto livello come Python, Java, ecc. preferisco sostituirli coi costrutti che questi ultimi mettono a disposizione.
Ad esempio, prima scrivevo roba come questa:
if MyDict.has_key("pippo"):
Value = MyDict["pippo"]
mio codice
else:
altro codice
Adesso preferisco questo:
try:
Value = MyDict["pippo"]
mio codice
except:
altro codice
Parlando con uno dei programmatori Java a lavoro, mi diceva che la tendenza è quella di sfruttare i controlli della JVM per evitare di testare condizioni, anche implicitamente, per far andare il codice più velocemente.
Ad esempio scorrere un intero array fermandosi quando la JVM solleva un'eccezione di index out of bound, intrappolandola con un try / catch, anziché far uso del classico for contenente la condizione di controllo sull'ultimo elemento.
EDIT: corretto esempio. :fiufiu:
Concordo.
Tra l'altro, parlando di eliminazione di if, da quando lavoro con linguaggi ad alto livello come Python, Java, ecc. preferisco sostituirli coi costrutti che questi ultimi mettono a disposizione.
Ad esempio, prima scrivevo roba come questa:
if MyDict.has_key("pippo"):
Value = MyDict["pippo"]
mio codice
else:
altro codice
Adesso preferisco questo:
try:
Value = MyDict["pippo"]
mio codice
except:
altro codice
Parlando con uno dei programmatori Java a lavoro, mi diceva che la tendenza è quella di sfruttare i controlli della JVM per evitare di testare condizioni, anche implicitamente, per far andare il codice più velocemente.
Ad esempio scorrere un intero array fermandosi quando la JVM solleva un'eccezione di index out of bound, intrappolandola con un try / catch, anziché far uso del classico for contenente la condizione di controllo sull'ultimo elemento.
EDIT: corretto esempio. :fiufiu:
cdimauro
15-05-2006, 09:18
Sì, mi riferisco al 6, comunque anche se non stessi studiando VB andrei alla stessa velocità xk sto semplicemente seguendo il corso di scuola, tempo di lavorare da solo a casa non ne ho molto purtroppo, quindi in fondo mi va bene che stia imparando il VB6, in fondo è sempre un linguaggio in +..
Perché provare il 6, quando il VB.NET 2005 è MOLTO meglio sia come linguaggio sia come IDE, e tra l'altro è completamente gratuito? ;)
Riguardo al filmato del browser è molto carino, ma pensavo, avendo a disposizione gli stessi oggetti non si potrebbe fare la stessa cosa anche in VB?
Consiglio di vederlo per intero quel filmato, perché:
1) in VB.NET, C#, Delphi, ecc. la stessa cosa si realizza in 1/10 del tempo;
2) si comprende quanto "IDE" come quelli del filmato siano BEN LONTANI dai canoni di comodità e semplicità d'uso degli altri IDE che ho elencato. ;)
Personalmente, quando ho visto aprire il WORDPAD per scrivere il codice per legare la finestrella appena creata, e il PROMPT DEI COMANDI per compilare il tutto e farlo partire, mi sono stropicciato gli occhi e le orecchie ((C) 2006 by Silvio B. :asd: ). Poi sono scoppiato in una fragorosa risata... :p
Veramente, sono ancora fermi ai tempi della clava (informatica). Dovrebbero dare un'occhiata a Delphi 1.0, il primo ambiente RAD creato per Windows, e rendersi conto di quanto devono ancora lavorare per arrivare a qualcosa di appena comparabile... :D
E stiamo parlando di QT, che non è neppure totalmente "libero", visto che si tratta di un framework proprietario, dotato di doppia licenza (commerciale e GPL). ;)
Perché provare il 6, quando il VB.NET 2005 è MOLTO meglio sia come linguaggio sia come IDE, e tra l'altro è completamente gratuito? ;)
Riguardo al filmato del browser è molto carino, ma pensavo, avendo a disposizione gli stessi oggetti non si potrebbe fare la stessa cosa anche in VB?
Consiglio di vederlo per intero quel filmato, perché:
1) in VB.NET, C#, Delphi, ecc. la stessa cosa si realizza in 1/10 del tempo;
2) si comprende quanto "IDE" come quelli del filmato siano BEN LONTANI dai canoni di comodità e semplicità d'uso degli altri IDE che ho elencato. ;)
Personalmente, quando ho visto aprire il WORDPAD per scrivere il codice per legare la finestrella appena creata, e il PROMPT DEI COMANDI per compilare il tutto e farlo partire, mi sono stropicciato gli occhi e le orecchie ((C) 2006 by Silvio B. :asd: ). Poi sono scoppiato in una fragorosa risata... :p
Veramente, sono ancora fermi ai tempi della clava (informatica). Dovrebbero dare un'occhiata a Delphi 1.0, il primo ambiente RAD creato per Windows, e rendersi conto di quanto devono ancora lavorare per arrivare a qualcosa di appena comparabile... :D
E stiamo parlando di QT, che non è neppure totalmente "libero", visto che si tratta di un framework proprietario, dotato di doppia licenza (commerciale e GPL). ;)
thebol
15-05-2006, 09:27
Parlando con uno dei programmatori Java a lavoro, mi diceva che la tendenza è quella di sfruttare i controlli della JVM per evitare di testare condizioni, anche implicitamente, per far andare il codice più velocemente.
Ad esempio scorrere un intero array fermandosi quando la JVM solleva un'eccezione di index out of bound, intrappolandola con un try / catch, anziché far uso del classico for contenente la condizione di controllo sull'ultimo elemento.
pazzo!!
ora faccio un mega refactoring su diamonds di sta cosa :asd:
cmq apparte gli scherzi, ha vantaggi di efficienza oltre che di dimenticarsi della condizione di uscita dell'if?
Ad esempio scorrere un intero array fermandosi quando la JVM solleva un'eccezione di index out of bound, intrappolandola con un try / catch, anziché far uso del classico for contenente la condizione di controllo sull'ultimo elemento.
pazzo!!
ora faccio un mega refactoring su diamonds di sta cosa :asd:
cmq apparte gli scherzi, ha vantaggi di efficienza oltre che di dimenticarsi della condizione di uscita dell'if?
cdimauro
15-05-2006, 09:34
Certamente, perché non devi testare esplicitamente una condizione, in quanto lo fa già la JVM, che eventualmente solleva l'eccezione. Si tratta di una duplicazione del codice, insomma. ;)
Personalmente è una soluzione che non mi piace molto: preferisco la leggibilità del codice alla sua efficienza. :p
Personalmente è una soluzione che non mi piace molto: preferisco la leggibilità del codice alla sua efficienza. :p
thebol
15-05-2006, 09:39
Certamente, perché non devi testare esplicitamente una condizione, in quanto lo fa già la JVM, che eventualmente solleva l'eccezione. Si tratta di una duplicazione del codice, insomma. ;)
Personalmente è una soluzione che non mi piace molto: preferisco la leggibilità del codice alla sua efficienza. :p
in effetti e molto "particolare" come soluzione
Personalmente è una soluzione che non mi piace molto: preferisco la leggibilità del codice alla sua efficienza. :p
in effetti e molto "particolare" come soluzione
cdimauro
15-05-2006, 09:58
Già. Considera che Python offre anche i classici operatori di assegnazione presenti nel C, quindi +=, -=, ecc., ma io continuo a scrivere x = x + 1 anziché x += 1, per questione di leggibilità. L'onere di ottimizzare il codice lo lascio al compilatore, visto che al giorno d'oggi sono molto evoluti e perfettamente in grado di riconoscere l'equivalenza delle due forme (che in genere vengono rappresentate con lo stesso abstract tree).
Personalmente avrei preferito un simbolo diverso per l'operazione di assegnazione, per rendere ancora più leggibile il codice, ma purtroppo la sintassi più diffusa e "amata" è quella del C (i cui simboli sono stati scelti per una questione puramente statistica, in base alla loro frequenza d'uso :muro: ).
Personalmente avrei preferito un simbolo diverso per l'operazione di assegnazione, per rendere ancora più leggibile il codice, ma purtroppo la sintassi più diffusa e "amata" è quella del C (i cui simboli sono stati scelti per una questione puramente statistica, in base alla loro frequenza d'uso :muro: ).
fek
15-05-2006, 10:20
pazzo!!
ora faccio un mega refactoring su diamonds di sta cosa :asd:
cmq apparte gli scherzi, ha vantaggi di efficienza oltre che di dimenticarsi della condizione di uscita dell'if?
Non ti azzardare. E' molto piu' leggibile e chiaro testare la condizione nel loop e affidarsi al fatto che il JIT sia in grado di rimuovere automaticamente il test interno dell'out of bound.
ora faccio un mega refactoring su diamonds di sta cosa :asd:
cmq apparte gli scherzi, ha vantaggi di efficienza oltre che di dimenticarsi della condizione di uscita dell'if?
Non ti azzardare. E' molto piu' leggibile e chiaro testare la condizione nel loop e affidarsi al fatto che il JIT sia in grado di rimuovere automaticamente il test interno dell'out of bound.
cdimauro
15-05-2006, 10:30
Sono ampiamente d'accordo sulla leggibilità, non sulla bontà del JIT però: devono ancora essere migliorati.
A lavoro c'è una sezione di sviluppo di giochi per telefonini, e hanno fatto diverse prove in merito: oltre alla minor occupazione di bytecode (e per i cellulari è un parametro molto importante), si sono accorti appunto della maggior velocità di esecuzione dell'approccio di cui parlavo sopra.
Sembra di esser tornati ai tempi di C64 e Amiga: sempre alla ricerca di codice compatto e al risparmio del singolo ciclo di clock. :p
A lavoro c'è una sezione di sviluppo di giochi per telefonini, e hanno fatto diverse prove in merito: oltre alla minor occupazione di bytecode (e per i cellulari è un parametro molto importante), si sono accorti appunto della maggior velocità di esecuzione dell'approccio di cui parlavo sopra.
Sembra di esser tornati ai tempi di C64 e Amiga: sempre alla ricerca di codice compatto e al risparmio del singolo ciclo di clock. :p
thebol
15-05-2006, 10:41
Non ti azzardare. E' molto piu' leggibile e chiaro testare la condizione nel loop e affidarsi al fatto che il JIT sia in grado di rimuovere automaticamente il test interno dell'out of bound.
stavo scherzando..
stavo scherzando..
PGI-Bis
15-05-2006, 11:03
E' strano che una cosa del tipo:
try {
for(int i = 0; i++;) piglia l'elemento i dell'array A
} catch(ArrayIndexOutOfBoundsException ex) {}
sia più "veloce" e più compatto del classico:
for(int i = 0; i < a.length; i++) come sopra
perchè, secondo le specifiche della JVM (2.16.2), il primo richiede necessariamente almeno un'istruzione in più: entrambi verificano che l'indice di accesso sia contenuto nella lunghezza dell'array ma il primo esegue anche un instanceof (che è poi un'uguaglianza tra numeri). Misteri delle JVM :D.
try {
for(int i = 0; i++;) piglia l'elemento i dell'array A
} catch(ArrayIndexOutOfBoundsException ex) {}
sia più "veloce" e più compatto del classico:
for(int i = 0; i < a.length; i++) come sopra
perchè, secondo le specifiche della JVM (2.16.2), il primo richiede necessariamente almeno un'istruzione in più: entrambi verificano che l'indice di accesso sia contenuto nella lunghezza dell'array ma il primo esegue anche un instanceof (che è poi un'uguaglianza tra numeri). Misteri delle JVM :D.
thebol
15-05-2006, 11:08
E' strano che una cosa del tipo:
try {
for(int i = 0; i++;) piglia l'elemento i dell'array A
} catch(ArrayIndexOutOfBoundsException ex) {}
sia più "veloce" e più compatto del classico:
for(int i = 0; i < a.length; i++) come sopra
perchè, secondo le specifiche della JVM (2.16.2), il primo richiede necessariamente almeno un'istruzione in più: entrambi verificano che l'indice di accesso sia contenuto nella lunghezza dell'array ma il primo esegue anche un instanceof (che è poi un'uguaglianza tra numeri). Misteri delle JVM :D.
vero, ma ne viene fatto uno per for, non per iterazione.
percui iterando su n numeri, la soluzione con la condizione nel for costa n*2 if, mentre la versione con try-catch n+1 if.
try {
for(int i = 0; i++;) piglia l'elemento i dell'array A
} catch(ArrayIndexOutOfBoundsException ex) {}
sia più "veloce" e più compatto del classico:
for(int i = 0; i < a.length; i++) come sopra
perchè, secondo le specifiche della JVM (2.16.2), il primo richiede necessariamente almeno un'istruzione in più: entrambi verificano che l'indice di accesso sia contenuto nella lunghezza dell'array ma il primo esegue anche un instanceof (che è poi un'uguaglianza tra numeri). Misteri delle JVM :D.
vero, ma ne viene fatto uno per for, non per iterazione.
percui iterando su n numeri, la soluzione con la condizione nel for costa n*2 if, mentre la versione con try-catch n+1 if.
fek
15-05-2006, 11:22
stavo scherzando..
:p
vero, ma ne viene fatto uno per for, non per iterazione.
percui iterando su n numeri, la soluzione con la condizione nel for costa n*2 if, mentre la versione con try-catch n+1 if.
In realta' costano uguali proprio perche' nel caso del loop il JIT "capisce" che il controllo sull out of bound e' gia' fatto quindi elimina quello interno.
:p
vero, ma ne viene fatto uno per for, non per iterazione.
percui iterando su n numeri, la soluzione con la condizione nel for costa n*2 if, mentre la versione con try-catch n+1 if.
In realta' costano uguali proprio perche' nel caso del loop il JIT "capisce" che il controllo sull out of bound e' gia' fatto quindi elimina quello interno.
wingman87
15-05-2006, 11:26
Perché provare il 6, quando il VB.NET 2005 è MOLTO meglio sia come linguaggio sia come IDE, e tra l'altro è completamente gratuito? ;)
Sì, hai ragione, nel caso dell'utente che ha aperto il 3d sì, io purtroppo devo andare avanti così xk come ho detto lo uso a scuola, quindi...
Sì, hai ragione, nel caso dell'utente che ha aperto il 3d sì, io purtroppo devo andare avanti così xk come ho detto lo uso a scuola, quindi...
PGI-Bis
15-05-2006, 11:49
vero, ma ne viene fatto uno per for, non per iterazione.
percui iterando su n numeri, la soluzione con la condizione nel for costa n*2 if, mentre la versione con try-catch n+1 if.
Sia nel primo che nel secondo caso c'è un test per ogni passaggio nel ciclo "i < array.length". Supponiamo anche che il JIT non elimini il "test interno": comunque il ciclo "classico" esegue un solo test (pur contenendone due).
La versione "compatta" non ha la condizione che verifica esplicitamente il contenimento dell'indice di accesso (passatemi la perifrasi): resta quella interna, dettata dalle specifiche del linguaggio.
In ogni caso entrambi i for eseguono quindi un controllo sull'indice di accesso all'array.
La versione "compatta" ha in più un instanceof, perchè deve controllare che l'eccezione sollevata dallo sforamento sia compatibile in assegnamento con il tipo di eccezione intercettato nel catch.
Hey, non dico che sia concretamente impossibile che il classico sia più lento del compatto: per quel che ne so la JVM reale potrebbe anche trasformare il codice in cirillico :D . Ma il punto mi sembra logicamente ineccepibile.
percui iterando su n numeri, la soluzione con la condizione nel for costa n*2 if, mentre la versione con try-catch n+1 if.
Sia nel primo che nel secondo caso c'è un test per ogni passaggio nel ciclo "i < array.length". Supponiamo anche che il JIT non elimini il "test interno": comunque il ciclo "classico" esegue un solo test (pur contenendone due).
La versione "compatta" non ha la condizione che verifica esplicitamente il contenimento dell'indice di accesso (passatemi la perifrasi): resta quella interna, dettata dalle specifiche del linguaggio.
In ogni caso entrambi i for eseguono quindi un controllo sull'indice di accesso all'array.
La versione "compatta" ha in più un instanceof, perchè deve controllare che l'eccezione sollevata dallo sforamento sia compatibile in assegnamento con il tipo di eccezione intercettato nel catch.
Hey, non dico che sia concretamente impossibile che il classico sia più lento del compatto: per quel che ne so la JVM reale potrebbe anche trasformare il codice in cirillico :D . Ma il punto mi sembra logicamente ineccepibile.
cdimauro
15-05-2006, 12:06
Nella versione compatta si hanno n * (incremento + controllo indice JVM) + try/catch "istruzioni".
Nella versione classica si hanno n * (incremento + controllo indice for + controllo indice JVM) "istruzioni".
La prima è più veloce della seconda, a meno che la JVM non sia in grado di rendersi conto del doppio controllo dell'indice e di togliere di mezzo quello superfluo, per cui quella classica si tradurrebbe in n * (incremento + controllo indice JVM) "istruzioni".
Purtroppo le JVM non sono tutte "intelligenti". Dove lavoro sono stati fatti diversi test sulle JVM di diversi telefonini, e la forma compatta risulta la più veloce.
Nella versione classica si hanno n * (incremento + controllo indice for + controllo indice JVM) "istruzioni".
La prima è più veloce della seconda, a meno che la JVM non sia in grado di rendersi conto del doppio controllo dell'indice e di togliere di mezzo quello superfluo, per cui quella classica si tradurrebbe in n * (incremento + controllo indice JVM) "istruzioni".
Purtroppo le JVM non sono tutte "intelligenti". Dove lavoro sono stati fatti diversi test sulle JVM di diversi telefonini, e la forma compatta risulta la più veloce.
fek
15-05-2006, 12:20
Come in tutte queste situazioni, si puo' discutere all'infinito, ma l'unico modo per risolvere il problema e' scrivere il codice e prenderne i tempi :)
PGI-Bis
15-05-2006, 12:21
Nella versione compatta si hanno n * (incremento + controllo indice JVM) + try/catch "istruzioni".
Nella versione classica si hanno n * (incremento + controllo indice for + controllo indice JVM) "istruzioni".
E' evidente e il mio ragionamento era logicamente eccepibilissimo :doh: . Per una qualche strana ragione, nella mia testa un if escludeva l'altro :fagiano:
Evvai, per oggi ho detto la mia str... :D
Nella versione classica si hanno n * (incremento + controllo indice for + controllo indice JVM) "istruzioni".
E' evidente e il mio ragionamento era logicamente eccepibilissimo :doh: . Per una qualche strana ragione, nella mia testa un if escludeva l'altro :fagiano:
Evvai, per oggi ho detto la mia str... :D
PGI-Bis
15-05-2006, 12:23
Come in tutte queste situazioni, si puo' discutere all'infinito
Mai quando la discussione sia onesta. Nel nostro caso io avevo torto marcio.
Mai quando la discussione sia onesta. Nel nostro caso io avevo torto marcio.
thebol
15-05-2006, 12:35
Mai quando la discussione sia onesta. Nel nostro caso io avevo torto marcio.
beh la tua soluzione era giusta se il JIT fosse furbo(come fek diceva).
E probibile che i JIT dei cellulari non siano avanzati come quelli x86 & company, magari proprio per ragioni di efficienza =D
beh la tua soluzione era giusta se il JIT fosse furbo(come fek diceva).
E probibile che i JIT dei cellulari non siano avanzati come quelli x86 & company, magari proprio per ragioni di efficienza =D
fek
15-05-2006, 12:37
beh la tua soluzione era giusta se il JIT fosse furbo(come fek diceva).
E probibile che i JIT dei cellulari non siano avanzati come quelli x86 & company, magari proprio per ragioni di efficienza =D
Mi sembra di ricordare che i compilatori per cellulare fanno una preverifica del codice prima del deploy e siano in grado di intercettare queste situazioni. Non ci metto la mano sul fuoco.
In realta' il discorso e' semplice: a meno che un profiler non dica che quel ciclo e' un collo di bottiglia, si usa la versione piu' leggibile.
E probibile che i JIT dei cellulari non siano avanzati come quelli x86 & company, magari proprio per ragioni di efficienza =D
Mi sembra di ricordare che i compilatori per cellulare fanno una preverifica del codice prima del deploy e siano in grado di intercettare queste situazioni. Non ci metto la mano sul fuoco.
In realta' il discorso e' semplice: a meno che un profiler non dica che quel ciclo e' un collo di bottiglia, si usa la versione piu' leggibile.
cdimauro
15-05-2006, 12:41
E' esattamente ciò che è successo nel nostro caso. ;)
cdimauro
15-05-2006, 12:44
Comunque il panorama dello sviluppo di applicazioni ludiche / multimediali per i cellulari è veramente disarmante: le differenze sono tante che si sta praticamente arrivando a sviluppare n versioni di uno stesso prodotto. :(
jappilas
15-05-2006, 12:51
Guarda l'ultimo task sui menu di Diamonds, e' scritto in C. Lo leggi e te ne accorgi subito. Il design del codice e' C.
:p :stordita: :O
cmq e' un fatto, anche se un po' sofferto, quel task mi e' stato molto utile ... mi ha fatto comprendere parecchie limitazioni del mio modo di pensare ed entrare in un' ottica del tutto nuova :)
Comunque il panorama dello sviluppo di applicazioni ludiche / multimediali per i cellulari è veramente disarmante: le differenze sono tante che si sta praticamente arrivando a sviluppare n versioni di uno stesso prodotto. :(
quasi come all' epoca dei giochini per home computer 8 e 16 bit... :D
tranne che a seconda del periodo, il numero di piattaforme target di quello che si poteva considerare il mainstream di quell' epoca, era andato via via scemando se non ricordo male ...
:p :stordita: :O
cmq e' un fatto, anche se un po' sofferto, quel task mi e' stato molto utile ... mi ha fatto comprendere parecchie limitazioni del mio modo di pensare ed entrare in un' ottica del tutto nuova :)
Comunque il panorama dello sviluppo di applicazioni ludiche / multimediali per i cellulari è veramente disarmante: le differenze sono tante che si sta praticamente arrivando a sviluppare n versioni di uno stesso prodotto. :(
quasi come all' epoca dei giochini per home computer 8 e 16 bit... :D
tranne che a seconda del periodo, il numero di piattaforme target di quello che si poteva considerare il mainstream di quell' epoca, era andato via via scemando se non ricordo male ...
cdimauro
15-05-2006, 13:04
Esattamente. Poi con l'imposizione del PC anche come macchina ludica, si è sostanzialmente appiattito.
Coi cellulari la situazione è l'opposto: è in piena espansione. Ce ne sono con display con risoluzione e palette/spazio colori diversi, che integrano o meno estensioni MMX e/o accelerazione hardware del video, con sezione audio diversa (monofoniche, polifoniche a 16 canali, con WAV, MP3, ecc.), s.o. diversi (Symbian o Java), e quelli con Java con JVM diversa.
Un vero inferno. Per fortuna che faccio tutt'altra cosa (la divisione giochi aveva proposto all'amministratore di farmi passare nelle loro fila, ma il grande capo ha deciso di lasciarmi dove sto. :D).
Coi cellulari la situazione è l'opposto: è in piena espansione. Ce ne sono con display con risoluzione e palette/spazio colori diversi, che integrano o meno estensioni MMX e/o accelerazione hardware del video, con sezione audio diversa (monofoniche, polifoniche a 16 canali, con WAV, MP3, ecc.), s.o. diversi (Symbian o Java), e quelli con Java con JVM diversa.
Un vero inferno. Per fortuna che faccio tutt'altra cosa (la divisione giochi aveva proposto all'amministratore di farmi passare nelle loro fila, ma il grande capo ha deciso di lasciarmi dove sto. :D).
thebol
15-05-2006, 13:14
ho fatto una prova fra 2 versioni:
un array di int da 1.000.000.000 elementi.
un for in cui assegno a lista[i] = i;
su array piu piccoli la differenza e minima e variabile (Da 1 a 20 ms di vantaggio per il try catch).
COn 1.000.000.000 (ci sono arrivato allargando l'heap) la differenza e >100ms e varia da esecuzione a esecuzione(si potrebbe fare sicuramente meglio il test).
Ad esempio 703 vs 547.
Prendo il time con system.currentTime, e faccio la print + flush fuori dal ciclo e dal try.
ps.Separando i test(2 esecuzioni diverse) quello con if ci mette 672 e quello col try 546. In questa maniera i risultati sono molto piu stabili +-10ms
Per cercare di pareggiare la situazione, dopo il for con l'if metto a null l'array, faccio girare il gc, e poi ricreo l'array.
NN posto il codice che ce l'ho sul portatile.
un array di int da 1.000.000.000 elementi.
un for in cui assegno a lista[i] = i;
su array piu piccoli la differenza e minima e variabile (Da 1 a 20 ms di vantaggio per il try catch).
COn 1.000.000.000 (ci sono arrivato allargando l'heap) la differenza e >100ms e varia da esecuzione a esecuzione(si potrebbe fare sicuramente meglio il test).
Ad esempio 703 vs 547.
Prendo il time con system.currentTime, e faccio la print + flush fuori dal ciclo e dal try.
ps.Separando i test(2 esecuzioni diverse) quello con if ci mette 672 e quello col try 546. In questa maniera i risultati sono molto piu stabili +-10ms
Per cercare di pareggiare la situazione, dopo il for con l'if metto a null l'array, faccio girare il gc, e poi ricreo l'array.
NN posto il codice che ce l'ho sul portatile.
PGI-Bis
15-05-2006, 13:50
A me la versione senza controllo esplicito risulta immondamente più lenta. Forse sbaglio qualcosa. ClassicFor è il for classico (che fantasia) CompactFor è l'altro.
Disclaimer: negherò anche di fronte al più sacro dei giuramenti di aver mai scritto l'immondizia che segue.
ClassicFor.java
public class ClassicFor {
static {
int x = 0;
int[] values = new int[1000000];
long dt = 0;
/** Ripete per 100 volte il test */
for(int k = 0; k < 100; k++) {
long t0 = System.nanoTime();
/** Fa qualcosa coi valori di un array */
for(int i = 0; i < values.length; i++) {
x += values[i];
}
long t1 = System.nanoTime();
dt += t1 - t0;
}
/** Calcola il tempo medio in ms di un test */
java.math.BigDecimal dec = new java.math.BigDecimal(dt / 100 / 1e6,
new java.math.MathContext(3));
System.out.println("Compact: " + dec + "ms");
System.exit(0);
}
}
CompactFor.java
public class CompactFor {
static {
int x = 0;
int[] values = new int[1000000];
long dt = 0;
/** Ripete per 100 volte il test */
for(int k = 0; k < 100; k++) {
long t0 = System.nanoTime();
/** Fa qualcosa coi valori di un array */
try {
for(int i = 0; ; i++) {
x += values[i];
}
} catch(ArrayIndexOutOfBoundsException ex) {}
long t1 = System.nanoTime();
dt += t1 - t0;
}
/** Calcola il tempo medio in ms di un test */
java.math.BigDecimal dec = new java.math.BigDecimal(dt / 100 / 1e6,
new java.math.MathContext(3));
System.out.println("Compact: " + dec + "ms");
System.exit(0);
}
}
Nel ciclo faccio una somma per evitare che il JIT (ammesso che lo sappia fare) scarti direttamente il ciclo for. La granularità di System.nanoTime dovrebbe essere di 1ms in Windows.
Da me è un costante 3 a 5 (meno è meglio) a favore del classico. Dove sbaglio :confused:
Disclaimer: negherò anche di fronte al più sacro dei giuramenti di aver mai scritto l'immondizia che segue.
ClassicFor.java
public class ClassicFor {
static {
int x = 0;
int[] values = new int[1000000];
long dt = 0;
/** Ripete per 100 volte il test */
for(int k = 0; k < 100; k++) {
long t0 = System.nanoTime();
/** Fa qualcosa coi valori di un array */
for(int i = 0; i < values.length; i++) {
x += values[i];
}
long t1 = System.nanoTime();
dt += t1 - t0;
}
/** Calcola il tempo medio in ms di un test */
java.math.BigDecimal dec = new java.math.BigDecimal(dt / 100 / 1e6,
new java.math.MathContext(3));
System.out.println("Compact: " + dec + "ms");
System.exit(0);
}
}
CompactFor.java
public class CompactFor {
static {
int x = 0;
int[] values = new int[1000000];
long dt = 0;
/** Ripete per 100 volte il test */
for(int k = 0; k < 100; k++) {
long t0 = System.nanoTime();
/** Fa qualcosa coi valori di un array */
try {
for(int i = 0; ; i++) {
x += values[i];
}
} catch(ArrayIndexOutOfBoundsException ex) {}
long t1 = System.nanoTime();
dt += t1 - t0;
}
/** Calcola il tempo medio in ms di un test */
java.math.BigDecimal dec = new java.math.BigDecimal(dt / 100 / 1e6,
new java.math.MathContext(3));
System.out.println("Compact: " + dec + "ms");
System.exit(0);
}
}
Nel ciclo faccio una somma per evitare che il JIT (ammesso che lo sappia fare) scarti direttamente il ciclo for. La granularità di System.nanoTime dovrebbe essere di 1ms in Windows.
Da me è un costante 3 a 5 (meno è meglio) a favore del classico. Dove sbaglio :confused:
fek
15-05-2006, 13:53
Da me è un costante 3 a 5 (meno è meglio) a favore del classico. Dove sbaglio :confused:
Da nessuna parte, noi programmatori siamo storicamente molto scarsi a indovinare i colli di bottiglia e a capire quale versione e' piu' ottimizzata :)
Da nessuna parte, noi programmatori siamo storicamente molto scarsi a indovinare i colli di bottiglia e a capire quale versione e' piu' ottimizzata :)
marco.r
15-05-2006, 14:03
Parlando con uno dei programmatori Java a lavoro, mi diceva che la tendenza è quella di sfruttare i controlli della JVM per evitare di testare condizioni, anche implicitamente, per far andare il codice più velocemente.
Ad esempio scorrere un intero array fermandosi quando la JVM solleva un'eccezione di index out of bound, intrappolandola con un try / catch, anziché far uso del classico for contenente la condizione di controllo sull'ultimo elemento.
Non la trovo una bella idea... le eccezioni dovrebbero servire per le condizioni eccezionali. Penso che il classico iteratore sia la soluzione piu' semplice e generale, niente controlli sui bound, niente eccezioni da raccogliere (a livello di codice scritto, non di quello eseguito ovviamente).
Ad esempio scorrere un intero array fermandosi quando la JVM solleva un'eccezione di index out of bound, intrappolandola con un try / catch, anziché far uso del classico for contenente la condizione di controllo sull'ultimo elemento.
Non la trovo una bella idea... le eccezioni dovrebbero servire per le condizioni eccezionali. Penso che il classico iteratore sia la soluzione piu' semplice e generale, niente controlli sui bound, niente eccezioni da raccogliere (a livello di codice scritto, non di quello eseguito ovviamente).
cdimauro
15-05-2006, 14:09
Non vedo perché non si dovrebbero usare, se sono previste dal linguaggio. Se Sun afferma che verrà generata un'eccezione di out of bound index se tento di accedere a un elemento fuori dal range previsto dal vettore, io posso benissimo usare quest'informazione a mio uso e consumo: non ci vedo assolutamente nulla di male. ;)
cdimauro
15-05-2006, 14:12
A me la versione senza controllo esplicito risulta immondamente più lenta. Forse sbaglio qualcosa. ClassicFor è il for classico (che fantasia) CompactFor è l'altro.
[...]
Nel ciclo faccio una somma per evitare che il JIT (ammesso che lo sappia fare) scarti direttamente il ciclo for. La granularità di System.nanoTime dovrebbe essere di 1ms in Windows.
Da me è un costante 3 a 5 (meno è meglio) a favore del classico. Dove sbaglio :confused:
Dovremmo chiederlo al JIT... :p
[...]
Nel ciclo faccio una somma per evitare che il JIT (ammesso che lo sappia fare) scarti direttamente il ciclo for. La granularità di System.nanoTime dovrebbe essere di 1ms in Windows.
Da me è un costante 3 a 5 (meno è meglio) a favore del classico. Dove sbaglio :confused:
Dovremmo chiederlo al JIT... :p
fek
15-05-2006, 14:20
Non vedo perché non si dovrebbero usare, se sono previste dal linguaggio. Se Sun afferma che verrà generata un'eccezione di out of bound index se tento di accedere a un elemento fuori dal range previsto dal vettore, io posso benissimo usare quest'informazione a mio uso e consumo: non ci vedo assolutamente nulla di male. ;)
Cesare, ha ragione marco qui: le eccezioni, come da nome, sono un costrutto che indica una condizione eccezionale del codice, che non dovrebbe mai accadere, e, se accade, va trattata in maniera eccezionale. La fine di un loop non e' una condizione eccezionale, e' una condizione normale, quindi, logicamente, non va usato quel costrutto. Se lo si usa, si sta abusando del linguaggio e non e' mai una buona idea.
Cesare, ha ragione marco qui: le eccezioni, come da nome, sono un costrutto che indica una condizione eccezionale del codice, che non dovrebbe mai accadere, e, se accade, va trattata in maniera eccezionale. La fine di un loop non e' una condizione eccezionale, e' una condizione normale, quindi, logicamente, non va usato quel costrutto. Se lo si usa, si sta abusando del linguaggio e non e' mai una buona idea.
PGI-Bis
15-05-2006, 14:22
Basta, ho il mal di testa. Se disabilito il JIT e GC e alloco tutta la memoria all'avvio vince il compatto di un'enormità (32.7ms per CompactFor, 76.7 per ClassicFor).
Ragazzi, queste cose tenetevele per voi perchè poi io ci perdo le giornate :D
Ragazzi, queste cose tenetevele per voi perchè poi io ci perdo le giornate :D
marco.r
15-05-2006, 14:30
if MyDict.has_key("pippo"):
Value = MyDict["pippo"]
mio codice
else:
altro codice
Adesso preferisco questo:
try:
Value = MyDict["pippo"]
mio codice
except:
altro codice
A seconda del contesto ci possono essere varianti piu' carine,
come ad esempio
Value = MyDict.get("pippo",defaultValue)
Se il codice è lo stesso ma devo assicurare un valore di default.
Altre volte è possibile linearizzare il codice lavorando non sul
singolo elemento ma sull'intera collezione, cosi' da sostituire il lookup con
una iterazione.
Value = MyDict["pippo"]
mio codice
else:
altro codice
Adesso preferisco questo:
try:
Value = MyDict["pippo"]
mio codice
except:
altro codice
A seconda del contesto ci possono essere varianti piu' carine,
come ad esempio
Value = MyDict.get("pippo",defaultValue)
Se il codice è lo stesso ma devo assicurare un valore di default.
Altre volte è possibile linearizzare il codice lavorando non sul
singolo elemento ma sull'intera collezione, cosi' da sostituire il lookup con
una iterazione.
cdimauro
15-05-2006, 14:49
Cesare, ha ragione marco qui: le eccezioni, come da nome, sono un costrutto che indica una condizione eccezionale del codice, che non dovrebbe mai accadere, e, se accade, va trattata in maniera eccezionale. La fine di un loop non e' una condizione eccezionale, e' una condizione normale, quindi, logicamente, non va usato quel costrutto. Se lo si usa, si sta abusando del linguaggio e non e' mai una buona idea.
Mumble mumble. Capisco cosa vuoi dire, ma dipende dai casi. Come programmatori dovremmo conoscere bene gli strumenti che usiamo e non andare oltre il "contratto" che essi mettono a disposizione.
Sappiamo che Java, per sua natura, mette a disposizione un ambiente "safe" (o "managed", che dir si voglia :p).
Da questo punto di vista, il fatto che in Java sia "regolamentato" un caso come quello citato, lo mette sul piano del lecito.
Anche in Python, ad esempio, nell'implementare i generatori si solleva un'eccezione in next() quando non ci sono più elementi; l'eccezione viene intercettata dal sistema e comporta l'uscita dal generatore, in maniera trasparente all'applicazione che lo usava iterando sugli elementi che gli metteva a disposizione.
La situazione è analoga a quella dello scorrimento degli elementi del vettore di cui sopra.
Si tratta di punti di vista leciti, IMHO
Non stiamo discutendo dell'uso o meno di puntatori come interi, di assunzioni sull'endianess o sull'uso dei campi di bit col C.
Mumble mumble. Capisco cosa vuoi dire, ma dipende dai casi. Come programmatori dovremmo conoscere bene gli strumenti che usiamo e non andare oltre il "contratto" che essi mettono a disposizione.
Sappiamo che Java, per sua natura, mette a disposizione un ambiente "safe" (o "managed", che dir si voglia :p).
Da questo punto di vista, il fatto che in Java sia "regolamentato" un caso come quello citato, lo mette sul piano del lecito.
Anche in Python, ad esempio, nell'implementare i generatori si solleva un'eccezione in next() quando non ci sono più elementi; l'eccezione viene intercettata dal sistema e comporta l'uscita dal generatore, in maniera trasparente all'applicazione che lo usava iterando sugli elementi che gli metteva a disposizione.
La situazione è analoga a quella dello scorrimento degli elementi del vettore di cui sopra.
Si tratta di punti di vista leciti, IMHO
Non stiamo discutendo dell'uso o meno di puntatori come interi, di assunzioni sull'endianess o sull'uso dei campi di bit col C.
marco.r
15-05-2006, 14:53
Non vedo perché non si dovrebbero usare, se sono previste dal linguaggio. Se Sun afferma che verrà generata un'eccezione di out of bound index se tento di accedere a un elemento fuori dal range previsto dal vettore, io posso benissimo usare quest'informazione a mio uso e consumo: non ci vedo assolutamente nulla di male. ;)
Non è che si debbano usare, solo che per una questione di leggibilità lo trovo inopportuno.
Se si tratta di tre righe il significato è abbastanza evidente,
ma se il corpo del ciclo diventa un po' piu' grande, devo saltare con l'occhio all'inizio e alla fine del blocco per capire come viene eseguito. Oltre a questo rischi di introdurre errori subdoli. In particolare non puoi piu' gestire il caso in cui effettivamente sfori dall'array per un errore di programmazione, e il controllo sui margini avviene all'interno del blocco invece che all'inizio.
Faccio un esempio un po' estremo... :D
int[] values = new int[1000];
/* blabla */
try {
for ( int i=0 ; ; i++ ) {
scaricaUnFileDaUnGigaByteDaInternet()
print values[i]
}
} catch(ArrayIndexOutOfBoundsException ex) {}
Rischi di scaricare un giga di troppo... :D
L'errore puo' sembrare grossolano, ma è possibile che accada se la riga di download viene aggiunta dopo da un altro programmatore, e alla meglio costringi il programmatore a riscrivere il ciclo per renderlo corretto.
E in ogni caso, a meno di loop molto stretti, il gioco non vale la candela visto che la maggior parte del tempo verrà passata ad eseguire il codice del loop, e non il controllo sui limiti.
Non è che si debbano usare, solo che per una questione di leggibilità lo trovo inopportuno.
Se si tratta di tre righe il significato è abbastanza evidente,
ma se il corpo del ciclo diventa un po' piu' grande, devo saltare con l'occhio all'inizio e alla fine del blocco per capire come viene eseguito. Oltre a questo rischi di introdurre errori subdoli. In particolare non puoi piu' gestire il caso in cui effettivamente sfori dall'array per un errore di programmazione, e il controllo sui margini avviene all'interno del blocco invece che all'inizio.
Faccio un esempio un po' estremo... :D
int[] values = new int[1000];
/* blabla */
try {
for ( int i=0 ; ; i++ ) {
scaricaUnFileDaUnGigaByteDaInternet()
print values[i]
}
} catch(ArrayIndexOutOfBoundsException ex) {}
Rischi di scaricare un giga di troppo... :D
L'errore puo' sembrare grossolano, ma è possibile che accada se la riga di download viene aggiunta dopo da un altro programmatore, e alla meglio costringi il programmatore a riscrivere il ciclo per renderlo corretto.
E in ogni caso, a meno di loop molto stretti, il gioco non vale la candela visto che la maggior parte del tempo verrà passata ad eseguire il codice del loop, e non il controllo sui limiti.
cdimauro
15-05-2006, 14:53
Basta, ho il mal di testa. Se disabilito il JIT e GC e alloco tutta la memoria all'avvio vince il compatto di un'enormità (32.7ms per CompactFor, 76.7 per ClassicFor).
Ragazzi, queste cose tenetevele per voi perchè poi io ci perdo le giornate :D
Hai provato ad allocare tutta la memoria all'avvio con JIT e GC attivi? Giusto per curiosità.
P.S. Bella discussione. :D
Ragazzi, queste cose tenetevele per voi perchè poi io ci perdo le giornate :D
Hai provato ad allocare tutta la memoria all'avvio con JIT e GC attivi? Giusto per curiosità.
P.S. Bella discussione. :D
cdimauro
15-05-2006, 14:56
A seconda del contesto ci possono essere varianti piu' carine,
come ad esempio
Value = MyDict.get("pippo",defaultValue)
Se il codice è lo stesso ma devo assicurare un valore di default.
Altre volte è possibile linearizzare il codice lavorando non sul
singolo elemento ma sull'intera collezione, cosi' da sostituire il lookup con
una iterazione.
E' quel che faccio in genere. :)
P.S. Il vecchio codice risente abbastanza dell'inesperienza: ogni giorno saltano fuori tante cosucce interessanti lavorando con Python... :p
come ad esempio
Value = MyDict.get("pippo",defaultValue)
Se il codice è lo stesso ma devo assicurare un valore di default.
Altre volte è possibile linearizzare il codice lavorando non sul
singolo elemento ma sull'intera collezione, cosi' da sostituire il lookup con
una iterazione.
E' quel che faccio in genere. :)
P.S. Il vecchio codice risente abbastanza dell'inesperienza: ogni giorno saltano fuori tante cosucce interessanti lavorando con Python... :p
marco.r
15-05-2006, 15:02
E' quel che faccio in genere. :)
P.S. Il vecchio codice risente abbastanza dell'inesperienza: ogni giorno saltano fuori tante cosucce interessanti lavorando con Python... :p
A chi lo dici... io ho scoperto solo ieri che con la versione 2.4 oltre alla liste si possono generare iteratori semplicemente sostituendo le [] con le ()
value = sum( x*x for x in range(1000) )
Bellissimo !
P.S. Il vecchio codice risente abbastanza dell'inesperienza: ogni giorno saltano fuori tante cosucce interessanti lavorando con Python... :p
A chi lo dici... io ho scoperto solo ieri che con la versione 2.4 oltre alla liste si possono generare iteratori semplicemente sostituendo le [] con le ()
value = sum( x*x for x in range(1000) )
Bellissimo !
cdimauro
15-05-2006, 15:03
Non è che si debbano usare, solo che per una questione di leggibilità lo trovo inopportuno.
Se si tratta di tre righe il significato è abbastanza evidente,
ma se il corpo del ciclo diventa un po' piu' grande, devo saltare con l'occhio all'inizio e alla fine del blocco per capire come viene eseguito. Oltre a questo rischi di introdurre errori subdoli. In particolare non puoi piu' gestire il caso in cui effettivamente sfori dall'array per un errore di programmazione, e il controllo sui margini avviene all'interno del blocco invece che all'inizio.
Faccio un esempio un po' estremo... :D
int[] values = new int[1000];
/* blabla */
try {
for ( int i=0 ; ; i++ ) {
scaricaUnFileDaUnGigaByteDaInternet()
print values[i]
}
} catch(ArrayIndexOutOfBoundsException ex) {}
Rischi di scaricare un giga di troppo... :D
L'errore puo' sembrare grossolano, ma è possibile che accada se la riga di download viene aggiunta dopo da un altro programmatore, e alla meglio costringi il programmatore a riscrivere il ciclo per renderlo corretto.
E in ogni caso, a meno di loop molto stretti, il gioco non vale la candela visto che la maggior parte del tempo verrà passata ad eseguire il codice del loop, e non il controllo sui limiti.
Guarda, per quanto mi riguarda se tiri in ballo la leggibilità con me vai a nozze. :p
Preferisco nettamente un codice più leggibile ma meno efficiente a uno criptico che cerca di risparmiare qualche ciclo di clock (se veramente ci riesce). ;)
Peggio ancora nel caso in cui, come sottolineavi, il codice possa andare a finire fra le mani di altre persone.
Per quanto riguarda l'esempio che ho fatto, fra l'if con l'has_key e il try / except, il secondo caso non è affatto la mia unica scelta. Dipende tutto dal codice che devo eseguire all'interno del try: se può sollevare un'eccezione, in genere preferisco utilizzare la forma con l'if.
Il caso comune, per me, è quello di un dizionario inizialmente vuoto che va via via riempendosi, per cui il try / except è la scelta che effettuo (se non vengono generate eccezioni, appunto).
Se si tratta di tre righe il significato è abbastanza evidente,
ma se il corpo del ciclo diventa un po' piu' grande, devo saltare con l'occhio all'inizio e alla fine del blocco per capire come viene eseguito. Oltre a questo rischi di introdurre errori subdoli. In particolare non puoi piu' gestire il caso in cui effettivamente sfori dall'array per un errore di programmazione, e il controllo sui margini avviene all'interno del blocco invece che all'inizio.
Faccio un esempio un po' estremo... :D
int[] values = new int[1000];
/* blabla */
try {
for ( int i=0 ; ; i++ ) {
scaricaUnFileDaUnGigaByteDaInternet()
print values[i]
}
} catch(ArrayIndexOutOfBoundsException ex) {}
Rischi di scaricare un giga di troppo... :D
L'errore puo' sembrare grossolano, ma è possibile che accada se la riga di download viene aggiunta dopo da un altro programmatore, e alla meglio costringi il programmatore a riscrivere il ciclo per renderlo corretto.
E in ogni caso, a meno di loop molto stretti, il gioco non vale la candela visto che la maggior parte del tempo verrà passata ad eseguire il codice del loop, e non il controllo sui limiti.
Guarda, per quanto mi riguarda se tiri in ballo la leggibilità con me vai a nozze. :p
Preferisco nettamente un codice più leggibile ma meno efficiente a uno criptico che cerca di risparmiare qualche ciclo di clock (se veramente ci riesce). ;)
Peggio ancora nel caso in cui, come sottolineavi, il codice possa andare a finire fra le mani di altre persone.
Per quanto riguarda l'esempio che ho fatto, fra l'if con l'has_key e il try / except, il secondo caso non è affatto la mia unica scelta. Dipende tutto dal codice che devo eseguire all'interno del try: se può sollevare un'eccezione, in genere preferisco utilizzare la forma con l'if.
Il caso comune, per me, è quello di un dizionario inizialmente vuoto che va via via riempendosi, per cui il try / except è la scelta che effettuo (se non vengono generate eccezioni, appunto).
h1jack3r
15-05-2006, 15:03
Interessante il discorsoce state facendo.
Rispetto al discorso iniziale del thread mi piacerebbe sentire l'opinione di Cionci, il grande assente del thread
Rispetto al discorso iniziale del thread mi piacerebbe sentire l'opinione di Cionci, il grande assente del thread
cdimauro
15-05-2006, 15:04
A chi lo dici... io ho scoperto solo ieri che con la versione 2.4 oltre alla liste si possono generare iteratori semplicemente sostituendo le [] con le ()
value = sum( x*x for x in range(1000) )
Bellissimo !
E molto efficiente. :p
value = sum( x*x for x in range(1000) )
Bellissimo !
E molto efficiente. :p
PGI-Bis
15-05-2006, 15:13
Hai provato ad allocare tutta la memoria all'avvio con JIT e GC attivi? Giusto per curiosità.
Il JIT favorisce l'approccio classico, probabilmente per la sua prevedibilità. Il ciclo sui componenti di un array è talmente comune che mi stupirei se non fosse oggetto di ogni possibile attenzione da parte della JVM.
Circa l'uso dell'eccezione come condizione di uscita da un ciclo, direi "dipende". Se accettiamo l'idea che un linguaggio di programmazione sia in primo luogo una lingua, cioè una forma di comunicazione umana, per quanto semplice, allora l'uso dell'eccezione come condizione d'uscita è errato tanto quanto è errato dire (in Java):
int x = new Object();
Come strumenti di comunicazione, le lingue sono fatte di simboli e significati. Io credo che una delle differenze maggiori tra lingue "classiche" e linguaggi di programmazione sia la mancanza pressochè assoluta di sinonimi. Si gioca al risparmio e se pare che due simboli significhino la stessa cosa al 99% si è capito male.
L'eccezione in Java significa che si è verificato un impedimento accidentale al raggiungimento dello scopo di un'istruzione o un blocco di istruzioni.
Il compatto ci propina un'eccezione che non solo non è accidentale ma segnala addirittura che lo scopo è stato raggiunto. Roba da strapparsi i capelli (quelli che genetica e gravità abbiano avuto la bontà di risparmiare).
Vale solo se si concordi sulla comparabilità tra, puta caso, Java e il Russo. L'alternativa non è delle migliori: se non è lingua allora è un instruction set, più o meno addolcito. E lì non ci sono significati: solo effetti.
Il JIT favorisce l'approccio classico, probabilmente per la sua prevedibilità. Il ciclo sui componenti di un array è talmente comune che mi stupirei se non fosse oggetto di ogni possibile attenzione da parte della JVM.
Circa l'uso dell'eccezione come condizione di uscita da un ciclo, direi "dipende". Se accettiamo l'idea che un linguaggio di programmazione sia in primo luogo una lingua, cioè una forma di comunicazione umana, per quanto semplice, allora l'uso dell'eccezione come condizione d'uscita è errato tanto quanto è errato dire (in Java):
int x = new Object();
Come strumenti di comunicazione, le lingue sono fatte di simboli e significati. Io credo che una delle differenze maggiori tra lingue "classiche" e linguaggi di programmazione sia la mancanza pressochè assoluta di sinonimi. Si gioca al risparmio e se pare che due simboli significhino la stessa cosa al 99% si è capito male.
L'eccezione in Java significa che si è verificato un impedimento accidentale al raggiungimento dello scopo di un'istruzione o un blocco di istruzioni.
Il compatto ci propina un'eccezione che non solo non è accidentale ma segnala addirittura che lo scopo è stato raggiunto. Roba da strapparsi i capelli (quelli che genetica e gravità abbiano avuto la bontà di risparmiare).
Vale solo se si concordi sulla comparabilità tra, puta caso, Java e il Russo. L'alternativa non è delle migliori: se non è lingua allora è un instruction set, più o meno addolcito. E lì non ci sono significati: solo effetti.
G|4Di4k
15-05-2006, 15:16
poi il tuo paragone con la matematica lo riproporrei in questo modo:
Goedel e i Principia Mathematica di Russell -> assembler
aritmetica -> C
come vedi nessuno di noi si è mai sognato di iniziare dall'assembler come mai nessuno si sognerà di iniziare da Goedel :D
Io ho iniziato dall'assembler:
1) Assembler
2) C
3) C++
4) Java
5) C#
Nel mezzo anche accenni di html e php :)
Goedel e i Principia Mathematica di Russell -> assembler
aritmetica -> C
come vedi nessuno di noi si è mai sognato di iniziare dall'assembler come mai nessuno si sognerà di iniziare da Goedel :D
Io ho iniziato dall'assembler:
1) Assembler
2) C
3) C++
4) Java
5) C#
Nel mezzo anche accenni di html e php :)
cdimauro
15-05-2006, 15:27
Il JIT favorisce l'approccio classico, probabilmente per la sua prevedibilità. Il ciclo sui componenti di un array è talmente comune che mi stupirei se non fosse oggetto di ogni possibile attenzione da parte della JVM.
Forse proprio per questo non si comporta bene con codice che non riesce a riconoscere come tale (ciclo). ;)
Circa l'uso dell'eccezione come condizione di uscita da un ciclo, direi "dipende". Se accettiamo l'idea che un linguaggio di programmazione sia in primo luogo una lingua, cioè una forma di comunicazione umana, per quanto semplice, allora l'uso dell'eccezione come condizione d'uscita è errato tanto quanto è errato dire (in Java):
int x = new Object();
Come strumenti di comunicazione, le lingue sono fatte di simboli e significati. Io credo che una delle differenze maggiori tra lingue "classiche" e linguaggi di programmazione sia la mancanza pressochè assoluta di sinonimi. Si gioca al risparmio e se pare che due simboli significhino la stessa cosa al 99% si è capito male.
L'eccezione in Java significa che si è verificato un impedimento accidentale al raggiungimento dello scopo di un'istruzione o un blocco di istruzioni.
Il compatto ci propina un'eccezione che non solo non è accidentale ma segnala addirittura che lo scopo è stato raggiunto. Roba da strapparsi i capelli (quelli che genetica e gravità abbiano avuto la bontà di risparmiare).
Vale solo se si concordi sulla comparabilità tra, puta caso, Java e il Russo. L'alternativa non è delle migliori: se non è lingua allora è un instruction set, più o meno addolcito. E lì non ci sono significati: solo effetti.
Virtus in medio stat. :)
Non possiamo prendere Java soltanto dal punto di vista sintattico: esiste anche la semantica. ;)
L'esempio che ho fatto prima penso che rispecchi bene la situazione in cui si pone il programmatore davanti alla scelta di uno dei due costrutti.
Se dovessimo considerare le eccezioni soltanto... eccezioni :p, allora dovremmo programmare tenendo conto (quasi) esclusivamente della sintassi, e sceglieremmo sempre la forma con l'if has_key. Ma non è così.
A mio avviso il sistema delle eccezioni che è stato introdotto nei linguaggi da un po' di anni a questa parte non deve servire esclusivamente per segnalare dei casi "anomali": può essere usato anche per pensare e scrivere del codice in maniera diversa.
La libertà del programmatore è cresciuta, insomma. ;)
Forse proprio per questo non si comporta bene con codice che non riesce a riconoscere come tale (ciclo). ;)
Circa l'uso dell'eccezione come condizione di uscita da un ciclo, direi "dipende". Se accettiamo l'idea che un linguaggio di programmazione sia in primo luogo una lingua, cioè una forma di comunicazione umana, per quanto semplice, allora l'uso dell'eccezione come condizione d'uscita è errato tanto quanto è errato dire (in Java):
int x = new Object();
Come strumenti di comunicazione, le lingue sono fatte di simboli e significati. Io credo che una delle differenze maggiori tra lingue "classiche" e linguaggi di programmazione sia la mancanza pressochè assoluta di sinonimi. Si gioca al risparmio e se pare che due simboli significhino la stessa cosa al 99% si è capito male.
L'eccezione in Java significa che si è verificato un impedimento accidentale al raggiungimento dello scopo di un'istruzione o un blocco di istruzioni.
Il compatto ci propina un'eccezione che non solo non è accidentale ma segnala addirittura che lo scopo è stato raggiunto. Roba da strapparsi i capelli (quelli che genetica e gravità abbiano avuto la bontà di risparmiare).
Vale solo se si concordi sulla comparabilità tra, puta caso, Java e il Russo. L'alternativa non è delle migliori: se non è lingua allora è un instruction set, più o meno addolcito. E lì non ci sono significati: solo effetti.
Virtus in medio stat. :)
Non possiamo prendere Java soltanto dal punto di vista sintattico: esiste anche la semantica. ;)
L'esempio che ho fatto prima penso che rispecchi bene la situazione in cui si pone il programmatore davanti alla scelta di uno dei due costrutti.
Se dovessimo considerare le eccezioni soltanto... eccezioni :p, allora dovremmo programmare tenendo conto (quasi) esclusivamente della sintassi, e sceglieremmo sempre la forma con l'if has_key. Ma non è così.
A mio avviso il sistema delle eccezioni che è stato introdotto nei linguaggi da un po' di anni a questa parte non deve servire esclusivamente per segnalare dei casi "anomali": può essere usato anche per pensare e scrivere del codice in maniera diversa.
La libertà del programmatore è cresciuta, insomma. ;)
cdimauro
15-05-2006, 15:31
Io ho iniziato dall'assembler:
1) Assembler
Assembly
2) C
3) C++
4) Java
5) C#
Nel mezzo anche accenni di html e php :)
Prova Python. :) Poi con mod_python + ClearSilver puoi buttare via anche HTML e (soprattutto) PHP. :D
1) Assembler
Assembly
2) C
3) C++
4) Java
5) C#
Nel mezzo anche accenni di html e php :)
Prova Python. :) Poi con mod_python + ClearSilver puoi buttare via anche HTML e (soprattutto) PHP. :D
G|4Di4k
15-05-2006, 15:34
Si assembly...vabbè :P
Ma ti dirò, il pitone mi aveva incuriosito ma non ho mai approfondito perchè non comprendo bene i suoi reali campi di applicazione :P
Come lo sfrutti ?
Ma ti dirò, il pitone mi aveva incuriosito ma non ho mai approfondito perchè non comprendo bene i suoi reali campi di applicazione :P
Come lo sfrutti ?
PGI-Bis
15-05-2006, 15:41
Sul punto della semantica abbiamo una visione molto diversa. Per me quella particolare possibilità offerta dalle eccezioni non è un significato, cioè non appartiene alla semantica del linguaggio Java come strumento di comunicazione.
Come strumento di programmazione è invece indubitabile che lo sia. Ma ragionerei più in termini di causalità: se faccio così capita cosà. Come dire che ci sono effetti senza significati.
Tieni conto che io ritengo (visione personale) che sia improprio parlare di semantica nell'ambito delle specifiche di un linguaggio di programmazione: le intendo invece come collezioni di effetti, senza arte nè parte.
Come strumento di programmazione è invece indubitabile che lo sia. Ma ragionerei più in termini di causalità: se faccio così capita cosà. Come dire che ci sono effetti senza significati.
Tieni conto che io ritengo (visione personale) che sia improprio parlare di semantica nell'ambito delle specifiche di un linguaggio di programmazione: le intendo invece come collezioni di effetti, senza arte nè parte.
cdimauro
15-05-2006, 15:44
x G|4Di4k. Per tutto. Dai banali script che si mangiano dei file di testo filtrando le informazioni, ai server web, ad applicazioni che manipolano file XML, a server / client SOAP, a server / client Ice, accesso a db con qualche milione di record di utenti, ecc. ecc.
A lavoro uso quasi esclusivamente Python. Il PHP sono costretto a usarlo soltanto per sviluppare dei mini client "dimostrativi" in PHP ai miei colleghi (che usano ancora quest'orribile linguaggio) per accedere ai server Ice che ho scritto in Python. ;)
A lavoro uso quasi esclusivamente Python. Il PHP sono costretto a usarlo soltanto per sviluppare dei mini client "dimostrativi" in PHP ai miei colleghi (che usano ancora quest'orribile linguaggio) per accedere ai server Ice che ho scritto in Python. ;)
G|4Di4k
15-05-2006, 15:48
x G|4Di4k. Per tutto. Dai banali script che si mangiano dei file di testo filtrando le informazioni, ai server web, ad applicazioni che manipolano file XML, a server / client SOAP, a server / client Ice, accesso a db con qualche milione di record di utenti, ecc. ecc.
A lavoro uso quasi esclusivamente Python. Il PHP sono costretto a usarlo soltanto per sviluppare dei mini client "dimostrativi" in PHP ai miei colleghi (che usano ancora quest'orribile linguaggio) per accedere ai server Ice che ho scritto in Python. ;)
Usi qualche ide o vai di "notepad" ?
Sembra buono da come me lo descrivi :D
A lavoro uso quasi esclusivamente Python. Il PHP sono costretto a usarlo soltanto per sviluppare dei mini client "dimostrativi" in PHP ai miei colleghi (che usano ancora quest'orribile linguaggio) per accedere ai server Ice che ho scritto in Python. ;)
Usi qualche ide o vai di "notepad" ?
Sembra buono da come me lo descrivi :D
cdimauro
15-05-2006, 15:58
Sul punto della semantica abbiamo una visione molto diversa. Per me quella particolare possibilità offerta dalle eccezioni non è un significato, cioè non appartiene alla semantica del linguaggio Java come strumento di comunicazione.
Come strumento di programmazione è invece indubitabile che lo sia. Ma ragionerei più in termini di causalità: se faccio così capita cosà. Come dire che ci sono effetti senza significati.
Tieni conto che io ritengo (visione personale) che sia improprio parlare di semantica nell'ambito delle specifiche di un linguaggio di programmazione: le intendo invece come collezioni di effetti, senza arte nè parte.
In quanto programmatore per me ha senso pensare a, pesare e usare entrambe le cose. :) Anzi, io considero anche altro: persino l'uso degli IDE con editor avente syntax highlight può farmi cambiare il modo in cui scrivo il mio codice.
Ad esempio, un paio decenni fa, quando lavoravo con le prime versioni del Turbo Pascal, scrivevo le parole riservate e gli identificatori con l'iniziale maiuscola. Con l'avvento degli editor aventi syntax highlight, ho smesso progressivamente di scrivere le parole riservate in questo modo, lasciando tutto in minuscolo.
Un altro esempio è con Python (sempre lui :D). Molti non lo apprezzano a causa dell'uso che fa dell'indentazione.
Se dovessi lavorarci scrivendo il sorgente sulla carta sicuramente ci sarebbero delle difficoltà di comprensione per quanto riguarda il codice racchiuso dai blocchi con la spaziatura. Ma gli editor che ci sono attualmente li segnalano con una linea tratteggiata verticale, rendendo la vita MOLTO più semplice. Oltre al fatto che, eseguondo la compilazione del sorgente mentre si sta scrivendo, evidenziano subito errori di allineamento delle istruzioni nei blocchi.
Insomma, un linguaggio non lo lascio mai "da solo": oltre alla sintassi per me c'è tanto altro. ;)
Come strumento di programmazione è invece indubitabile che lo sia. Ma ragionerei più in termini di causalità: se faccio così capita cosà. Come dire che ci sono effetti senza significati.
Tieni conto che io ritengo (visione personale) che sia improprio parlare di semantica nell'ambito delle specifiche di un linguaggio di programmazione: le intendo invece come collezioni di effetti, senza arte nè parte.
In quanto programmatore per me ha senso pensare a, pesare e usare entrambe le cose. :) Anzi, io considero anche altro: persino l'uso degli IDE con editor avente syntax highlight può farmi cambiare il modo in cui scrivo il mio codice.
Ad esempio, un paio decenni fa, quando lavoravo con le prime versioni del Turbo Pascal, scrivevo le parole riservate e gli identificatori con l'iniziale maiuscola. Con l'avvento degli editor aventi syntax highlight, ho smesso progressivamente di scrivere le parole riservate in questo modo, lasciando tutto in minuscolo.
Un altro esempio è con Python (sempre lui :D). Molti non lo apprezzano a causa dell'uso che fa dell'indentazione.
Se dovessi lavorarci scrivendo il sorgente sulla carta sicuramente ci sarebbero delle difficoltà di comprensione per quanto riguarda il codice racchiuso dai blocchi con la spaziatura. Ma gli editor che ci sono attualmente li segnalano con una linea tratteggiata verticale, rendendo la vita MOLTO più semplice. Oltre al fatto che, eseguondo la compilazione del sorgente mentre si sta scrivendo, evidenziano subito errori di allineamento delle istruzioni nei blocchi.
Insomma, un linguaggio non lo lascio mai "da solo": oltre alla sintassi per me c'è tanto altro. ;)
thebol
15-05-2006, 16:08
x G|4Di4k. Per tutto. Dai banali script che si mangiano dei file di testo filtrando le informazioni, ai server web, ad applicazioni che manipolano file XML, a server / client SOAP, a server / client Ice, accesso a db con qualche milione di record di utenti, ecc. ecc.
A lavoro uso quasi esclusivamente Python. Il PHP sono costretto a usarlo soltanto per sviluppare dei mini client "dimostrativi" in PHP ai miei colleghi (che usano ancora quest'orribile linguaggio) per accedere ai server Ice che ho scritto in Python. ;)
che roba è un server ICE?
wikipedia e google nn m'hanno aiutato :|(ringrazziando il firewall..)
A lavoro uso quasi esclusivamente Python. Il PHP sono costretto a usarlo soltanto per sviluppare dei mini client "dimostrativi" in PHP ai miei colleghi (che usano ancora quest'orribile linguaggio) per accedere ai server Ice che ho scritto in Python. ;)
che roba è un server ICE?
wikipedia e google nn m'hanno aiutato :|(ringrazziando il firewall..)
cdimauro
15-05-2006, 16:08
Usi qualche ide o vai di "notepad" ?
Uso SPE (Stani's Python Editor), che è abbastanza buono e offre tante cose carine. A parte quelle che ho elencato nel messaggio precedente, permette di tirare fuori un diagramma UML del sorgente e/o la documentazione con un click, controllare più approfonditamente eventuali errori presenti, ecc. ecc. E' pieno di funzionalità. :)
La cosa molto interessante è che ha una console già aperta con l'interprete pronto ad accettare comandi, per cui puoi scrivere al volo del codice e controllarlo, oppure di eseguire la parte di selezionato.
Molto carino.
Come IDE puoi usare anche Eclipse: c'è un plug-in apposta che permette di sfruttare quest'IDE, e permette anche di effettuare qualche forma di rifattorizzazione.
Sembra buono da come me lo descrivi :D
Permette di scrivere programmi molto velocemente, e ha una sintassi bella ed elegante (tutto il contrario di Perl :D).
Per chi vuol farsi 4 risate: http://www.sounerd.com.br/index.php?option=com_content&task=view&id=237&Itemid=43 :D
Uso SPE (Stani's Python Editor), che è abbastanza buono e offre tante cose carine. A parte quelle che ho elencato nel messaggio precedente, permette di tirare fuori un diagramma UML del sorgente e/o la documentazione con un click, controllare più approfonditamente eventuali errori presenti, ecc. ecc. E' pieno di funzionalità. :)
La cosa molto interessante è che ha una console già aperta con l'interprete pronto ad accettare comandi, per cui puoi scrivere al volo del codice e controllarlo, oppure di eseguire la parte di selezionato.
Molto carino.
Come IDE puoi usare anche Eclipse: c'è un plug-in apposta che permette di sfruttare quest'IDE, e permette anche di effettuare qualche forma di rifattorizzazione.
Sembra buono da come me lo descrivi :D
Permette di scrivere programmi molto velocemente, e ha una sintassi bella ed elegante (tutto il contrario di Perl :D).
Per chi vuol farsi 4 risate: http://www.sounerd.com.br/index.php?option=com_content&task=view&id=237&Itemid=43 :D
cdimauro
15-05-2006, 16:10
che roba è un server ICE?
wikipedia e google nn m'hanno aiutato :|(ringrazziando il firewall..)
http://www.zeroc.com/ice.html
Per confronto: http://www.zeroc.com/iceVsCorba.html e http://www.zeroc.com/iceVsSoap.html ;)
wikipedia e google nn m'hanno aiutato :|(ringrazziando il firewall..)
http://www.zeroc.com/ice.html
Per confronto: http://www.zeroc.com/iceVsCorba.html e http://www.zeroc.com/iceVsSoap.html ;)
fek
15-05-2006, 17:08
Mumble mumble. Capisco cosa vuoi dire, ma dipende dai casi. Come programmatori dovremmo conoscere bene gli strumenti che usiamo e non andare oltre il "contratto" che essi mettono a disposizione.
Sappiamo che Java, per sua natura, mette a disposizione un ambiente "safe" (o "managed", che dir si voglia :p).
Da questo punto di vista, il fatto che in Java sia "regolamentato" un caso come quello citato, lo mette sul piano del lecito.
Anche in Python, ad esempio, nell'implementare i generatori si solleva un'eccezione in next() quando non ci sono più elementi; l'eccezione viene intercettata dal sistema e comporta l'uscita dal generatore, in maniera trasparente all'applicazione che lo usava iterando sugli elementi che gli metteva a disposizione.
La situazione è analoga a quella dello scorrimento degli elementi del vettore di cui sopra.
Si tratta di punti di vista leciti, IMHO
Non stiamo discutendo dell'uso o meno di puntatori come interi, di assunzioni sull'endianess o sull'uso dei campi di bit col C.
Non sono d'accordo, Cesare. Usare le eccezioni per gestire situazioni non eccezionali non e' un punto di vista, e' proprio un grave errore concettuale. Qui si parla di uno strumento messo a disposizione dal linguaggio e come usarlo propriamente: se le hanno chiamate eccezioni ci sara' un motivo :)
Esempio che dovrebbe chiarire il discorso:
int z;
if (x == 0)
{
throw new DivideByZero();
}
z = y / x;
oppure:
int z;
if (x == 0)
{
z = max;
}
else
{
z = y / x;
}
Nel primo caso, usando un'eccezione, stai comunicando che 0 non e' un valore valido e non fa' parte del dominio degl'input. Non devi mai ricevere uno 0 in input, se accade, alzi le mani e generi un'eccezione. Nel secondo caso stai invece comunicando che 0 e' un valore valido di input e il risultato della divisione sara' il massimo valore nel dominio dell'output. Quale delle due soluzione e' giusta dipende ovviamente dal problema.
Come vedi l'uso dell'eccezione qui sta comunicando chiaramente alcuni concetti importanti sulle assunzione che il tuo codice fa sull'input che riceve. Nel caso del for, invece, usi lo strumento impropriamente perche' il codice comunica una cosa diversa da quello che sta facendo: l'eccezione out of bound viene generata ad ogni esecuzione, quindi non e' piu' un'eccezione. Gestisci la situazione con gli strumenti propri del linguaggio.
Poi se il ciclo for sara' un collo di bottiglia, sono certo che troverai una soluzione algoritmica al problema ;)
Sappiamo che Java, per sua natura, mette a disposizione un ambiente "safe" (o "managed", che dir si voglia :p).
Da questo punto di vista, il fatto che in Java sia "regolamentato" un caso come quello citato, lo mette sul piano del lecito.
Anche in Python, ad esempio, nell'implementare i generatori si solleva un'eccezione in next() quando non ci sono più elementi; l'eccezione viene intercettata dal sistema e comporta l'uscita dal generatore, in maniera trasparente all'applicazione che lo usava iterando sugli elementi che gli metteva a disposizione.
La situazione è analoga a quella dello scorrimento degli elementi del vettore di cui sopra.
Si tratta di punti di vista leciti, IMHO
Non stiamo discutendo dell'uso o meno di puntatori come interi, di assunzioni sull'endianess o sull'uso dei campi di bit col C.
Non sono d'accordo, Cesare. Usare le eccezioni per gestire situazioni non eccezionali non e' un punto di vista, e' proprio un grave errore concettuale. Qui si parla di uno strumento messo a disposizione dal linguaggio e come usarlo propriamente: se le hanno chiamate eccezioni ci sara' un motivo :)
Esempio che dovrebbe chiarire il discorso:
int z;
if (x == 0)
{
throw new DivideByZero();
}
z = y / x;
oppure:
int z;
if (x == 0)
{
z = max;
}
else
{
z = y / x;
}
Nel primo caso, usando un'eccezione, stai comunicando che 0 non e' un valore valido e non fa' parte del dominio degl'input. Non devi mai ricevere uno 0 in input, se accade, alzi le mani e generi un'eccezione. Nel secondo caso stai invece comunicando che 0 e' un valore valido di input e il risultato della divisione sara' il massimo valore nel dominio dell'output. Quale delle due soluzione e' giusta dipende ovviamente dal problema.
Come vedi l'uso dell'eccezione qui sta comunicando chiaramente alcuni concetti importanti sulle assunzione che il tuo codice fa sull'input che riceve. Nel caso del for, invece, usi lo strumento impropriamente perche' il codice comunica una cosa diversa da quello che sta facendo: l'eccezione out of bound viene generata ad ogni esecuzione, quindi non e' piu' un'eccezione. Gestisci la situazione con gli strumenti propri del linguaggio.
Poi se il ciclo for sara' un collo di bottiglia, sono certo che troverai una soluzione algoritmica al problema ;)
fek
15-05-2006, 17:13
Se dovessimo considerare le eccezioni soltanto... eccezioni :p, allora dovremmo programmare tenendo conto (quasi) esclusivamente della sintassi, e sceglieremmo sempre la forma con l'if has_key. Ma non è così.
Si', considera le eccezioni soltanto come eccezioni :)
E se in Diamonds provi a usare un'eccezione per segnalare una condizione non eccezionale sai che ti faccio alle ditine!
A mio avviso il sistema delle eccezioni che è stato introdotto nei linguaggi da un po' di anni a questa parte non deve servire esclusivamente per segnalare dei casi "anomali": può essere usato anche per pensare e scrivere del codice in maniera diversa.
Totalmente in disaccordo. Un'eccezione e' un'eccezione e la si usa come tale: per segnalare condizioni anomale. Non si abusa mai dei costrutti di un linguaggio. Un martello serve per piantare i chiodi, ma lo puoi anche dare in testa alla gente, ma non e' un uso proprio :D
Si', considera le eccezioni soltanto come eccezioni :)
E se in Diamonds provi a usare un'eccezione per segnalare una condizione non eccezionale sai che ti faccio alle ditine!
A mio avviso il sistema delle eccezioni che è stato introdotto nei linguaggi da un po' di anni a questa parte non deve servire esclusivamente per segnalare dei casi "anomali": può essere usato anche per pensare e scrivere del codice in maniera diversa.
Totalmente in disaccordo. Un'eccezione e' un'eccezione e la si usa come tale: per segnalare condizioni anomale. Non si abusa mai dei costrutti di un linguaggio. Un martello serve per piantare i chiodi, ma lo puoi anche dare in testa alla gente, ma non e' un uso proprio :D
Xalexalex
15-05-2006, 17:23
x G|4Di4k. Per tutto. Dai banali script che si mangiano dei file di testo filtrando le informazioni, ai server web, ad applicazioni che manipolano file XML, a server / client SOAP, a server / client Ice, accesso a db con qualche milione di record di utenti, ecc. ecc.
A lavoro uso quasi esclusivamente Python. Il PHP sono costretto a usarlo soltanto per sviluppare dei mini client "dimostrativi" in PHP ai miei colleghi (che usano ancora quest'orribile linguaggio) per accedere ai server Ice che ho scritto in Python. ;)
Perchè PHP sarebbe così orribile? < - non è una domanda provocatoria...
A lavoro uso quasi esclusivamente Python. Il PHP sono costretto a usarlo soltanto per sviluppare dei mini client "dimostrativi" in PHP ai miei colleghi (che usano ancora quest'orribile linguaggio) per accedere ai server Ice che ho scritto in Python. ;)
Perchè PHP sarebbe così orribile? < - non è una domanda provocatoria...
PGI-Bis
15-05-2006, 17:24
A volte mi chiedo se il progresso della conoscenza umana non sarebbe più semplice se alcune questioni potessero essere risolte con un duello ai venti passi. Tra l'idea che...e l'idea che...la più razionale è...BANG!!!, occhei, la prima.
fek
15-05-2006, 17:29
A volte mi chiedo se il progresso della conoscenza umana non sarebbe più semplice se alcune questioni potessero essere risolte con un duello ai venti passi. Tra l'idea che...e l'idea che...la più razionale è...BANG!!!, occhei, la prima.
:sbonk:
:sbonk:
k0nt3
15-05-2006, 18:51
Quella che hai dato è la definizione di approccio top down.
Divide & conqueror si applica in altri contesti.
la definizione di approccio top down è un altra, io ho dato la definizione di divide&conquer che è abbastanza più generica
Consiglio di vederlo per intero quel filmato, perché:
1) in VB.NET, C#, Delphi, ecc. la stessa cosa si realizza in 1/10 del tempo;
2) si comprende quanto "IDE" come quelli del filmato siano BEN LONTANI dai canoni di comodità e semplicità d'uso degli altri IDE che ho elencato.
Personalmente, quando ho visto aprire il WORDPAD per scrivere il codice per legare la finestrella appena creata, e il PROMPT DEI COMANDI per compilare il tutto e farlo partire, mi sono stropicciato gli occhi e le orecchie ((C) 2006 by Silvio B. ). Poi sono scoppiato in una fragorosa risata...
Veramente, sono ancora fermi ai tempi della clava (informatica). Dovrebbero dare un'occhiata a Delphi 1.0, il primo ambiente RAD creato per Windows, e rendersi conto di quanto devono ancora lavorare per arrivare a qualcosa di appena comparabile...
E stiamo parlando di QT, che non è neppure totalmente "libero", visto che si tratta di un framework proprietario, dotato di doppia licenza (commerciale e GPL).
la smetti di parlare di cose che non conosci?
1) dimostramelo
2) dimostramelo
hai detto aria fino ad adesso
poi si vede che non hai capito bene... (udite udite) perchè qtdesigner si integra alla perfezione in visual studio (e pure in kdevelop su linux) quindi puoi anche non usare il wordpad e la tua fragorosa risata svanisce subito per lasciare il posto alla mia fragorosa risata.
infine QT è libero per fare applicazioni libere quindi hai sbagliato ancora.
Divide & conqueror si applica in altri contesti.
la definizione di approccio top down è un altra, io ho dato la definizione di divide&conquer che è abbastanza più generica
Consiglio di vederlo per intero quel filmato, perché:
1) in VB.NET, C#, Delphi, ecc. la stessa cosa si realizza in 1/10 del tempo;
2) si comprende quanto "IDE" come quelli del filmato siano BEN LONTANI dai canoni di comodità e semplicità d'uso degli altri IDE che ho elencato.
Personalmente, quando ho visto aprire il WORDPAD per scrivere il codice per legare la finestrella appena creata, e il PROMPT DEI COMANDI per compilare il tutto e farlo partire, mi sono stropicciato gli occhi e le orecchie ((C) 2006 by Silvio B. ). Poi sono scoppiato in una fragorosa risata...
Veramente, sono ancora fermi ai tempi della clava (informatica). Dovrebbero dare un'occhiata a Delphi 1.0, il primo ambiente RAD creato per Windows, e rendersi conto di quanto devono ancora lavorare per arrivare a qualcosa di appena comparabile...
E stiamo parlando di QT, che non è neppure totalmente "libero", visto che si tratta di un framework proprietario, dotato di doppia licenza (commerciale e GPL).
la smetti di parlare di cose che non conosci?
1) dimostramelo
2) dimostramelo
hai detto aria fino ad adesso
poi si vede che non hai capito bene... (udite udite) perchè qtdesigner si integra alla perfezione in visual studio (e pure in kdevelop su linux) quindi puoi anche non usare il wordpad e la tua fragorosa risata svanisce subito per lasciare il posto alla mia fragorosa risata.
infine QT è libero per fare applicazioni libere quindi hai sbagliato ancora.
k0nt3
15-05-2006, 18:59
Non la trovo una bella idea... le eccezioni dovrebbero servire per le condizioni eccezionali. Penso che il classico iteratore sia la soluzione piu' semplice e generale, niente controlli sui bound, niente eccezioni da raccogliere (a livello di codice scritto, non di quello eseguito ovviamente).
quoto
EDIT: incredibile sono daccordo con fek :eek: mò vedi che cambia idea :asd:
quoto
EDIT: incredibile sono daccordo con fek :eek: mò vedi che cambia idea :asd:
G|4Di4k
15-05-2006, 20:51
Uso SPE (Stani's Python Editor), che è abbastanza buono e offre tante cose carine. A parte quelle che ho elencato nel messaggio precedente, permette di tirare fuori un diagramma UML del sorgente e/o la documentazione con un click, controllare più approfonditamente eventuali errori presenti, ecc. ecc. E' pieno di funzionalità. :)
La cosa molto interessante è che ha una console già aperta con l'interprete pronto ad accettare comandi, per cui puoi scrivere al volo del codice e controllarlo, oppure di eseguire la parte di selezionato.
Molto carino.
Come IDE puoi usare anche Eclipse: c'è un plug-in apposta che permette di sfruttare quest'IDE, e permette anche di effettuare qualche forma di rifattorizzazione.
Permette di scrivere programmi molto velocemente, e ha una sintassi bella ed elegante (tutto il contrario di Perl :D).
Per chi vuol farsi 4 risate: http://www.sounerd.com.br/index.php?option=com_content&task=view&id=237&Itemid=43 :D
Volo a vedere su google :)
La cosa molto interessante è che ha una console già aperta con l'interprete pronto ad accettare comandi, per cui puoi scrivere al volo del codice e controllarlo, oppure di eseguire la parte di selezionato.
Molto carino.
Come IDE puoi usare anche Eclipse: c'è un plug-in apposta che permette di sfruttare quest'IDE, e permette anche di effettuare qualche forma di rifattorizzazione.
Permette di scrivere programmi molto velocemente, e ha una sintassi bella ed elegante (tutto il contrario di Perl :D).
Per chi vuol farsi 4 risate: http://www.sounerd.com.br/index.php?option=com_content&task=view&id=237&Itemid=43 :D
Volo a vedere su google :)
cdimauro
16-05-2006, 08:19
Non sono d'accordo, Cesare. Usare le eccezioni per gestire situazioni non eccezionali non e' un punto di vista, e' proprio un grave errore concettuale. Qui si parla di uno strumento messo a disposizione dal linguaggio e come usarlo propriamente: se le hanno chiamate eccezioni ci sara' un motivo :)
Esempio che dovrebbe chiarire il discorso:
int z;
if (x == 0)
{
throw new DivideByZero();
}
z = y / x;
oppure:
int z;
if (x == 0)
{
z = max;
}
else
{
z = y / x;
}
Nel primo caso, usando un'eccezione, stai comunicando che 0 non e' un valore valido e non fa' parte del dominio degl'input. Non devi mai ricevere uno 0 in input, se accade, alzi le mani e generi un'eccezione. Nel secondo caso stai invece comunicando che 0 e' un valore valido di input e il risultato della divisione sara' il massimo valore nel dominio dell'output. Quale delle due soluzione e' giusta dipende ovviamente dal problema.
Come vedi l'uso dell'eccezione qui sta comunicando chiaramente alcuni concetti importanti sulle assunzione che il tuo codice fa sull'input che riceve. Nel caso del for, invece, usi lo strumento impropriamente perche' il codice comunica una cosa diversa da quello che sta facendo: l'eccezione out of bound viene generata ad ogni esecuzione, quindi non e' piu' un'eccezione. Gestisci la situazione con gli strumenti propri del linguaggio.
Poi se il ciclo for sara' un collo di bottiglia, sono certo che troverai una soluzione algoritmica al problema ;)
Ho capito. Intendi il linguaggio come forma di comunicazione.
Si', considera le eccezioni soltanto come eccezioni :)
Totalmente in disaccordo. Un'eccezione e' un'eccezione e la si usa come tale: per segnalare condizioni anomale. Non si abusa mai dei costrutti di un linguaggio. Un martello serve per piantare i chiodi, ma lo puoi anche dare in testa alla gente, ma non e' un uso proprio :D
Mi sto prendendo una pausa di riflessione sull'argomento.
E se in Diamonds provi a usare un'eccezione per segnalare una condizione non eccezionale sai che ti faccio alle ditine!
:) Non c'è problema: non è successo prima (fortunatamente :D) e non succederà. ;)
Esempio che dovrebbe chiarire il discorso:
int z;
if (x == 0)
{
throw new DivideByZero();
}
z = y / x;
oppure:
int z;
if (x == 0)
{
z = max;
}
else
{
z = y / x;
}
Nel primo caso, usando un'eccezione, stai comunicando che 0 non e' un valore valido e non fa' parte del dominio degl'input. Non devi mai ricevere uno 0 in input, se accade, alzi le mani e generi un'eccezione. Nel secondo caso stai invece comunicando che 0 e' un valore valido di input e il risultato della divisione sara' il massimo valore nel dominio dell'output. Quale delle due soluzione e' giusta dipende ovviamente dal problema.
Come vedi l'uso dell'eccezione qui sta comunicando chiaramente alcuni concetti importanti sulle assunzione che il tuo codice fa sull'input che riceve. Nel caso del for, invece, usi lo strumento impropriamente perche' il codice comunica una cosa diversa da quello che sta facendo: l'eccezione out of bound viene generata ad ogni esecuzione, quindi non e' piu' un'eccezione. Gestisci la situazione con gli strumenti propri del linguaggio.
Poi se il ciclo for sara' un collo di bottiglia, sono certo che troverai una soluzione algoritmica al problema ;)
Ho capito. Intendi il linguaggio come forma di comunicazione.
Si', considera le eccezioni soltanto come eccezioni :)
Totalmente in disaccordo. Un'eccezione e' un'eccezione e la si usa come tale: per segnalare condizioni anomale. Non si abusa mai dei costrutti di un linguaggio. Un martello serve per piantare i chiodi, ma lo puoi anche dare in testa alla gente, ma non e' un uso proprio :D
Mi sto prendendo una pausa di riflessione sull'argomento.
E se in Diamonds provi a usare un'eccezione per segnalare una condizione non eccezionale sai che ti faccio alle ditine!
:) Non c'è problema: non è successo prima (fortunatamente :D) e non succederà. ;)
cdimauro
16-05-2006, 08:59
Perchè PHP sarebbe così orribile? < - non è una domanda provocatoria...
E' un parere strettamente personale, sia chiaro. :)
Mi sembra una versione del C adattata alla meno peggio per aggiungere delle funzionalità di scripting alle pagine HTML (tant'è che un sorgente PHP è racchiuso in un tag di apertura).
A parte la sintassi, te ne accorgi da alcune caratteristiche: la mancanza di costrutti sintattici per definire delle costanti, l'uso spasmodico di include e require che si rende necessario per "organizzare" il proprio codice (e quindi la totale assenza del concetto di modulo/unit/package; se, ad esempio, hai editato un file e hai introdotto un banale errore di sintassi, te ne accorgi soltanto mentre il codice che lo usa sta girando), debole tipizzazione dei dati (che può facilmente generare problemi), presenza di una notevole quantità di operatori (utili per offuscare ancora di più codice :D), presenza di "puntatori" (dal passaggio di parametri alla definizione e uso delle classi: nella documentazione la parola "puntatore" è largamente presente, e denota la fonte di "ispirazione" della definizione del linguaggio).
Per quanto riguarda altre caratteristiche proprie del linguaggio PHP (che non trovo gradevoli), cito il "miscuglio" che permette di realizzare fra dati e codice (espressioni contenute in stringhe, identificatori che "diventano" stringhe e viceversa), dichiarazioni di stringhe che si comportano in maniera troppo diversa (escape), il tipo stringa che utilizza operatori appositi, il tipo array che funge da gran "calderone" in cui infilare tutto (permette di definire sequenze e dizionari), variabili che possono essere usate senza che sia stato assegnato loro un valore (il che porta a non pochi bug nel codice: è forse la fonte più comune di problemi), scoping delle variabili abbastanza diverso dai "canoni", callback di funzioni abbastanza rozzo (bisogna chiamare la funzione call_user_func), definizione di funzioni con parametri predefiniti assolutamente ridicola (possono essere inseriti prima di parametri obbligatori!), commenti sulla singola linea definiti in modo diverso.
E per fortuna che con PHP5 sono state introdotte diverse migliorie, come ad esempio il fatto che l'assegnazione fra istanze di classe comporta la copia del riferimento (e non la copia di tutti gli attributi, come avveniva prima), l'introduzione delle interfacce e delle eccezioni, perché altrimenti il quadro sarebbe stato ancora più desolante.
Sembra che il linguaggio si sia evoluto nel tempo infilandogli quello che serviva al momento, senza una "visione d'insieme".
Questa è la mia impressione, ripeto, e lo noto anche lavorando nel campo per cui è nato il PHP, la generazione di pagine web: con Python e il relativo mod_python il codice per realizzare la stesse cose è più compatto ma soprattutto MOLTO più leggibile (specialmente quando devo interfacciarmi coi database per recuperare valori o effettuare modifiche), e differisce ben poco da come scrivo codice per altro tipo di applicazioni.
E' un parere strettamente personale, sia chiaro. :)
Mi sembra una versione del C adattata alla meno peggio per aggiungere delle funzionalità di scripting alle pagine HTML (tant'è che un sorgente PHP è racchiuso in un tag di apertura).
A parte la sintassi, te ne accorgi da alcune caratteristiche: la mancanza di costrutti sintattici per definire delle costanti, l'uso spasmodico di include e require che si rende necessario per "organizzare" il proprio codice (e quindi la totale assenza del concetto di modulo/unit/package; se, ad esempio, hai editato un file e hai introdotto un banale errore di sintassi, te ne accorgi soltanto mentre il codice che lo usa sta girando), debole tipizzazione dei dati (che può facilmente generare problemi), presenza di una notevole quantità di operatori (utili per offuscare ancora di più codice :D), presenza di "puntatori" (dal passaggio di parametri alla definizione e uso delle classi: nella documentazione la parola "puntatore" è largamente presente, e denota la fonte di "ispirazione" della definizione del linguaggio).
Per quanto riguarda altre caratteristiche proprie del linguaggio PHP (che non trovo gradevoli), cito il "miscuglio" che permette di realizzare fra dati e codice (espressioni contenute in stringhe, identificatori che "diventano" stringhe e viceversa), dichiarazioni di stringhe che si comportano in maniera troppo diversa (escape), il tipo stringa che utilizza operatori appositi, il tipo array che funge da gran "calderone" in cui infilare tutto (permette di definire sequenze e dizionari), variabili che possono essere usate senza che sia stato assegnato loro un valore (il che porta a non pochi bug nel codice: è forse la fonte più comune di problemi), scoping delle variabili abbastanza diverso dai "canoni", callback di funzioni abbastanza rozzo (bisogna chiamare la funzione call_user_func), definizione di funzioni con parametri predefiniti assolutamente ridicola (possono essere inseriti prima di parametri obbligatori!), commenti sulla singola linea definiti in modo diverso.
E per fortuna che con PHP5 sono state introdotte diverse migliorie, come ad esempio il fatto che l'assegnazione fra istanze di classe comporta la copia del riferimento (e non la copia di tutti gli attributi, come avveniva prima), l'introduzione delle interfacce e delle eccezioni, perché altrimenti il quadro sarebbe stato ancora più desolante.
Sembra che il linguaggio si sia evoluto nel tempo infilandogli quello che serviva al momento, senza una "visione d'insieme".
Questa è la mia impressione, ripeto, e lo noto anche lavorando nel campo per cui è nato il PHP, la generazione di pagine web: con Python e il relativo mod_python il codice per realizzare la stesse cose è più compatto ma soprattutto MOLTO più leggibile (specialmente quando devo interfacciarmi coi database per recuperare valori o effettuare modifiche), e differisce ben poco da come scrivo codice per altro tipo di applicazioni.
fek
16-05-2006, 10:28
la smetti di parlare di cose che non conosci?
1) dimostramelo
2) dimostramelo
hai detto aria fino ad adesso
Fra te e Cesare, quello che spesso e volentieri parla di cose che non conosce non e' Cesare. Gli esempi sono molteplici.
1) dimostramelo
2) dimostramelo
hai detto aria fino ad adesso
Fra te e Cesare, quello che spesso e volentieri parla di cose che non conosce non e' Cesare. Gli esempi sono molteplici.
cdimauro
16-05-2006, 10:33
Preferisco non rispondergli: tanto è tutto tempo perso, come al solito.
k0nt3
16-05-2006, 15:51
Fra te e Cesare, quello che spesso e volentieri parla di cose che non conosce non e' Cesare. Gli esempi sono molteplici.
in questo caso io conosco qtdesigner e lui no.
in questo caso io conosco qtdesigner e lui no.
sirus
16-05-2006, 19:50
So benissimo di arrivare in ritardo ma ora mi inserisco.
Io ho cominciato a fare le prime "ca22ate" a 13 anni con il Pascal sotto MS-DOS :cool: e con il Pascal ho conosciuto tutti i costrutti fondamentali di un linguaggio di programmazione, l'ho usato anche in prima e seconda superiore e poi in terza superiore sono passato al C.
Il primo libro su cui ho studiato il C è stato il K&R quindi credo di aver imparato il meglio ed il peggio del C infatti un po' tutti i miei professori mi hanno sempre criticato per come usavo il C e soprattutto per l'uso spropositato che facevo dei puntatori anche non proprio in manierà didattica :D ...
Poi ho cominciato con il C++ e dopo qualche iniziale problema di comprensione del concetto di classe, oggetto e tutto ciò che ne consegue (dovuto alla mia radicata mentalità fortemente basata sul C e sulla programmazione imperativa - per la cronaca adoro l'Assembly ;)) ho capito che era la via migliore! Prima di "imparare" (non si finisce mai) il C++ ho tentato anche con il Java ma i miei tentativi sono miseramente falliti, non è che non lo sappia usare è che proprio non lo soffro rispetto al C++...
Ora come ora se dovessi buttarmi su un nuovo linguaggio (il Java tutto sommato sarebbe nuovo per me) sceglierei sicuramente il C# che si dice abbia tutti i vantaggi di Java e C++ coniugati ;)
Nello stage della quarta superiore per vari motivi pensai ad un array di puntatori a funzione (non conoscevo ancora la programmazione OBJ Oriented), ho lavorato ad un progetto di una linea di produzione che coniugava PC e PLC (B&R) e si usava rigorosamente il C, quindi e dato che non disponevo degli strumenti messi a disposizione dai linguaggi ad oggetti mi sono adattato ad una soluzione che sinceramente trovo molto molto elegante quindi in fin dei conti un programmatore si arrangia con qualsiasi linguaggio di programmazione...
;)
Se si tratta proprio di imparare a programmare sarebbe più interesante pensare ad un linguaggio non prettamente di programmazione ma anche un semplice meta-linguaggio :O
Io ho cominciato a fare le prime "ca22ate" a 13 anni con il Pascal sotto MS-DOS :cool: e con il Pascal ho conosciuto tutti i costrutti fondamentali di un linguaggio di programmazione, l'ho usato anche in prima e seconda superiore e poi in terza superiore sono passato al C.
Il primo libro su cui ho studiato il C è stato il K&R quindi credo di aver imparato il meglio ed il peggio del C infatti un po' tutti i miei professori mi hanno sempre criticato per come usavo il C e soprattutto per l'uso spropositato che facevo dei puntatori anche non proprio in manierà didattica :D ...
Poi ho cominciato con il C++ e dopo qualche iniziale problema di comprensione del concetto di classe, oggetto e tutto ciò che ne consegue (dovuto alla mia radicata mentalità fortemente basata sul C e sulla programmazione imperativa - per la cronaca adoro l'Assembly ;)) ho capito che era la via migliore! Prima di "imparare" (non si finisce mai) il C++ ho tentato anche con il Java ma i miei tentativi sono miseramente falliti, non è che non lo sappia usare è che proprio non lo soffro rispetto al C++...
Ora come ora se dovessi buttarmi su un nuovo linguaggio (il Java tutto sommato sarebbe nuovo per me) sceglierei sicuramente il C# che si dice abbia tutti i vantaggi di Java e C++ coniugati ;)
Nello stage della quarta superiore per vari motivi pensai ad un array di puntatori a funzione (non conoscevo ancora la programmazione OBJ Oriented), ho lavorato ad un progetto di una linea di produzione che coniugava PC e PLC (B&R) e si usava rigorosamente il C, quindi e dato che non disponevo degli strumenti messi a disposizione dai linguaggi ad oggetti mi sono adattato ad una soluzione che sinceramente trovo molto molto elegante quindi in fin dei conti un programmatore si arrangia con qualsiasi linguaggio di programmazione...
;)
Se si tratta proprio di imparare a programmare sarebbe più interesante pensare ad un linguaggio non prettamente di programmazione ma anche un semplice meta-linguaggio :O
cdimauro
17-05-2006, 08:34
Python, insomma. :p
vBulletin® v3.6.4, Copyright ©2000-2026, Jelsoft Enterprises Ltd.