LittleDeveloper
08-04-2010, 20:06
Ciao ho deciso di iniziare a programmare utilizzando questo linguaggio voi che ne pensate?? Faccio bene o no?
View Full Version : [c] Iniziare a programmare con il linguaggio C
lupoxxx87
08-04-2010, 20:17
ehm...si......lo spirito è quello giusto..il linguaggio va bene....ma sappi che servono anche le basi teoriche..
LittleDeveloper
08-04-2010, 20:18
ehm...si......lo spirito è quello giusto..il linguaggio va bene....ma sappi che servono anche le basi teoriche..
E le ho le basi teoriche ora comincio a studiare se ho problemi questo forum mi sembra proprio stupendo!! Posti qualcosa e dopo 2 dico 2 secondi arrivano subito risposte!!! Troppo bello!!
E le ho le basi teoriche ora comincio a studiare se ho problemi questo forum mi sembra proprio stupendo!! Posti qualcosa e dopo 2 dico 2 secondi arrivano subito risposte!!! Troppo bello!!
GByTe87
08-04-2010, 21:15
Se ne è parlato spesso, ed il C non è il massimo per iniziare a programmare, in quanto, se vogliamo, troppo di "basso livello". :D
Io ti consiglierei Python, è molto più immediato per avvicinarsi alla programmazione.
Dopo potrai cominciare a combattere con i sigsegv del c :asd:
Dai un occhio a questo 3d: http://www.hwupgrade.it/forum/showthread.php?t=1979444
Io ti consiglierei Python, è molto più immediato per avvicinarsi alla programmazione.
Dopo potrai cominciare a combattere con i sigsegv del c :asd:
Dai un occhio a questo 3d: http://www.hwupgrade.it/forum/showthread.php?t=1979444
fero86
08-04-2010, 22:15
Dopo potrai cominciare a combattere con i sigsegv del c :asd: o le access violations :O
PGI-Bis
09-04-2010, 00:41
:D Non facciamo i furbi! Ha chiesto informazioni su un linguaggio specifico. Se volete consigliare alternative scrivete la litanìa nel thread ufficiale
http://www.hwupgrade.it/forum/showthread.php?t=1979444
http://www.hwupgrade.it/forum/showthread.php?t=1979444
^TiGeRShArK^
09-04-2010, 08:26
:D Non facciamo i furbi! Ha chiesto informazioni su un linguaggio specifico. Se volete consigliare alternative scrivete la litanìa nel thread ufficiale
http://www.hwupgrade.it/forum/showthread.php?t=1979444
:mbe:
Ciao ho deciso di iniziare a programmare utilizzando questo linguaggio voi che ne pensate?? Faccio bene o no?
Per me non fa assolutamente bene. :O
Di peggio poteva scegliere solo l'assembly e il linguaggio macchina.
Anzi no.
Magari con quelli avrebbe imparato qualcosa su come funzionano i processori.
http://www.hwupgrade.it/forum/showthread.php?t=1979444
:mbe:
Ciao ho deciso di iniziare a programmare utilizzando questo linguaggio voi che ne pensate?? Faccio bene o no?
Per me non fa assolutamente bene. :O
Di peggio poteva scegliere solo l'assembly e il linguaggio macchina.
Anzi no.
Magari con quelli avrebbe imparato qualcosa su come funzionano i processori.
WarDuck
09-04-2010, 08:31
Io comincierei da Java, dato che:
a) è cmq il più usato
b) non è difficile
c) è una "via di mezzo"
:D
Ma soprattutto IMHO la documentazione è fatta meglio rispetto ad altri linguaggi.
Ci sarebbe anche C# volendo, ma IMHO per iniziare è meglio Java.
a) è cmq il più usato
b) non è difficile
c) è una "via di mezzo"
:D
Ma soprattutto IMHO la documentazione è fatta meglio rispetto ad altri linguaggi.
Ci sarebbe anche C# volendo, ma IMHO per iniziare è meglio Java.
darkito85
09-04-2010, 08:51
Beh non sono d'accordo con chi sconsiglia di iniziare dal C. Tutto dipende dalla voglia e dalle proprie basi. Io ho iniziato con il C e da li mi sono spostato verso gli altri. Tutto sta dalle proprie abilità. Io gli consiglio di provare ad iniziare dal C, se gli risulta troppo complicato allora migrare verso linguaggi,magari di scripting, come python o php,o dare un occhiata al Vbasic ed il Java la cui documentazione è ampiamente disponibile anche in rete.
WarDuck
09-04-2010, 09:24
Beh non sono d'accordo con chi sconsiglia di iniziare dal C. Tutto dipende dalla voglia e dalle proprie basi. Io ho iniziato con il C e da li mi sono spostato verso gli altri. Tutto sta dalle proprie abilità. Io gli consiglio di provare ad iniziare dal C, se gli risulta troppo complicato allora migrare verso linguaggi,magari di scripting, come python o php,o dare un occhiata al Vbasic ed il Java la cui documentazione è ampiamente disponibile anche in rete.
Le abilità si costruiscono man mano, del resto se non ha mai programmato l'abilità non c'entra niente (programmare è un conto, risolvere un problema è un'altra cosa).
E' una questione di forma-mentis, se vedi il linguaggio di programmazione come strumento allora sceglierai lo strumento più adatto a risolvere un dato problema.
Il suo scopo è imparare, imparare a programmare non significa conoscere solo la sintassi del linguaggio (cosa che di per se non serve a nulla), imparare a programmare significa anche affrontare i problemi in un certo modo, ed in tal senso è meglio usare un linguaggio che ti permetta di mettere al centro i problemi piuttosto che la sintassi.
Le abilità si costruiscono man mano, del resto se non ha mai programmato l'abilità non c'entra niente (programmare è un conto, risolvere un problema è un'altra cosa).
E' una questione di forma-mentis, se vedi il linguaggio di programmazione come strumento allora sceglierai lo strumento più adatto a risolvere un dato problema.
Il suo scopo è imparare, imparare a programmare non significa conoscere solo la sintassi del linguaggio (cosa che di per se non serve a nulla), imparare a programmare significa anche affrontare i problemi in un certo modo, ed in tal senso è meglio usare un linguaggio che ti permetta di mettere al centro i problemi piuttosto che la sintassi.
Teo@Unix
09-04-2010, 10:41
Il suo scopo è imparare, imparare a programmare non significa conoscere solo la sintassi del linguaggio (cosa che di per se non serve a nulla), imparare a programmare significa anche affrontare i problemi in un certo modo, ed in tal senso è meglio usare un linguaggio che ti permetta di mettere al centro i problemi piuttosto che la sintassi.
Condivido.
Io consiglio C anche se come giustamente ti hanno detto è più faticoso.
Però a mio avviso se dovrai poi andare verso l'alto sarà più facile, più piacevole e sarà un passaggio più naturale di quello contrario.
Fermo restando che la scelta è tua e dipende sempre da quello che vuoi fare e quello che ti conviene usare.
Se devi imparare a programmare credo non sia il caso di intestardirsi da subito con un linguaggio in particolare, leggiti qualcosa sulla teoria degli algoritmi in modo da capire l'approccio mentale da mantenere quando vuoi fare qualcosa utilizzando un computer, se non lo hai già fatto ...
Condivido.
Io consiglio C anche se come giustamente ti hanno detto è più faticoso.
Però a mio avviso se dovrai poi andare verso l'alto sarà più facile, più piacevole e sarà un passaggio più naturale di quello contrario.
Fermo restando che la scelta è tua e dipende sempre da quello che vuoi fare e quello che ti conviene usare.
Se devi imparare a programmare credo non sia il caso di intestardirsi da subito con un linguaggio in particolare, leggiti qualcosa sulla teoria degli algoritmi in modo da capire l'approccio mentale da mantenere quando vuoi fare qualcosa utilizzando un computer, se non lo hai già fatto ...
lupoxxx87
09-04-2010, 12:37
Il suo scopo è imparare, imparare a programmare non significa conoscere solo la sintassi del linguaggio (cosa che di per se non serve a nulla), imparare a programmare significa anche affrontare i problemi in un certo modo, ed in tal senso è meglio usare un linguaggio che ti permetta di mettere al centro i problemi piuttosto che la sintassi.
quello che intendevo con "le basi teoriche"
quello che intendevo con "le basi teoriche"
^TiGeRShArK^
09-04-2010, 13:28
discorso trito e ritrito.
1) Col C non puo' sviluppare programmi multi-piattaforma come da sua richiesta
2) Imparando il C si entra nell'ottica procedurale quindi dovra' DIS-imparare il C per poi poter imparare la programmazione ad oggetti.
E infatti molti ancora oggi programmano in maniera procedurale anche in linguaggi orientati agli oggetti proprio perche' hanno iniziato a programmare scrivendo codice procedurale.
1) Col C non puo' sviluppare programmi multi-piattaforma come da sua richiesta
2) Imparando il C si entra nell'ottica procedurale quindi dovra' DIS-imparare il C per poi poter imparare la programmazione ad oggetti.
E infatti molti ancora oggi programmano in maniera procedurale anche in linguaggi orientati agli oggetti proprio perche' hanno iniziato a programmare scrivendo codice procedurale.
pequeno
09-04-2010, 20:14
Beh, considerando che inizia ora "l'avventura", farebbe bene ad iniziare con Python, poichè probabilmente ha una curva di apprendimento più bassa rispetto a linguaggi più ostici come il C.
2) Imparando il C si entra nell'ottica procedurale quindi dovra' DIS-imparare il C per poi poter imparare la programmazione ad oggetti.
E infatti molti ancora oggi programmano in maniera procedurale anche in linguaggi orientati agli oggetti proprio perche' hanno iniziato a programmare scrivendo codice procedurale.
Su questo concordo.
E' vero che le singole parti di un programma a oggetti richiedono comunque una programmazione "procedurale".. i costrutti alla fine son quelli.. ma fare il passaggio dalla programmazione procedurale a quella ad oggetti diventa arduo, quando ci si è abituati mentalmente a quel tipo di ragionamento.
In definitiva direi Python - che non è meramente un linguaggio di scripting come molti ancora si ostinano a sostenere - o Java che ha l'ulteriore vantaggio della diffusione a livello lavorativo.
2) Imparando il C si entra nell'ottica procedurale quindi dovra' DIS-imparare il C per poi poter imparare la programmazione ad oggetti.
E infatti molti ancora oggi programmano in maniera procedurale anche in linguaggi orientati agli oggetti proprio perche' hanno iniziato a programmare scrivendo codice procedurale.
Su questo concordo.
E' vero che le singole parti di un programma a oggetti richiedono comunque una programmazione "procedurale".. i costrutti alla fine son quelli.. ma fare il passaggio dalla programmazione procedurale a quella ad oggetti diventa arduo, quando ci si è abituati mentalmente a quel tipo di ragionamento.
In definitiva direi Python - che non è meramente un linguaggio di scripting come molti ancora si ostinano a sostenere - o Java che ha l'ulteriore vantaggio della diffusione a livello lavorativo.
^TiGeRShArK^
09-04-2010, 22:08
Nel thread che era stato chiuso aveva specificato anche che vuole creare programmi standalone multi-piattaforma.
Va bene che python è un'ottimo linguaggio per imparare a programmare, e gliel'avrei consigliato anch'io, ma se vuole creare programmi con un'interfaccia grafica quando ne sarà in grado netbeans è sicuramente superiore a python.
Va bene che python è un'ottimo linguaggio per imparare a programmare, e gliel'avrei consigliato anch'io, ma se vuole creare programmi con un'interfaccia grafica quando ne sarà in grado netbeans è sicuramente superiore a python.
clockover
10-04-2010, 12:07
Ciao ho deciso di iniziare a programmare utilizzando questo linguaggio voi che ne pensate?? Faccio bene o no?
daglie dentro col C....
daglie dentro col C....
fero86
10-04-2010, 15:12
Beh, considerando che inizia ora "l'avventura", farebbe bene ad iniziare con Python, poichè probabilmente ha una curva di apprendimento più bassa rispetto a linguaggi più ostici come il C. veramente il C é molto piu semplice di Python; basti pensare che offre solo il paradigma procedurale, mentre Python li offre tutti.
E' vero che le singole parti di un programma a oggetti richiedono comunque una programmazione "procedurale".. i costrutti alla fine son quelli.. ma fare il passaggio dalla programmazione procedurale a quella ad oggetti diventa arduo, quando ci si è abituati mentalmente a quel tipo di ragionamento. se é per questo é molto piu arduo fare il passaggio alla programmazione funzionale e programmare senza side-effects, ma che dire, in qualche modo si fa. la programmazione funzionale poi di recente sta acquistando molta importanza visto il trend della parallelizzazione, quindi perché non iniziare con F#?
Va bene che python è un'ottimo linguaggio per imparare a programmare, e gliel'avrei consigliato anch'io, ma se vuole creare programmi con un'interfaccia grafica quando ne sarà in grado netbeans è sicuramente superiore a python. NetBeans non é un linguaggio... :mbe:
E' vero che le singole parti di un programma a oggetti richiedono comunque una programmazione "procedurale".. i costrutti alla fine son quelli.. ma fare il passaggio dalla programmazione procedurale a quella ad oggetti diventa arduo, quando ci si è abituati mentalmente a quel tipo di ragionamento. se é per questo é molto piu arduo fare il passaggio alla programmazione funzionale e programmare senza side-effects, ma che dire, in qualche modo si fa. la programmazione funzionale poi di recente sta acquistando molta importanza visto il trend della parallelizzazione, quindi perché non iniziare con F#?
Va bene che python è un'ottimo linguaggio per imparare a programmare, e gliel'avrei consigliato anch'io, ma se vuole creare programmi con un'interfaccia grafica quando ne sarà in grado netbeans è sicuramente superiore a python. NetBeans non é un linguaggio... :mbe:
cdimauro
10-04-2010, 16:35
veramente il C é molto piu semplice di Python; basti pensare che offre solo il paradigma procedurale, mentre Python li offre tutti.
Ma la stessa programmazione procedurale in Python è di gran lunga più semplice che in C. E soprattutto non ti provoca mal di testa a colpi di segmentation fault, double delete, bug intermittenti, ecc. :cool:
NetBeans non é un linguaggio... :mbe:
Vabbé, si capiva dai. Lo intendeva come strumenti a disposizione (per quel linguaggio) per realizzare GUI.
Ma la stessa programmazione procedurale in Python è di gran lunga più semplice che in C. E soprattutto non ti provoca mal di testa a colpi di segmentation fault, double delete, bug intermittenti, ecc. :cool:
NetBeans non é un linguaggio... :mbe:
Vabbé, si capiva dai. Lo intendeva come strumenti a disposizione (per quel linguaggio) per realizzare GUI.
^TiGeRShArK^
10-04-2010, 18:37
veramente il C é molto piu semplice di Python; basti pensare che offre solo il paradigma procedurale, mentre Python li offre tutti.
si, e io sono topo gigio. :doh:
il C è molto + complesso e inoltre ti insegna a pensare secondo il paradigma procedurale che ad oggi è il MALE.
Se vuoi imparare a programmare in maniera procedurale puoi anche usare il C, ma non ne vedo l'utilità sia perchè ci sono linguaggi procedurali + semplici, sia perchè è perfettamente inutile imparare la programmazione procedurale.
Giusto due settimane fa ne abbiamo scartato uno perchè durante il pair-programming per l'interview si vedeva che programmava e pensava secondo il paradigma procedurale.
Una persona del genere in un team odierno può solo fare danni.
se é per questo é molto piu arduo fare il passaggio alla programmazione funzionale e programmare senza side-effects, ma che dire, in qualche modo si fa. la programmazione funzionale poi di recente sta acquistando molta importanza visto il trend della parallelizzazione, quindi perché non iniziare con F#?
Se è per questo potrebbe iniziare con C# che offre LINQ che sfrutta decisamente bene la programmazione funzionale.
Ma è contro le sue richieste dato che aveva esplicitamente richiesto un linguaggio multi-piattaforma da usare su linux, mac e windows.
Inoltre nel mercato odierno del lavoro la programmazione ad oggetti la fa da padrone, non si scappa.
In futuro si vedrà.
NetBeans non é un linguaggio... :mbe:
:doh:
Mi pareva fosse chiaro il concetto, avevo già consigliato java, ho spiegato che con java puoi ottenere con poca fatica interfacce grafiche di tutto rispetto con netbeans.
si, e io sono topo gigio. :doh:
il C è molto + complesso e inoltre ti insegna a pensare secondo il paradigma procedurale che ad oggi è il MALE.
Se vuoi imparare a programmare in maniera procedurale puoi anche usare il C, ma non ne vedo l'utilità sia perchè ci sono linguaggi procedurali + semplici, sia perchè è perfettamente inutile imparare la programmazione procedurale.
Giusto due settimane fa ne abbiamo scartato uno perchè durante il pair-programming per l'interview si vedeva che programmava e pensava secondo il paradigma procedurale.
Una persona del genere in un team odierno può solo fare danni.
se é per questo é molto piu arduo fare il passaggio alla programmazione funzionale e programmare senza side-effects, ma che dire, in qualche modo si fa. la programmazione funzionale poi di recente sta acquistando molta importanza visto il trend della parallelizzazione, quindi perché non iniziare con F#?
Se è per questo potrebbe iniziare con C# che offre LINQ che sfrutta decisamente bene la programmazione funzionale.
Ma è contro le sue richieste dato che aveva esplicitamente richiesto un linguaggio multi-piattaforma da usare su linux, mac e windows.
Inoltre nel mercato odierno del lavoro la programmazione ad oggetti la fa da padrone, non si scappa.
In futuro si vedrà.
NetBeans non é un linguaggio... :mbe:
:doh:
Mi pareva fosse chiaro il concetto, avevo già consigliato java, ho spiegato che con java puoi ottenere con poca fatica interfacce grafiche di tutto rispetto con netbeans.
fero86
11-04-2010, 01:39
si, e io sono topo gigio. :doh:
il C è molto + complesso io la mia dimostrazione te l'ho data, da te invece leggo solo un'affermazione non giustificata.
del C si puó dire tutto: che é vecchio, che é improduttivo, che offre pochissimi strumenti nelle librerie predefinite, che le specifiche lasciano indefiniti diversi comportamenti e causano potenziali problemi di sicurezza, che come linguaggio ha tutti i difetti dell'universo piu uno, ma dire che sia piu complesso di Python é ridicolo. secondo me anche la sua semplicitá va annoverata tra i suoi difetti: é un linguaggio che offre troppo pochi strumenti anche sul piano dei costrutti, nel 2010 non si puó essere produttivi con if, switch, for, do, while, struct e funzioni.
e inoltre ti insegna a pensare secondo il paradigma procedurale che ad oggi è il MALE. vorresti farmi credere che non usi mai la composizione sequenziale quando programmi? che i metodi dei tuoi oggetti hanno solo un'istruzione?
usare il paradigma procedurale é inevitabile in molti linguaggi, tra cui anche Java (per C# il discorso sarebbe diverso ma la stragrande maggioranza delle volte lo si usa quasi come Java). il punto del discorso é un altro: il paradigma procedurale da solo é troppo povero, la programmazione a oggetti lo arricchisce permettendo di essere piu produttivi.
Giusto due settimane fa ne abbiamo scartato uno perchè durante il pair-programming per l'interview si vedeva che programmava e pensava secondo il paradigma procedurale.
Una persona del genere in un team odierno può solo fare danni. e posso chiedere come si presentava la sua carriera accademica o ci sono questioni di privacy? perché (posto che non conosco bene il sistema di studi delle vostre parti) se mi dici che si é preso una laurea breve in 10 anni e con un voto mediocre direi che non é il paradigma procedurale il motivo per cui l'avete scartato.
Se è per questo potrebbe iniziare con C# che offre LINQ che sfrutta decisamente bene la programmazione funzionale. LINQ da solo non basta a rendere C# un linguaggio funzionale.
Ma è contro le sue richieste dato che aveva esplicitamente richiesto un linguaggio multi-piattaforma da usare su linux, mac e windows. hai ragione, confido sempre troppo in Mono :D
comunque Mac ha Rotor.
Inoltre nel mercato odierno del lavoro la programmazione ad oggetti la fa da padrone, non si scappa. F# é a oggetti, comunque anche il paradigma funzionale é molto importante: i programmi puramente funzionali sono rientranti e i programmi rientranti sono automaticamente parallelizzabili.
il C è molto + complesso io la mia dimostrazione te l'ho data, da te invece leggo solo un'affermazione non giustificata.
del C si puó dire tutto: che é vecchio, che é improduttivo, che offre pochissimi strumenti nelle librerie predefinite, che le specifiche lasciano indefiniti diversi comportamenti e causano potenziali problemi di sicurezza, che come linguaggio ha tutti i difetti dell'universo piu uno, ma dire che sia piu complesso di Python é ridicolo. secondo me anche la sua semplicitá va annoverata tra i suoi difetti: é un linguaggio che offre troppo pochi strumenti anche sul piano dei costrutti, nel 2010 non si puó essere produttivi con if, switch, for, do, while, struct e funzioni.
e inoltre ti insegna a pensare secondo il paradigma procedurale che ad oggi è il MALE. vorresti farmi credere che non usi mai la composizione sequenziale quando programmi? che i metodi dei tuoi oggetti hanno solo un'istruzione?
usare il paradigma procedurale é inevitabile in molti linguaggi, tra cui anche Java (per C# il discorso sarebbe diverso ma la stragrande maggioranza delle volte lo si usa quasi come Java). il punto del discorso é un altro: il paradigma procedurale da solo é troppo povero, la programmazione a oggetti lo arricchisce permettendo di essere piu produttivi.
Giusto due settimane fa ne abbiamo scartato uno perchè durante il pair-programming per l'interview si vedeva che programmava e pensava secondo il paradigma procedurale.
Una persona del genere in un team odierno può solo fare danni. e posso chiedere come si presentava la sua carriera accademica o ci sono questioni di privacy? perché (posto che non conosco bene il sistema di studi delle vostre parti) se mi dici che si é preso una laurea breve in 10 anni e con un voto mediocre direi che non é il paradigma procedurale il motivo per cui l'avete scartato.
Se è per questo potrebbe iniziare con C# che offre LINQ che sfrutta decisamente bene la programmazione funzionale. LINQ da solo non basta a rendere C# un linguaggio funzionale.
Ma è contro le sue richieste dato che aveva esplicitamente richiesto un linguaggio multi-piattaforma da usare su linux, mac e windows. hai ragione, confido sempre troppo in Mono :D
comunque Mac ha Rotor.
Inoltre nel mercato odierno del lavoro la programmazione ad oggetti la fa da padrone, non si scappa. F# é a oggetti, comunque anche il paradigma funzionale é molto importante: i programmi puramente funzionali sono rientranti e i programmi rientranti sono automaticamente parallelizzabili.
Damage92
11-04-2010, 08:36
Ma la stessa programmazione procedurale in Python è di gran lunga più semplice che in C. E soprattutto non ti provoca mal di testa a colpi di segmentation fault, double delete, bug intermittenti, ecc. :cool:
C'è una cosa che non capisco...
Io ho cominciato con il visual basic 6 su windows, poi ho studiato su un libro di C su linux, e ho intenzione di imparare il C++...
Ora, è vero che con il C vieni seppellito da "segmentation fault, double delete, bug intermittenti", ma per imparare, non è questo quello che serve?
Faccio un paragone:
Se voglio diventare meccanico, non prendo un motore già fatto e lo metto nell'auto per farla camminare, perché così saprò fare andare l'auto, ma non avrò bene capito come funziona (che poi è il mio obbiettivo primario, no?).
Se invece assemblo io il motore, magari funzionerà male, ma avrò capito bene quali problemi ci sono dietro, e quindi come fa a funzionare!
Poi è ovvio che una volta imparato il C è meglio studiare anche altri linguaggi (python, C++...), ma con il C puoi capire come funziona il "motore"! Qualcuno ha citato l'assembler: sarebbe quello il punto da dove iniziare! Se capisci come funziona la macchina ad un livello così basso, poi potrai usare bene gli strumenti più potenti.
Per questo, nella mia "newbaggine", consiglio a LittleDeveloper il C per iniziare (ma solo piccole dosi a volta :D).
Magari insieme ad un buon libro (o prof, magari ad averne uno bravo!).
C'è qualcosa che non va nel mio ragionamento?
C'è una cosa che non capisco...
Io ho cominciato con il visual basic 6 su windows, poi ho studiato su un libro di C su linux, e ho intenzione di imparare il C++...
Ora, è vero che con il C vieni seppellito da "segmentation fault, double delete, bug intermittenti", ma per imparare, non è questo quello che serve?
Faccio un paragone:
Se voglio diventare meccanico, non prendo un motore già fatto e lo metto nell'auto per farla camminare, perché così saprò fare andare l'auto, ma non avrò bene capito come funziona (che poi è il mio obbiettivo primario, no?).
Se invece assemblo io il motore, magari funzionerà male, ma avrò capito bene quali problemi ci sono dietro, e quindi come fa a funzionare!
Poi è ovvio che una volta imparato il C è meglio studiare anche altri linguaggi (python, C++...), ma con il C puoi capire come funziona il "motore"! Qualcuno ha citato l'assembler: sarebbe quello il punto da dove iniziare! Se capisci come funziona la macchina ad un livello così basso, poi potrai usare bene gli strumenti più potenti.
Per questo, nella mia "newbaggine", consiglio a LittleDeveloper il C per iniziare (ma solo piccole dosi a volta :D).
Magari insieme ad un buon libro (o prof, magari ad averne uno bravo!).
C'è qualcosa che non va nel mio ragionamento?
rеpne scasb
11-04-2010, 08:55
■
^TiGeRShArK^
11-04-2010, 09:45
io la mia dimostrazione te l'ho data, da te invece leggo solo un'affermazione non giustificata.
del C si puó dire tutto: che é vecchio, che é improduttivo, che offre pochissimi strumenti nelle librerie predefinite, che le specifiche lasciano indefiniti diversi comportamenti e causano potenziali problemi di sicurezza, che come linguaggio ha tutti i difetti dell'universo piu uno, ma dire che sia piu complesso di Python é ridicolo. secondo me anche la sua semplicitá va annoverata tra i suoi difetti: é un linguaggio che offre troppo pochi strumenti anche sul piano dei costrutti, nel 2010 non si puó essere produttivi con if, switch, for, do, while, struct e funzioni.
Certo, l'aritmetica dei puntatori è semplicissima ed è impossibile sbagliare. :asd:
La manipolazione delle stringhe è la cosa + semplice del mondo (a proposito, ci sono le stringhe in C? :)) :asd:
Leggere e scrivere su file è la cosa + semplice del mondo. :asd:
quanto agli if sono una buona causa di errori e ove possibile vanno eliminati.
La programmazione ad oggetti ti offre + strumenti per fare ciò. :)
vorresti farmi credere che non usi mai la composizione sequenziale quando programmi? che i metodi dei tuoi oggetti hanno solo un'istruzione?
usare il paradigma procedurale é inevitabile in molti linguaggi, tra cui anche Java (per C# il discorso sarebbe diverso ma la stragrande maggioranza delle volte lo si usa quasi come Java). il punto del discorso é un altro: il paradigma procedurale da solo é troppo povero, la programmazione a oggetti lo arricchisce permettendo di essere piu produttivi.
Non è il fatto di quello che usi è il ragionamento che fai per scrivere codice.
Un'accozzaglia di codice pieno di if, che utilizza array anzichè degli oggetti, e con cicli a manetta non è assolutamente un buon codice.
C'è sempre una soluzione migliore ma col paradigma procedurale non la puoi usare.
Con il C# usando il paradigma ad oggetti e quello funzionale di LINQ puoi fare entrambe le cose.
e posso chiedere come si presentava la sua carriera accademica o ci sono questioni di privacy? perché (posto che non conosco bene il sistema di studi delle vostre parti) se mi dici che si é preso una laurea breve in 10 anni e con un voto mediocre direi che non é il paradigma procedurale il motivo per cui l'avete scartato.
L'abbiamo scartato proprio perchè durante la sessione di pair programming si vedeva che non era abituato a programmare ad oggetti, non aveva mai utilizzato delle piattaforme di test e scriveva codice contorto, difficile da debuggare e impossibile da testare.
LINQ da solo non basta a rendere C# un linguaggio funzionale.
No, ma gli permette di sfruttare tutti i vantaggi della programmazione funzionale senza side-effects, tra cui il parallelismo automatico, assolutamente gratuito e sicuro, in diverse situazioni grazie alle Parallels Extensions.
hai ragione, confido sempre troppo in Mono :D
comunque Mac ha Rotor.
F# é a oggetti, comunque anche il paradigma funzionale é molto importante: i programmi puramente funzionali sono rientranti e i programmi rientranti sono automaticamente parallelizzabili.
Infatti in C# puoi scrivere le parti critiche di codice che ti interessa parallelizzare in questo modo:
var filteredImage = from p in image.pixels.AsParallel()
where p.value > 10 && p.value < 100
select p;
foreach (var pixel in filteredImage) {
process(pixel);
}
Con la semplice chiamata al metodo AsParallel il framework suddivide automaticamente i task a seconda del numero di processori presenti sul sistema, sfruttando pienamente la macchina su cui gira il codice.
E comunque F# è decisamente + orientato alla programmazione funzionale essendo "figlio" di OCaml.
del C si puó dire tutto: che é vecchio, che é improduttivo, che offre pochissimi strumenti nelle librerie predefinite, che le specifiche lasciano indefiniti diversi comportamenti e causano potenziali problemi di sicurezza, che come linguaggio ha tutti i difetti dell'universo piu uno, ma dire che sia piu complesso di Python é ridicolo. secondo me anche la sua semplicitá va annoverata tra i suoi difetti: é un linguaggio che offre troppo pochi strumenti anche sul piano dei costrutti, nel 2010 non si puó essere produttivi con if, switch, for, do, while, struct e funzioni.
Certo, l'aritmetica dei puntatori è semplicissima ed è impossibile sbagliare. :asd:
La manipolazione delle stringhe è la cosa + semplice del mondo (a proposito, ci sono le stringhe in C? :)) :asd:
Leggere e scrivere su file è la cosa + semplice del mondo. :asd:
quanto agli if sono una buona causa di errori e ove possibile vanno eliminati.
La programmazione ad oggetti ti offre + strumenti per fare ciò. :)
vorresti farmi credere che non usi mai la composizione sequenziale quando programmi? che i metodi dei tuoi oggetti hanno solo un'istruzione?
usare il paradigma procedurale é inevitabile in molti linguaggi, tra cui anche Java (per C# il discorso sarebbe diverso ma la stragrande maggioranza delle volte lo si usa quasi come Java). il punto del discorso é un altro: il paradigma procedurale da solo é troppo povero, la programmazione a oggetti lo arricchisce permettendo di essere piu produttivi.
Non è il fatto di quello che usi è il ragionamento che fai per scrivere codice.
Un'accozzaglia di codice pieno di if, che utilizza array anzichè degli oggetti, e con cicli a manetta non è assolutamente un buon codice.
C'è sempre una soluzione migliore ma col paradigma procedurale non la puoi usare.
Con il C# usando il paradigma ad oggetti e quello funzionale di LINQ puoi fare entrambe le cose.
e posso chiedere come si presentava la sua carriera accademica o ci sono questioni di privacy? perché (posto che non conosco bene il sistema di studi delle vostre parti) se mi dici che si é preso una laurea breve in 10 anni e con un voto mediocre direi che non é il paradigma procedurale il motivo per cui l'avete scartato.
L'abbiamo scartato proprio perchè durante la sessione di pair programming si vedeva che non era abituato a programmare ad oggetti, non aveva mai utilizzato delle piattaforme di test e scriveva codice contorto, difficile da debuggare e impossibile da testare.
LINQ da solo non basta a rendere C# un linguaggio funzionale.
No, ma gli permette di sfruttare tutti i vantaggi della programmazione funzionale senza side-effects, tra cui il parallelismo automatico, assolutamente gratuito e sicuro, in diverse situazioni grazie alle Parallels Extensions.
hai ragione, confido sempre troppo in Mono :D
comunque Mac ha Rotor.
F# é a oggetti, comunque anche il paradigma funzionale é molto importante: i programmi puramente funzionali sono rientranti e i programmi rientranti sono automaticamente parallelizzabili.
Infatti in C# puoi scrivere le parti critiche di codice che ti interessa parallelizzare in questo modo:
var filteredImage = from p in image.pixels.AsParallel()
where p.value > 10 && p.value < 100
select p;
foreach (var pixel in filteredImage) {
process(pixel);
}
Con la semplice chiamata al metodo AsParallel il framework suddivide automaticamente i task a seconda del numero di processori presenti sul sistema, sfruttando pienamente la macchina su cui gira il codice.
E comunque F# è decisamente + orientato alla programmazione funzionale essendo "figlio" di OCaml.
^TiGeRShArK^
11-04-2010, 09:57
C'è una cosa che non capisco...
Io ho cominciato con il visual basic 6 su windows, poi ho studiato su un libro di C su linux, e ho intenzione di imparare il C++...
Ora, è vero che con il C vieni seppellito da "segmentation fault, double delete, bug intermittenti", ma per imparare, non è questo quello che serve?
No.
E' questo che ti serve se vuoi imparare a programmare in C utilizzando un paradigma che ormai, a parte qualche eccezione, non serve a nulla nel mondo del lavoro.
Faccio un paragone:
Se voglio diventare meccanico, non prendo un motore già fatto e lo metto nell'auto per farla camminare, perché così saprò fare andare l'auto, ma non avrò bene capito come funziona (che poi è il mio obbiettivo primario, no?).
Se invece assemblo io il motore, magari funzionerà male, ma avrò capito bene quali problemi ci sono dietro, e quindi come fa a funzionare!
Il tuo paragone è sbagliato.
Dovresti fare un paragone tra un meccanico che prova a montare tutto con un cacciavite e un meccanico che utilizza tutti gli strumenti a disposizione.
Il linguaggio di programmazione è solo lo STRUMENTO, non è nulla di +.
E come meccanico col C ne stai usando uno che è specializzato ed essenziale in pochi casi, ma che nella stragrande maggioranza dei casi è poco funzionale o addirittura dannoso.
"The right tool for the right job" è la prima cosa da comprendere se si vuole programmare seriamente.
Essere fanboy di uno strumento non serve a niente.
Bisogna avere a disposizione quanti + strumenti possibile nella propria cassetta degli attrezzi e si devono utilizzare bene.
Poi è ovvio che una volta imparato il C è meglio studiare anche altri linguaggi (python, C++...), ma con il C puoi capire come funziona il "motore"! Qualcuno ha citato l'assembler: sarebbe quello il punto da dove iniziare! Se capisci come funziona la macchina ad un livello così basso, poi potrai usare bene gli strumenti più potenti.
L'assembly infatti ha anche una sua utilità se il tuo scopo primario è capire come funziona il processore, non per niente viene utilizzato in tutti i corsi di calcolatori elettronici e architettura dei calcolatori.
Ma il C non ti spiega assolutamente nulla di come funziona una CPU.
Per questo, nella mia "newbaggine", consiglio a LittleDeveloper il C per iniziare (ma solo piccole dosi a volta :D).
Magari insieme ad un buon libro (o prof, magari ad averne uno bravo!).
C'è qualcosa che non va nel mio ragionamento?
vedi sopra. :p
Io ho cominciato con il visual basic 6 su windows, poi ho studiato su un libro di C su linux, e ho intenzione di imparare il C++...
Ora, è vero che con il C vieni seppellito da "segmentation fault, double delete, bug intermittenti", ma per imparare, non è questo quello che serve?
No.
E' questo che ti serve se vuoi imparare a programmare in C utilizzando un paradigma che ormai, a parte qualche eccezione, non serve a nulla nel mondo del lavoro.
Faccio un paragone:
Se voglio diventare meccanico, non prendo un motore già fatto e lo metto nell'auto per farla camminare, perché così saprò fare andare l'auto, ma non avrò bene capito come funziona (che poi è il mio obbiettivo primario, no?).
Se invece assemblo io il motore, magari funzionerà male, ma avrò capito bene quali problemi ci sono dietro, e quindi come fa a funzionare!
Il tuo paragone è sbagliato.
Dovresti fare un paragone tra un meccanico che prova a montare tutto con un cacciavite e un meccanico che utilizza tutti gli strumenti a disposizione.
Il linguaggio di programmazione è solo lo STRUMENTO, non è nulla di +.
E come meccanico col C ne stai usando uno che è specializzato ed essenziale in pochi casi, ma che nella stragrande maggioranza dei casi è poco funzionale o addirittura dannoso.
"The right tool for the right job" è la prima cosa da comprendere se si vuole programmare seriamente.
Essere fanboy di uno strumento non serve a niente.
Bisogna avere a disposizione quanti + strumenti possibile nella propria cassetta degli attrezzi e si devono utilizzare bene.
Poi è ovvio che una volta imparato il C è meglio studiare anche altri linguaggi (python, C++...), ma con il C puoi capire come funziona il "motore"! Qualcuno ha citato l'assembler: sarebbe quello il punto da dove iniziare! Se capisci come funziona la macchina ad un livello così basso, poi potrai usare bene gli strumenti più potenti.
L'assembly infatti ha anche una sua utilità se il tuo scopo primario è capire come funziona il processore, non per niente viene utilizzato in tutti i corsi di calcolatori elettronici e architettura dei calcolatori.
Ma il C non ti spiega assolutamente nulla di come funziona una CPU.
Per questo, nella mia "newbaggine", consiglio a LittleDeveloper il C per iniziare (ma solo piccole dosi a volta :D).
Magari insieme ad un buon libro (o prof, magari ad averne uno bravo!).
C'è qualcosa che non va nel mio ragionamento?
vedi sopra. :p
^TiGeRShArK^
11-04-2010, 10:00
:rotfl: Era dai tempi dell' "Impero del MALE" di reaganiana memoria che non sentivo un'affermazione demagogica basata sul concetto elementare bene/male, che fosse espressa in modo serio. Bello soprattutto l'articolo "il" prima del sostantivo "MALE" (in maiuscolo).
Ti devi comunque aggiornare se vuoi convincere fero86. Ti consiglio: Porquet Jean-Luc - Venditori di fumo. Le regole basilari della demagogia efficace - ISBN: 9788881129683
Io non voglio convincere nessuno. :)
I miei sono solo consigli che posso dare in base alla mia esperienza. :)
Certo è che persone che al giorno d'oggi ragionano in maniera procedurale non hanno sbocchi nella maggior parte del mercato del lavoro.
Se poi la propria massima aspirazione è lavorare su dei drivers, su un kernel in C o su dei microcontrollori allora nessun problema. :)
Per me la programmazione è molto altro e comprende campi + ampi e imho divertenti. :)
Ti devi comunque aggiornare se vuoi convincere fero86. Ti consiglio: Porquet Jean-Luc - Venditori di fumo. Le regole basilari della demagogia efficace - ISBN: 9788881129683
Io non voglio convincere nessuno. :)
I miei sono solo consigli che posso dare in base alla mia esperienza. :)
Certo è che persone che al giorno d'oggi ragionano in maniera procedurale non hanno sbocchi nella maggior parte del mercato del lavoro.
Se poi la propria massima aspirazione è lavorare su dei drivers, su un kernel in C o su dei microcontrollori allora nessun problema. :)
Per me la programmazione è molto altro e comprende campi + ampi e imho divertenti. :)
rеpne scasb
11-04-2010, 10:11
■
^TiGeRShArK^
11-04-2010, 10:24
Qualche giorno fa leggevo questa cosa: http://www.hwupgrade.it/forum/showpost.php?p=31550318&postcount=81 voi dire che sono stata ingannata? Dannato Matrixbob ed il suo modo obnubilante di esporre pseudo-fatti!!
Ti sei persa le statistiche di TIOBE (si proprio quelle postate in quel thraed) quando ponevano ai primi posti RPG, il linguaggio usato su AS/400 (ora iSeries). :)
Inutile dire che dopo si è scoperto che prendevano in considerazione anche i Role Playing Game nella formulazione della loro statistica. :rotfl:
Da quel giorno per me TIOBE ha validità assolutamente NULLA. :)
Ti sei persa le statistiche di TIOBE (si proprio quelle postate in quel thraed) quando ponevano ai primi posti RPG, il linguaggio usato su AS/400 (ora iSeries). :)
Inutile dire che dopo si è scoperto che prendevano in considerazione anche i Role Playing Game nella formulazione della loro statistica. :rotfl:
Da quel giorno per me TIOBE ha validità assolutamente NULLA. :)
rеpne scasb
11-04-2010, 10:29
■
^TiGeRShArK^
11-04-2010, 10:33
Ma appunto, ri ringrazio sentitamente di avermi edotta. Ora io vedo il BENE....... lo percepisco sottoforma di etere luminoso.........
ah beh..
continua pure a credere alle statistiche di tiobe, senza pensare con la tua testa ai campi in cui ad oggi è usato il C rispetto a tutti gli altri linguaggi. :)
Io di sicuro non mi metto a scrivere un applicazione web o desktop in C oggi come oggi se con altri strumenti posso ottenere risultati molto migliori e in minore tempo. :)
E di una persona che ragioni in quel modo, anche usando altri linguaggi, nel team non ne ho proprio bisogno. :)
ah beh..
continua pure a credere alle statistiche di tiobe, senza pensare con la tua testa ai campi in cui ad oggi è usato il C rispetto a tutti gli altri linguaggi. :)
Io di sicuro non mi metto a scrivere un applicazione web o desktop in C oggi come oggi se con altri strumenti posso ottenere risultati molto migliori e in minore tempo. :)
E di una persona che ragioni in quel modo, anche usando altri linguaggi, nel team non ne ho proprio bisogno. :)
lupoxxx87
11-04-2010, 11:01
ndr1:
il thread sta diventando la solita arringa difensiva del proprio linguaggio preferito....non mi pare fosse questo l'intento del thread
ndr2 (assolutamente oggettiva):
perchè nessuno si pone realmente il problema dal punto di vista giusto ?
qual'è il linguaggio migliore...per fare cosa !?!?!?
restringiamo un attimo il campo a C e Java per i maggiori punti, perchè altrimenti oltre a Phyton potremmo aggiungere PHP, Ruby, Cobol e altri ancora...
• devo programmare una eeprom ? --> C
• devo scrivere un piccolo sistema embedded ? --> C
• voglio scrivere una applicazione distribuita ? --> Java
• voglio scrivere una piccola app web ? --> Java
ora non venite a scrivere critiche inutili perchè so benissimo anch'io che ci sono mille altri modi per realizzare questi piccoli quattro esempi in miliardi di altri linguaggi.
la cosa che continuate, o continuiamo a fare (non voglio considerarmi superiore a nessuno) è additare ai difetti dei singoli linguaggi.
l'aritmetica dei puntatori è una str****ta ? beh ma se ho lo spazio all'interno della mia eeprom fissato a 64k, non riesco certo a installarci una JVM.
tra pochi giorni un mio collega discuterà la relazione finale del proprio phd. ha passato 3 anni a realizzare un sistema di sensori di movimento che, posizionati su una racchetta da tennis, aumentano o diminuiscono la tensione delle corde a seconda del colpo che il giocatore sta effettuando.
tutto questo senza processori o altro. solo un quarzo come generatore di clock, 2 rom, un motorino elettrico e una batteria, e tutto programmato in assembly.
cosa c'entra ?
c'entra il fatto che non è il programmatore a decidere il linguaggio, ma la necessità !
ogni programmatore può trovarsi bene con un linguaggio o con l'altro; un bravo programmatore non è uno che sa programmare qualsiasi cosa con un linguaggio solo. una figura così è un programmatore esperto del tale linguaggio. un bravo programmatore sa riconoscere, di fronte alle necessità e ai mezzi, quale sia il linguaggio migliore per la propria situazione e, all'occorrenza, rivolgersi a dei programmatori esperti di tale linguaggio.
il thread sta diventando la solita arringa difensiva del proprio linguaggio preferito....non mi pare fosse questo l'intento del thread
ndr2 (assolutamente oggettiva):
perchè nessuno si pone realmente il problema dal punto di vista giusto ?
qual'è il linguaggio migliore...per fare cosa !?!?!?
restringiamo un attimo il campo a C e Java per i maggiori punti, perchè altrimenti oltre a Phyton potremmo aggiungere PHP, Ruby, Cobol e altri ancora...
• devo programmare una eeprom ? --> C
• devo scrivere un piccolo sistema embedded ? --> C
• voglio scrivere una applicazione distribuita ? --> Java
• voglio scrivere una piccola app web ? --> Java
ora non venite a scrivere critiche inutili perchè so benissimo anch'io che ci sono mille altri modi per realizzare questi piccoli quattro esempi in miliardi di altri linguaggi.
la cosa che continuate, o continuiamo a fare (non voglio considerarmi superiore a nessuno) è additare ai difetti dei singoli linguaggi.
l'aritmetica dei puntatori è una str****ta ? beh ma se ho lo spazio all'interno della mia eeprom fissato a 64k, non riesco certo a installarci una JVM.
tra pochi giorni un mio collega discuterà la relazione finale del proprio phd. ha passato 3 anni a realizzare un sistema di sensori di movimento che, posizionati su una racchetta da tennis, aumentano o diminuiscono la tensione delle corde a seconda del colpo che il giocatore sta effettuando.
tutto questo senza processori o altro. solo un quarzo come generatore di clock, 2 rom, un motorino elettrico e una batteria, e tutto programmato in assembly.
cosa c'entra ?
c'entra il fatto che non è il programmatore a decidere il linguaggio, ma la necessità !
ogni programmatore può trovarsi bene con un linguaggio o con l'altro; un bravo programmatore non è uno che sa programmare qualsiasi cosa con un linguaggio solo. una figura così è un programmatore esperto del tale linguaggio. un bravo programmatore sa riconoscere, di fronte alle necessità e ai mezzi, quale sia il linguaggio migliore per la propria situazione e, all'occorrenza, rivolgersi a dei programmatori esperti di tale linguaggio.
^TiGeRShArK^
11-04-2010, 11:04
ogni programmatore può trovarsi bene con un linguaggio o con l'altro; un bravo programmatore non è uno che sa programmare qualsiasi cosa con un linguaggio solo. una figura così è un programmatore esperto del tale linguaggio. un bravo programmatore sa riconoscere, di fronte alle necessità e ai mezzi, quale sia il linguaggio migliore per la propria situazione e, all'occorrenza, rivolgersi a dei programmatori esperti di tale linguaggio.
esatto, è quello che sto ripetendo dall'inizio del thread. :)
esatto, è quello che sto ripetendo dall'inizio del thread. :)
banryu79
11-04-2010, 11:11
@LittleDeveloper:
Se già non lo hai fatto ti consiglio di leggere questo thread (semi-ufficiale):
QUALE LINGUAGGIO SCEGLIERE ? (http://www.hwupgrade.it/forum/showthread.php?t=1979444)
che ti consente di esaminare pur sempre delle opinioni altrui ma, data la forma il modo e i tempi e il motivo con cui sono state espresse, e postate, potrebbero aiutarti a formarti un quadro di massima un po' più chiaro che la lettura di questo come di altri simili thread. Ovviamente IMHO.
Se già non lo hai fatto ti consiglio di leggere questo thread (semi-ufficiale):
QUALE LINGUAGGIO SCEGLIERE ? (http://www.hwupgrade.it/forum/showthread.php?t=1979444)
che ti consente di esaminare pur sempre delle opinioni altrui ma, data la forma il modo e i tempi e il motivo con cui sono state espresse, e postate, potrebbero aiutarti a formarti un quadro di massima un po' più chiaro che la lettura di questo come di altri simili thread. Ovviamente IMHO.
lupoxxx87
11-04-2010, 11:34
esatto, è quello che sto ripetendo dall'inizio del thread. :)
ah...a me sembrava che ripetessi che C fa ca**re mentre Java è la cosa più bella del mondo
ah...a me sembrava che ripetessi che C fa ca**re mentre Java è la cosa più bella del mondo
^TiGeRShArK^
11-04-2010, 11:37
ah...a me sembrava che ripetessi che C fa ca**re mentre Java è la cosa più bella del mondo
evidentemente non hai letto i miei post. :)
Il linguaggio di programmazione è solo lo STRUMENTO, non è nulla di +.
E come meccanico col C ne stai usando uno che è specializzato ed essenziale in pochi casi, ma che nella stragrande maggioranza dei casi è poco funzionale o addirittura dannoso.
"The right tool for the right job" è la prima cosa da comprendere se si vuole programmare seriamente.
Essere fanboy di uno strumento non serve a niente.
Bisogna avere a disposizione quanti + strumenti possibile nella propria cassetta degli attrezzi e si devono utilizzare bene.
E comunque, anche se ho consigliato java o python nel caso non siano essenziali le interfacce grafiche, io ora come ora lavoro in C#. :)
Io sono un fan dell'utilizzare lo strumento giusto per quello che devi fare, non certo di un unico linguaggio. :)
evidentemente non hai letto i miei post. :)
Il linguaggio di programmazione è solo lo STRUMENTO, non è nulla di +.
E come meccanico col C ne stai usando uno che è specializzato ed essenziale in pochi casi, ma che nella stragrande maggioranza dei casi è poco funzionale o addirittura dannoso.
"The right tool for the right job" è la prima cosa da comprendere se si vuole programmare seriamente.
Essere fanboy di uno strumento non serve a niente.
Bisogna avere a disposizione quanti + strumenti possibile nella propria cassetta degli attrezzi e si devono utilizzare bene.
E comunque, anche se ho consigliato java o python nel caso non siano essenziali le interfacce grafiche, io ora come ora lavoro in C#. :)
Io sono un fan dell'utilizzare lo strumento giusto per quello che devi fare, non certo di un unico linguaggio. :)
cdimauro
11-04-2010, 11:52
C'è una cosa che non capisco...
Io ho cominciato con il visual basic 6 su windows, poi ho studiato su un libro di C su linux, e ho intenzione di imparare il C++...
Ora, è vero che con il C vieni seppellito da "segmentation fault, double delete, bug intermittenti", ma per imparare, non è questo quello che serve?
Faccio un paragone:
Se voglio diventare meccanico, non prendo un motore già fatto e lo metto nell'auto per farla camminare, perché così saprò fare andare l'auto, ma non avrò bene capito come funziona (che poi è il mio obbiettivo primario, no?).
Se invece assemblo io il motore, magari funzionerà male, ma avrò capito bene quali problemi ci sono dietro, e quindi come fa a funzionare!
Poi è ovvio che una volta imparato il C è meglio studiare anche altri linguaggi (python, C++...), ma con il C puoi capire come funziona il "motore"! Qualcuno ha citato l'assembler: sarebbe quello il punto da dove iniziare! Se capisci come funziona la macchina ad un livello così basso, poi potrai usare bene gli strumenti più potenti.
Per questo, nella mia "newbaggine", consiglio a LittleDeveloper il C per iniziare (ma solo piccole dosi a volta :D).
Magari insieme ad un buon libro (o prof, magari ad averne uno bravo!).
C'è qualcosa che non va nel mio ragionamento?
Sì, e a quello che ha scritto già Tiger aggiungo una cosa: l'errore che commetti (non soltanto tu: è una cosa comune :p) è confondere le basi della programmazione / informatica coi dettagli di bassi livello.
L'unica cosa veramente basilare per un buon programmatore è il concetto di algoritmo. E, di conseguenza, il concetto di dato, tipo di dato, variabile, iterazione, condizione, ecc.
Queste sono le basi.
I dettagli di basso livello sono tutt'altra cosa e servono per comprendere come funziona l'architettura di uno specifico elaboratore.
Paradossalmente, se dovessimo prendere per buono il fatto di far corrispondere alla basi della programmazione i dettagli di più basso livello, partendo da Python (linguaggio di altissimo livello) passeremmo al C, poi all'assembly, al linguaggio macchina, e al a VHDL che definisce il funzionamento dei chip. Ma potremmo anche spingerci oltre: microelettronica, fisica, e matematica (di quella "tosta": immagina cosa possa servire per descrivere il funzionamento di un transistor).
Quindi prima di iniziare a programmare dovremmo conseguire un'ottima laurea in matematica, e possibilmente un bel master o, meglio ancora, un PhD in questa materia.
E poi, a ritroso, passando alla fisica, ecc. ecc.
Stimolante, vero? :D
Io ho cominciato con il visual basic 6 su windows, poi ho studiato su un libro di C su linux, e ho intenzione di imparare il C++...
Ora, è vero che con il C vieni seppellito da "segmentation fault, double delete, bug intermittenti", ma per imparare, non è questo quello che serve?
Faccio un paragone:
Se voglio diventare meccanico, non prendo un motore già fatto e lo metto nell'auto per farla camminare, perché così saprò fare andare l'auto, ma non avrò bene capito come funziona (che poi è il mio obbiettivo primario, no?).
Se invece assemblo io il motore, magari funzionerà male, ma avrò capito bene quali problemi ci sono dietro, e quindi come fa a funzionare!
Poi è ovvio che una volta imparato il C è meglio studiare anche altri linguaggi (python, C++...), ma con il C puoi capire come funziona il "motore"! Qualcuno ha citato l'assembler: sarebbe quello il punto da dove iniziare! Se capisci come funziona la macchina ad un livello così basso, poi potrai usare bene gli strumenti più potenti.
Per questo, nella mia "newbaggine", consiglio a LittleDeveloper il C per iniziare (ma solo piccole dosi a volta :D).
Magari insieme ad un buon libro (o prof, magari ad averne uno bravo!).
C'è qualcosa che non va nel mio ragionamento?
Sì, e a quello che ha scritto già Tiger aggiungo una cosa: l'errore che commetti (non soltanto tu: è una cosa comune :p) è confondere le basi della programmazione / informatica coi dettagli di bassi livello.
L'unica cosa veramente basilare per un buon programmatore è il concetto di algoritmo. E, di conseguenza, il concetto di dato, tipo di dato, variabile, iterazione, condizione, ecc.
Queste sono le basi.
I dettagli di basso livello sono tutt'altra cosa e servono per comprendere come funziona l'architettura di uno specifico elaboratore.
Paradossalmente, se dovessimo prendere per buono il fatto di far corrispondere alla basi della programmazione i dettagli di più basso livello, partendo da Python (linguaggio di altissimo livello) passeremmo al C, poi all'assembly, al linguaggio macchina, e al a VHDL che definisce il funzionamento dei chip. Ma potremmo anche spingerci oltre: microelettronica, fisica, e matematica (di quella "tosta": immagina cosa possa servire per descrivere il funzionamento di un transistor).
Quindi prima di iniziare a programmare dovremmo conseguire un'ottima laurea in matematica, e possibilmente un bel master o, meglio ancora, un PhD in questa materia.
E poi, a ritroso, passando alla fisica, ecc. ecc.
Stimolante, vero? :D
^TiGeRShArK^
11-04-2010, 12:08
Sì, e a quello che ha scritto già Tiger aggiungo una cosa: l'errore che commetti (non soltanto tu: è una cosa comune :p) è confondere le basi della programmazione / informatica coi dettagli di bassi livello.
L'unica cosa veramente basilare per un buon programmatore è il concetto di algoritmo. E, di conseguenza, il concetto di dato, tipo di dato, variabile, iterazione, condizione, ecc.
Queste sono le basi.
I dettagli di basso livello sono tutt'altra cosa e servono per comprendere come funziona l'architettura di uno specifico elaboratore.
Paradossalmente, se dovessimo prendere per buono il fatto di far corrispondere alla basi della programmazione i dettagli di più basso livello, partendo da Python (linguaggio di altissimo livello) passeremmo al C, poi all'assembly, al linguaggio macchina, e al a VHDL che definisce il funzionamento dei chip. Ma potremmo anche spingerci oltre: microelettronica, fisica, e matematica (di quella "tosta": immagina cosa possa servire per descrivere il funzionamento di un transistor).
Quindi prima di iniziare a programmare dovremmo conseguire un'ottima laurea in matematica, e possibilmente un bel master o, meglio ancora, un PhD in questa materia.
E poi, a ritroso, passando alla fisica, ecc. ecc.
Stimolante, vero? :D
dispositivi elettronici, quando si studiava la fisica delle giunzioni di silicio &co., era davvero carina come materia, peccato che fosse un pò pesantuccia. :D
L'unica cosa veramente basilare per un buon programmatore è il concetto di algoritmo. E, di conseguenza, il concetto di dato, tipo di dato, variabile, iterazione, condizione, ecc.
Queste sono le basi.
I dettagli di basso livello sono tutt'altra cosa e servono per comprendere come funziona l'architettura di uno specifico elaboratore.
Paradossalmente, se dovessimo prendere per buono il fatto di far corrispondere alla basi della programmazione i dettagli di più basso livello, partendo da Python (linguaggio di altissimo livello) passeremmo al C, poi all'assembly, al linguaggio macchina, e al a VHDL che definisce il funzionamento dei chip. Ma potremmo anche spingerci oltre: microelettronica, fisica, e matematica (di quella "tosta": immagina cosa possa servire per descrivere il funzionamento di un transistor).
Quindi prima di iniziare a programmare dovremmo conseguire un'ottima laurea in matematica, e possibilmente un bel master o, meglio ancora, un PhD in questa materia.
E poi, a ritroso, passando alla fisica, ecc. ecc.
Stimolante, vero? :D
dispositivi elettronici, quando si studiava la fisica delle giunzioni di silicio &co., era davvero carina come materia, peccato che fosse un pò pesantuccia. :D
WarDuck
11-04-2010, 12:27
A me sembra che molti siano confusi dal fatto che credono che imparare a programmare = imparare un linguaggio.
Niente di più falso.
Inoltre la semplicità di un linguaggio (se la si vuole considerare in maniera oggettiva) è un concetto che può assumere diverse forme:
Si può considerare "semplice" un linguaggio con pochi costrutti come il C, o "semplice" un linguaggio che con poche righe assove ad un problema come Python. L'ideale sarebbe avere entrambe le cose, ma l'ingegneria è l'arte del compromesso quindi direi di non lamentarci più di tanto.
In entrambi i casi il linguaggio scelto di per se non ti darà la mentalità per risolvere i problemi. Ovvero il "COSA fare per" (e non il COME, anche se poi è altrettanto importante).
Studiare come è fatto un linguaggio di programmazione e quali strumenti offre è solo l'inizio.
Certo è che la programmazione a basso livello ti può far comprendere meglio il funzionamento di un calcolatore, e questo non è necessariamente un male.
In ogni caso secondo me è meglio usare un linguaggio che sta un po' a metà (nella metà alta diciamo :D) come Java per acquisire quella mentalità.
Niente di più falso.
Inoltre la semplicità di un linguaggio (se la si vuole considerare in maniera oggettiva) è un concetto che può assumere diverse forme:
Si può considerare "semplice" un linguaggio con pochi costrutti come il C, o "semplice" un linguaggio che con poche righe assove ad un problema come Python. L'ideale sarebbe avere entrambe le cose, ma l'ingegneria è l'arte del compromesso quindi direi di non lamentarci più di tanto.
In entrambi i casi il linguaggio scelto di per se non ti darà la mentalità per risolvere i problemi. Ovvero il "COSA fare per" (e non il COME, anche se poi è altrettanto importante).
Studiare come è fatto un linguaggio di programmazione e quali strumenti offre è solo l'inizio.
Certo è che la programmazione a basso livello ti può far comprendere meglio il funzionamento di un calcolatore, e questo non è necessariamente un male.
In ogni caso secondo me è meglio usare un linguaggio che sta un po' a metà (nella metà alta diciamo :D) come Java per acquisire quella mentalità.
^TiGeRShArK^
11-04-2010, 12:29
A me sembra che molti siano confusi dal fatto che credono che imparare a programmare = imparare un linguaggio.
Niente di più falso.
Inoltre la semplicità di un linguaggio (se la si vuole considerare in maniera oggettiva) è un concetto che può assumere diverse forme:
Si può considerare "semplice" un linguaggio con pochi costrutti come il C, o "semplice" un linguaggio che con poche righe assove ad un problema come Python. L'ideale sarebbe avere entrambe le cose, ma l'ingegneria è l'arte del compromesso quindi direi di non lamentarci più di tanto.
In entrambi i casi il linguaggio scelto di per se non ti darà la mentalità per risolvere i problemi. Ovvero il "COSA fare per" (e non il COME, anche se poi è altrettanto importante).
Studiare come è fatto un linguaggio di programmazione e quali strumenti offre è solo l'inizio.
Certo è che la programmazione a basso livello ti può far comprendere meglio il funzionamento di un calcolatore, e questo non è necessariamente un male.
In ogni caso secondo me è meglio usare un linguaggio che sta un po' a metà (nella metà alta diciamo :D) come Java per acquisire quella mentalità.
di sicuro col C non potrai imparare la mentalità per programmare ad oggetti. :p
E se poi vorrai impararla devi prima DIS-imparare quello che hai imparato col C, come sanno benissimo tutti quelli che, come me, hanno iniziato con dei linguaggi procedurali e sono migrati solo dopo ai linguaggi ad oggetti. :p
Niente di più falso.
Inoltre la semplicità di un linguaggio (se la si vuole considerare in maniera oggettiva) è un concetto che può assumere diverse forme:
Si può considerare "semplice" un linguaggio con pochi costrutti come il C, o "semplice" un linguaggio che con poche righe assove ad un problema come Python. L'ideale sarebbe avere entrambe le cose, ma l'ingegneria è l'arte del compromesso quindi direi di non lamentarci più di tanto.
In entrambi i casi il linguaggio scelto di per se non ti darà la mentalità per risolvere i problemi. Ovvero il "COSA fare per" (e non il COME, anche se poi è altrettanto importante).
Studiare come è fatto un linguaggio di programmazione e quali strumenti offre è solo l'inizio.
Certo è che la programmazione a basso livello ti può far comprendere meglio il funzionamento di un calcolatore, e questo non è necessariamente un male.
In ogni caso secondo me è meglio usare un linguaggio che sta un po' a metà (nella metà alta diciamo :D) come Java per acquisire quella mentalità.
di sicuro col C non potrai imparare la mentalità per programmare ad oggetti. :p
E se poi vorrai impararla devi prima DIS-imparare quello che hai imparato col C, come sanno benissimo tutti quelli che, come me, hanno iniziato con dei linguaggi procedurali e sono migrati solo dopo ai linguaggi ad oggetti. :p
lupoxxx87
11-04-2010, 12:45
beh a me piaceva... xD
:.Blizzard.:
11-04-2010, 13:52
di sicuro col C non potrai imparare la mentalità per programmare ad oggetti. :p
E se poi vorrai impararla devi prima DIS-imparare quello che hai imparato col C, come sanno benissimo tutti quelli che, come me, hanno iniziato con dei linguaggi procedurali e sono migrati solo dopo ai linguaggi ad oggetti. :p
Il problema è poi quando devi fare il passaggio inverso per necessità ... :D
E se poi vorrai impararla devi prima DIS-imparare quello che hai imparato col C, come sanno benissimo tutti quelli che, come me, hanno iniziato con dei linguaggi procedurali e sono migrati solo dopo ai linguaggi ad oggetti. :p
Il problema è poi quando devi fare il passaggio inverso per necessità ... :D
rеpne scasb
11-04-2010, 14:28
■
^TiGeRShArK^
11-04-2010, 15:11
E tu sei sicuro di averli letti?
si, di solito li rileggo sempre dopo che scrivo. :)
si, di solito li rileggo sempre dopo che scrivo. :)
rеpne scasb
11-04-2010, 17:19
■
PGI-Bis
11-04-2010, 17:51
Quindi prima di iniziare a programmare dovremmo conseguire un'ottima laurea in matematica, e possibilmente un bel master o, meglio ancora, un PhD in questa materia.
E poi, a ritroso, passando alla fisica, ecc. ecc.
Stimolante, vero? :D
Mah, ti dirò, a metterla giù così non parrebbe un'idea poi così cattiva.
E poi, a ritroso, passando alla fisica, ecc. ecc.
Stimolante, vero? :D
Mah, ti dirò, a metterla giù così non parrebbe un'idea poi così cattiva.
fero86
11-04-2010, 19:49
Certo, l'aritmetica dei puntatori è semplicissima ed è impossibile sbagliare. :asd: gli errori off-by-one si possono commettere in qualunque linguaggio che fornisca gli array, compresi Python, Java e C#, solo che hanno conseguenze diverse. per il resto l'aritmetica dei puntatori mi pare che abbia una complessitá analoga a quella elementare: hai presente le sottrazioni e le addizioni, no?
La manipolazione delle stringhe è la cosa + semplice del mondo (a proposito, ci sono le stringhe in C? :)) :asd: se manipolare le stringhe in C é difficile non é certo dovuto alla complessitá del linguaggio, ma al contrario é dovuto alla sua povertá. in C non puoi avere quella che in altri linguaggi é ad esempio la classe string.
Leggere e scrivere su file è la cosa + semplice del mondo. :asd: stesso discorso di prima.
quanto agli if sono una buona causa di errori e ove possibile vanno eliminati. stai degenerando :asd:
potremmo vedere qualche statistica da cui si evince che i programmatori sbagliano piu spesso usando il costrutto if? :D
La programmazione ad oggetti ti offre + strumenti per fare ciò. :) questo é quello che dico anch'io. il discorso che tu non vuoi capire é che sono questi strumenti a fare la complessitá del linguaggio; lo renderanno anche piu facile da usare, senza dubbio (altrimenti che ci stanno a fare?), ma lo rendono piu difficile da imparare.
Non è il fatto di quello che usi è il ragionamento che fai per scrivere codice.
Un'accozzaglia di codice pieno di if, che utilizza array anzichè degli oggetti, e con cicli a manetta non è assolutamente un buon codice.
C'è sempre una soluzione migliore ma col paradigma procedurale non la puoi usare. grazie per averci esposto la tua personalissima interpretazione del paradigma procedurale. detto questo vorrei farti presente che il paradigma procedurale per come lo si intende generalmente é assolutamente inevitabile nei linguaggi non funzionali, sia perché non puoi contare sulla tail-call optimization (che non viene imposta dalle specifiche e quindi programmare senza side-effects esaurirebbe lo stack di sistema) sia perché usare il paradigma funzionale causerebbe un grosso overhead sintattico (vedi Java, dove per avere qualcosa che ricordi vagamente una lambda expression devi implementare una anonymous inner class).
L'abbiamo scartato proprio perchè durante la sessione di pair programming si vedeva che non era abituato a programmare ad oggetti, non aveva mai utilizzato delle piattaforme di test e scriveva codice contorto, difficile da debuggare e impossibile da testare. non hai risposto alla mia domanda. se non vuoi o non puoi non fa nulla, tanto era anche OT.
No, ma gli permette di sfruttare tutti i vantaggi della programmazione funzionale senza side-effects, tra cui il parallelismo automatico, assolutamente gratuito e sicuro, in diverse situazioni grazie alle Parallels Extensions. non lo metto in dubbio, ma resta la mia affermazione precedente. intendiamoci, C# é un linguaggio (anche) funzionale, ma LINQ da solo non basta a renderlo tale.
E comunque F# è decisamente + orientato alla programmazione funzionale essendo "figlio" di OCaml. altra tua personale interpretazione; in F# puoi sfruttare tanto il paradigma a oggetti quanto quello funzionale.
La manipolazione delle stringhe è la cosa + semplice del mondo (a proposito, ci sono le stringhe in C? :)) :asd: se manipolare le stringhe in C é difficile non é certo dovuto alla complessitá del linguaggio, ma al contrario é dovuto alla sua povertá. in C non puoi avere quella che in altri linguaggi é ad esempio la classe string.
Leggere e scrivere su file è la cosa + semplice del mondo. :asd: stesso discorso di prima.
quanto agli if sono una buona causa di errori e ove possibile vanno eliminati. stai degenerando :asd:
potremmo vedere qualche statistica da cui si evince che i programmatori sbagliano piu spesso usando il costrutto if? :D
La programmazione ad oggetti ti offre + strumenti per fare ciò. :) questo é quello che dico anch'io. il discorso che tu non vuoi capire é che sono questi strumenti a fare la complessitá del linguaggio; lo renderanno anche piu facile da usare, senza dubbio (altrimenti che ci stanno a fare?), ma lo rendono piu difficile da imparare.
Non è il fatto di quello che usi è il ragionamento che fai per scrivere codice.
Un'accozzaglia di codice pieno di if, che utilizza array anzichè degli oggetti, e con cicli a manetta non è assolutamente un buon codice.
C'è sempre una soluzione migliore ma col paradigma procedurale non la puoi usare. grazie per averci esposto la tua personalissima interpretazione del paradigma procedurale. detto questo vorrei farti presente che il paradigma procedurale per come lo si intende generalmente é assolutamente inevitabile nei linguaggi non funzionali, sia perché non puoi contare sulla tail-call optimization (che non viene imposta dalle specifiche e quindi programmare senza side-effects esaurirebbe lo stack di sistema) sia perché usare il paradigma funzionale causerebbe un grosso overhead sintattico (vedi Java, dove per avere qualcosa che ricordi vagamente una lambda expression devi implementare una anonymous inner class).
L'abbiamo scartato proprio perchè durante la sessione di pair programming si vedeva che non era abituato a programmare ad oggetti, non aveva mai utilizzato delle piattaforme di test e scriveva codice contorto, difficile da debuggare e impossibile da testare. non hai risposto alla mia domanda. se non vuoi o non puoi non fa nulla, tanto era anche OT.
No, ma gli permette di sfruttare tutti i vantaggi della programmazione funzionale senza side-effects, tra cui il parallelismo automatico, assolutamente gratuito e sicuro, in diverse situazioni grazie alle Parallels Extensions. non lo metto in dubbio, ma resta la mia affermazione precedente. intendiamoci, C# é un linguaggio (anche) funzionale, ma LINQ da solo non basta a renderlo tale.
E comunque F# è decisamente + orientato alla programmazione funzionale essendo "figlio" di OCaml. altra tua personale interpretazione; in F# puoi sfruttare tanto il paradigma a oggetti quanto quello funzionale.
fero86
11-04-2010, 20:17
Certo è che persone che al giorno d'oggi ragionano in maniera procedurale non hanno sbocchi nella maggior parte del mercato del lavoro. ampiamente smentito direi :D
ah beh..
continua pure a credere alle statistiche di tiobe, senza pensare con la tua testa ai campi in cui ad oggi è usato il C rispetto a tutti gli altri linguaggi. :) e dovremmo inventarceli questi campi? in base a cosa dovremmo pensarli con la nostra testa? se ora ci mettiamo a fantasticare su come sia fatta la realtá non arriveremo lontano.
magari sbaglieró ma tu, francamente, non mi sai molto di laurea in Informatica: in genere gli Informatici imparano a "usare la testa" solo quando hanno a disposizione degli assiomi.
esatto, è quello che sto ripetendo dall'inizio del thread. :) e quali sono i post di questo thread in cui hai scritto che ogni programmatore può trovarsi bene con un linguaggio o con l'altro, che un bravo programmatore non è uno che sa programmare qualsiasi cosa con un linguaggio solo, che una figura così è un programmatore esperto del tale linguaggio e che un bravo programmatore sa riconoscere, di fronte alle necessità e ai mezzi, quale sia il linguaggio migliore per la propria situazione e, all'occorrenza, rivolgersi a dei programmatori esperti di tale linguaggio? :D
ah beh..
continua pure a credere alle statistiche di tiobe, senza pensare con la tua testa ai campi in cui ad oggi è usato il C rispetto a tutti gli altri linguaggi. :) e dovremmo inventarceli questi campi? in base a cosa dovremmo pensarli con la nostra testa? se ora ci mettiamo a fantasticare su come sia fatta la realtá non arriveremo lontano.
magari sbaglieró ma tu, francamente, non mi sai molto di laurea in Informatica: in genere gli Informatici imparano a "usare la testa" solo quando hanno a disposizione degli assiomi.
esatto, è quello che sto ripetendo dall'inizio del thread. :) e quali sono i post di questo thread in cui hai scritto che ogni programmatore può trovarsi bene con un linguaggio o con l'altro, che un bravo programmatore non è uno che sa programmare qualsiasi cosa con un linguaggio solo, che una figura così è un programmatore esperto del tale linguaggio e che un bravo programmatore sa riconoscere, di fronte alle necessità e ai mezzi, quale sia il linguaggio migliore per la propria situazione e, all'occorrenza, rivolgersi a dei programmatori esperti di tale linguaggio? :D
fero86
11-04-2010, 20:21
E se poi vorrai impararla devi prima DIS-imparare quello che hai imparato col C, come sanno benissimo tutti quelli che, come me, hanno iniziato con dei linguaggi procedurali e sono migrati solo dopo ai linguaggi ad oggetti. :p ma veramente manco per niente: se stiamo parlando del paradigma procedurale io con la programmazione a oggetti non ho disimparato un bel nulla visto che, come ti ho spiegato in un post precedente, in certi linguaggi orientati agli oggetti mi risulta del tutto inevitabile usare la composizione sequenziale. se invece stiamo parlando di una qualche fantomatica mentalitá allora largo alle pippe mentali.
fero86
11-04-2010, 20:22
Non hai colto la finesse... finge di non coglierla, fa fico :asd:
Mah, ti dirò, a metterla giù così non parrebbe un'idea poi così cattiva. quotone!! :D
Mah, ti dirò, a metterla giù così non parrebbe un'idea poi così cattiva. quotone!! :D
fero86
11-04-2010, 20:25
in tutto ció é bellissimo l'aggiornamento della firma di repne scasb :rotfl:
attenzione all'articolo poi :D
attenzione all'articolo poi :D
WarDuck
11-04-2010, 22:18
@fero: se intendi la complessità di un linguaggio solo come numero di costrutti che ha il linguaggio, ti faccio notare che non è di quel tipo di complessità che si stava parlando.
Imparare a programmare non significa imparare i costrutti di un linguaggio di programmazione, ma saperli usare a proprio vantaggio per risolvere un dato problema.
Un linguaggio di basso livello ti obbliga ad occuparti di aspetti che sono ben lontani dal problema che cerchi di risolvere.
Per questo la programmazione ad oggetti ha avuto, ha e continuerà ad avere enorme successo.
Imparare a programmare non significa imparare i costrutti di un linguaggio di programmazione, ma saperli usare a proprio vantaggio per risolvere un dato problema.
Un linguaggio di basso livello ti obbliga ad occuparti di aspetti che sono ben lontani dal problema che cerchi di risolvere.
Per questo la programmazione ad oggetti ha avuto, ha e continuerà ad avere enorme successo.
^TiGeRShArK^
11-04-2010, 22:51
gli errori off-by-one si possono commettere in qualunque linguaggio che fornisca gli array, compresi Python, Java e C#, solo che hanno conseguenze diverse. per il resto l'aritmetica dei puntatori mi pare che abbia una complessitá analoga a quella elementare: hai presente le sottrazioni e le addizioni, no?
Si, proprio uguali. :)
se manipolare le stringhe in C é difficile non é certo dovuto alla complessitá del linguaggio, ma al contrario é dovuto alla sua povertá. in C non puoi avere quella che in altri linguaggi é ad esempio la classe string.
Un linguaggio che ti deve fare manipolare un array per operare su delle stringhe è più complesso di uno che ti offre strumenti appositi e che DEVI conoscere se non vuoi rimanere fermo agli ani '80. :)
stesso discorso di prima.
stai degenerando :asd:
potremmo vedere qualche statistica da cui si evince che i programmatori sbagliano piu spesso usando il costrutto if? :D
mmm...
mai sentito parlare di "complessità ciclomatica", vero? :)
Mai utilizzato dei tool di code coverage sulla build machine che ti dicono quanti metodi sono coperti dai test e quanti branch? :)
Mai testato qualcosa quantomeno con junit o equivalenti?
questo é quello che dico anch'io. il discorso che tu non vuoi capire é che sono questi strumenti a fare la complessitá del linguaggio; lo renderanno anche piu facile da usare, senza dubbio (altrimenti che ci stanno a fare?), ma lo rendono piu difficile da imparare.
Ah, ok.
Quindi ora sarebbe + difficile fare "ciao".toUpper() che iterarsi tutto l'array e chiamare la funzione toupper carattere per carattere. :)
Devo avere uno strano concetto di semplicità io, mi avrà traviato il C# forse. :)
grazie per averci esposto la tua personalissima interpretazione del paradigma procedurale. detto questo vorrei farti presente che il paradigma procedurale per come lo si intende generalmente é assolutamente inevitabile nei linguaggi non funzionali, sia perché non puoi contare sulla tail-call optimization (che non viene imposta dalle specifiche e quindi programmare senza side-effects esaurirebbe lo stack di sistema) sia perché usare il paradigma funzionale causerebbe un grosso overhead sintattico (vedi Java, dove per avere qualcosa che ricordi vagamente una lambda expression devi implementare una anonymous inner class).
A parte che in C# le lambda expression si definiscono semplicemente così:
words.Where(w => w.length > 1);
senza crearsi anonymous inner class e menate varie.
Comunque la definizione di programmazione procedurale è la seguente:
A procedural programming language provides a programmer a means to define precisely each step in the performance of a task. The programmer knows what is to be accomplished and provides through the language step-by-step instructions on how the task is to be done. Using a procedural language, the programmer specifies language statements to perform a sequence of algorithmic steps.
Mentre per la programmazione ad oggetti abbiamo:
Object-oriented programming (OOP) is a programming paradigm that uses "objects" – data structures consisting of datafields and methods together with their interactions – to design applications and computer programs. Programming techniques may include features such as data abstraction, encapsulation, modularity, polymorphism, and inheritance.
Giusto per citare wikipedia che sta tanto simpatica a repne quanto gli sto simpatico io. :)
E da qui si evince che con Il C non impari a programmare, ma impari a programmare con un paradigma procedurale, che va bene ancora solo in pochi ambiti.
Dagli anni '90 in poi ha iniziato a diffondersi sempre di + la programmazione ad oggetti (quantomeno formalmente là in italia, ma vedendo quanti fan del C ci sono non mi stupisco del contrario).
Imparare a programmare con un linguaggio procedurale ti spinge a pensare in un modo "step-by-step" che è l'esatto contrario di come andrebbero affrontati i problemi con la programmazione ad oggetti.
Se la massima aspirazione di qualcuno è scrivere un driver, programmare dei microcontrollori o partecipare al kernel di linux, allora gli può anche andare bene, ma se uno vuole imparare a programmare nella più completa accezione del termine deve imparare la programmazione ad oggetti.
Se poi impara anche la programmazione funzionale tanto di guadagnato.
non hai risposto alla mia domanda. se non vuoi o non puoi non fa nulla, tanto era anche OT.
Non ne ho idea dato che io ho solo partecipato al pair-programming e l'ho visto scrivere quel codice. :)
So solo quello che ho già detto prima. :)
non lo metto in dubbio, ma resta la mia affermazione precedente. intendiamoci, C# é un linguaggio (anche) funzionale, ma LINQ da solo non basta a renderlo tale.
Mai detto il contrario.
Ma dipende dalla definizione.
Al C# mancano alcuni costrutti per essere un linguaggio funzionale completo, ma ciò non vuol dire che non possa utilizzare diversi paradigmi della programmazione funzionale.
altra tua personale interpretazione; in F# puoi sfruttare tanto il paradigma a oggetti quanto quello funzionale.
F# ha più costrutti funzionali rispetto al C#. :)
Vabbè che l'ho studiacchiato solo per gioco un annetto fa, ma non mi pare che C# abbia parole chiavi per definire funzioni ricorsive, la tail-recursion, e gli operatori per definire i valori di ritorno delle suddette funzioni come l'F#. :)
Si, proprio uguali. :)
se manipolare le stringhe in C é difficile non é certo dovuto alla complessitá del linguaggio, ma al contrario é dovuto alla sua povertá. in C non puoi avere quella che in altri linguaggi é ad esempio la classe string.
Un linguaggio che ti deve fare manipolare un array per operare su delle stringhe è più complesso di uno che ti offre strumenti appositi e che DEVI conoscere se non vuoi rimanere fermo agli ani '80. :)
stesso discorso di prima.
stai degenerando :asd:
potremmo vedere qualche statistica da cui si evince che i programmatori sbagliano piu spesso usando il costrutto if? :D
mmm...
mai sentito parlare di "complessità ciclomatica", vero? :)
Mai utilizzato dei tool di code coverage sulla build machine che ti dicono quanti metodi sono coperti dai test e quanti branch? :)
Mai testato qualcosa quantomeno con junit o equivalenti?
questo é quello che dico anch'io. il discorso che tu non vuoi capire é che sono questi strumenti a fare la complessitá del linguaggio; lo renderanno anche piu facile da usare, senza dubbio (altrimenti che ci stanno a fare?), ma lo rendono piu difficile da imparare.
Ah, ok.
Quindi ora sarebbe + difficile fare "ciao".toUpper() che iterarsi tutto l'array e chiamare la funzione toupper carattere per carattere. :)
Devo avere uno strano concetto di semplicità io, mi avrà traviato il C# forse. :)
grazie per averci esposto la tua personalissima interpretazione del paradigma procedurale. detto questo vorrei farti presente che il paradigma procedurale per come lo si intende generalmente é assolutamente inevitabile nei linguaggi non funzionali, sia perché non puoi contare sulla tail-call optimization (che non viene imposta dalle specifiche e quindi programmare senza side-effects esaurirebbe lo stack di sistema) sia perché usare il paradigma funzionale causerebbe un grosso overhead sintattico (vedi Java, dove per avere qualcosa che ricordi vagamente una lambda expression devi implementare una anonymous inner class).
A parte che in C# le lambda expression si definiscono semplicemente così:
words.Where(w => w.length > 1);
senza crearsi anonymous inner class e menate varie.
Comunque la definizione di programmazione procedurale è la seguente:
A procedural programming language provides a programmer a means to define precisely each step in the performance of a task. The programmer knows what is to be accomplished and provides through the language step-by-step instructions on how the task is to be done. Using a procedural language, the programmer specifies language statements to perform a sequence of algorithmic steps.
Mentre per la programmazione ad oggetti abbiamo:
Object-oriented programming (OOP) is a programming paradigm that uses "objects" – data structures consisting of datafields and methods together with their interactions – to design applications and computer programs. Programming techniques may include features such as data abstraction, encapsulation, modularity, polymorphism, and inheritance.
Giusto per citare wikipedia che sta tanto simpatica a repne quanto gli sto simpatico io. :)
E da qui si evince che con Il C non impari a programmare, ma impari a programmare con un paradigma procedurale, che va bene ancora solo in pochi ambiti.
Dagli anni '90 in poi ha iniziato a diffondersi sempre di + la programmazione ad oggetti (quantomeno formalmente là in italia, ma vedendo quanti fan del C ci sono non mi stupisco del contrario).
Imparare a programmare con un linguaggio procedurale ti spinge a pensare in un modo "step-by-step" che è l'esatto contrario di come andrebbero affrontati i problemi con la programmazione ad oggetti.
Se la massima aspirazione di qualcuno è scrivere un driver, programmare dei microcontrollori o partecipare al kernel di linux, allora gli può anche andare bene, ma se uno vuole imparare a programmare nella più completa accezione del termine deve imparare la programmazione ad oggetti.
Se poi impara anche la programmazione funzionale tanto di guadagnato.
non hai risposto alla mia domanda. se non vuoi o non puoi non fa nulla, tanto era anche OT.
Non ne ho idea dato che io ho solo partecipato al pair-programming e l'ho visto scrivere quel codice. :)
So solo quello che ho già detto prima. :)
non lo metto in dubbio, ma resta la mia affermazione precedente. intendiamoci, C# é un linguaggio (anche) funzionale, ma LINQ da solo non basta a renderlo tale.
Mai detto il contrario.
Ma dipende dalla definizione.
Al C# mancano alcuni costrutti per essere un linguaggio funzionale completo, ma ciò non vuol dire che non possa utilizzare diversi paradigmi della programmazione funzionale.
altra tua personale interpretazione; in F# puoi sfruttare tanto il paradigma a oggetti quanto quello funzionale.
F# ha più costrutti funzionali rispetto al C#. :)
Vabbè che l'ho studiacchiato solo per gioco un annetto fa, ma non mi pare che C# abbia parole chiavi per definire funzioni ricorsive, la tail-recursion, e gli operatori per definire i valori di ritorno delle suddette funzioni come l'F#. :)
^TiGeRShArK^
11-04-2010, 22:58
ampiamente smentito direi :D
Da chi? :)
e dovremmo inventarceli questi campi? in base a cosa dovremmo pensarli con la nostra testa? se ora ci mettiamo a fantasticare su come sia fatta la realtá non arriveremo lontano.
Intendevo che non è difficle capire in quali campi è utilizzato al giorno d'oggi il C, io stesso li ho citati, e sono sicuro che anche repne li conosca benissimo, solo che ha qualche difficoltà ad ammettere che con il C e l'assembly non puoi fare tutto dato che ci sono strumenti che ti permettono di essere ben + produttivo. :)
magari sbaglieró ma tu, francamente, non mi sai molto di laurea in Informatica: in genere gli Informatici imparano a "usare la testa" solo quando hanno a disposizione degli assiomi.
Mai detto di essere laureato in informatica. :)
Sono un ingegnere delle telecomunicazioni da ormai 5 anni e programmo da + o - 20 anni. :)
e quali sono i post di questo thread in cui hai scritto che ogni programmatore può trovarsi bene con un linguaggio o con l'altro, che un bravo programmatore non è uno che sa programmare qualsiasi cosa con un linguaggio solo, che una figura così è un programmatore esperto del tale linguaggio e che un bravo programmatore sa riconoscere, di fronte alle necessità e ai mezzi, quale sia il linguaggio migliore per la propria situazione e, all'occorrenza, rivolgersi a dei programmatori esperti di tale linguaggio? :D
Il linguaggio di programmazione è solo lo STRUMENTO, non è nulla di +.
E come meccanico col C ne stai usando uno che è specializzato ed essenziale in pochi casi, ma che nella stragrande maggioranza dei casi è poco funzionale o addirittura dannoso.
"The right tool for the right job" è la prima cosa da comprendere se si vuole programmare seriamente.
Essere fanboy di uno strumento non serve a niente.
Bisogna avere a disposizione quanti + strumenti possibile nella propria cassetta degli attrezzi e si devono utilizzare bene.
Credevo fosse chiaro il concetto, vorrà dire che la prossima volta lo spiegherò meglio. :)
Da chi? :)
e dovremmo inventarceli questi campi? in base a cosa dovremmo pensarli con la nostra testa? se ora ci mettiamo a fantasticare su come sia fatta la realtá non arriveremo lontano.
Intendevo che non è difficle capire in quali campi è utilizzato al giorno d'oggi il C, io stesso li ho citati, e sono sicuro che anche repne li conosca benissimo, solo che ha qualche difficoltà ad ammettere che con il C e l'assembly non puoi fare tutto dato che ci sono strumenti che ti permettono di essere ben + produttivo. :)
magari sbaglieró ma tu, francamente, non mi sai molto di laurea in Informatica: in genere gli Informatici imparano a "usare la testa" solo quando hanno a disposizione degli assiomi.
Mai detto di essere laureato in informatica. :)
Sono un ingegnere delle telecomunicazioni da ormai 5 anni e programmo da + o - 20 anni. :)
e quali sono i post di questo thread in cui hai scritto che ogni programmatore può trovarsi bene con un linguaggio o con l'altro, che un bravo programmatore non è uno che sa programmare qualsiasi cosa con un linguaggio solo, che una figura così è un programmatore esperto del tale linguaggio e che un bravo programmatore sa riconoscere, di fronte alle necessità e ai mezzi, quale sia il linguaggio migliore per la propria situazione e, all'occorrenza, rivolgersi a dei programmatori esperti di tale linguaggio? :D
Il linguaggio di programmazione è solo lo STRUMENTO, non è nulla di +.
E come meccanico col C ne stai usando uno che è specializzato ed essenziale in pochi casi, ma che nella stragrande maggioranza dei casi è poco funzionale o addirittura dannoso.
"The right tool for the right job" è la prima cosa da comprendere se si vuole programmare seriamente.
Essere fanboy di uno strumento non serve a niente.
Bisogna avere a disposizione quanti + strumenti possibile nella propria cassetta degli attrezzi e si devono utilizzare bene.
Credevo fosse chiaro il concetto, vorrà dire che la prossima volta lo spiegherò meglio. :)
^TiGeRShArK^
11-04-2010, 22:58
ma veramente manco per niente: se stiamo parlando del paradigma procedurale io con la programmazione a oggetti non ho disimparato un bel nulla visto che, come ti ho spiegato in un post precedente, in certi linguaggi orientati agli oggetti mi risulta del tutto inevitabile usare la composizione sequenziale. se invece stiamo parlando di una qualche fantomatica mentalitá allora largo alle pippe mentali.
Allora semplicemente non stai programmando ad oggetti. :)
Allora semplicemente non stai programmando ad oggetti. :)
^TiGeRShArK^
11-04-2010, 22:59
finge di non coglierla, fa fico :asd:
Beh, lei finge che io abbia finto di non coglierla, che fa ancora + fico. :asd:
Beh, lei finge che io abbia finto di non coglierla, che fa ancora + fico. :asd:
^TiGeRShArK^
11-04-2010, 23:01
in tutto ció é bellissimo l'aggiornamento della firma di repne scasb :rotfl:
attenzione all'articolo poi :D
beh, quale onore. :)
Ho praticamente la stessa importanza di Windows, Linux, Mac Os X e Wikipedia. :asd:
attenzione all'articolo poi :D
beh, quale onore. :)
Ho praticamente la stessa importanza di Windows, Linux, Mac Os X e Wikipedia. :asd:
PGI-Bis
11-04-2010, 23:56
Mentre per la programmazione ad oggetti abbiamo: ...
Quella definizione la prenderei con le pinze perchè se la usiamo per dividere l'insieme dei linguaggi di programmazione C risulta essere dalla parte sbagliata della barricata (quella OO).
In C non è solo possibile ma anche agevole creare pacchetti denominati di variabili e funzioni.
E' persino più facile che farlo in Java, C# o Smalltalk.
La partita della programmazione orientata agli oggetti (che è l'applicazione della prospettiva orientata agli oggetti) non si gioca con la creazione di pacchetti di funzioni e variabili ma sul collegamento dinamico tra i nomi di quei pacchetti e combinazioni diverse di funzioni e variabili.
Quello che rende C ostico da usare per la programmazione orientata agli oggetti è la mancanza di uno strumento ad hoc per collegare dinamicamente parti di un modulo a parti di altri moduli cio che permette di realizzare quella combinazione di definizioni che è l'anima della prospettiva orientata agli oggetti.
Quella definizione la prenderei con le pinze perchè se la usiamo per dividere l'insieme dei linguaggi di programmazione C risulta essere dalla parte sbagliata della barricata (quella OO).
In C non è solo possibile ma anche agevole creare pacchetti denominati di variabili e funzioni.
E' persino più facile che farlo in Java, C# o Smalltalk.
La partita della programmazione orientata agli oggetti (che è l'applicazione della prospettiva orientata agli oggetti) non si gioca con la creazione di pacchetti di funzioni e variabili ma sul collegamento dinamico tra i nomi di quei pacchetti e combinazioni diverse di funzioni e variabili.
Quello che rende C ostico da usare per la programmazione orientata agli oggetti è la mancanza di uno strumento ad hoc per collegare dinamicamente parti di un modulo a parti di altri moduli cio che permette di realizzare quella combinazione di definizioni che è l'anima della prospettiva orientata agli oggetti.
rеpne scasb
12-04-2010, 11:36
■
lupoxxx87
12-04-2010, 12:24
finchè seguiremo tutti lo spunto culturale italiano continueremo a litigare sostenendo che il nostro linguaggio sia il migliore di tutti....
perchè dire basta ? è nel nostro dna litigare per chi ha il prato più verde...
perchè dire basta ? è nel nostro dna litigare per chi ha il prato più verde...
gugoXX
12-04-2010, 12:45
C'è una cosa che non capisco...
Io ho cominciato con il visual basic 6 su windows, poi ho studiato su un libro di C su linux, e ho intenzione di imparare il C++...
Ora, è vero che con il C vieni seppellito da "segmentation fault, double delete, bug intermittenti", ma per imparare, non è questo quello che serve?
Faccio un paragone:
Se voglio diventare meccanico, non prendo un motore già fatto e lo metto nell'auto per farla camminare, perché così saprò fare andare l'auto, ma non avrò bene capito come funziona (che poi è il mio obbiettivo primario, no?).
Se invece assemblo io il motore, magari funzionerà male, ma avrò capito bene quali problemi ci sono dietro, e quindi come fa a funzionare!
Il paragone non e' analogo.
Nel mondo del lavoro oggi sara' davvero molto improbabile incontrare un segmentation fault, e raramente un memory leak, a meno che tu non lavori nelle nicchie dell'embedded o abbia bisogno di interfacciarti con librerie vecchie.
Non e' quindi necessario conoscere tali problemi secondari e i modi per evitarli, e le volte che proprio lo si dovra' fare ci si potra' concentrare, senza dover perdere tanto, tanto tempo prima. Tempo rubato all'approfondimento di concetti davvero importanti, come l'uso opportuno delle strutture dati migliori a seconda del problema che ci si pone davanti.
Alla fine tutti in C prima o poi studiano le hashtable. Ma sono talmente brutte da scrivere che si finisce sempre per non utilizzarle, e si rischia di reinventare la ruota ogni volta.
Anche solo concetti banali come le Liste vengono annegate nel rumore dei problemi.
Basti vedere come viene risolto tipicamente un problema come quello apparso pochi giorni fa: "Dati i valori 1-N, riempire un array disordinato contenente tali valori".
La soluzione proposta non sbagliata migliore era O(N^2), quando sapendo invece gestire le collezioni nel modo giusto si puo' arrivare a O(Log N)
Esattamente come un programmatore C non doveva conoscere problemi come
"In assembly Esistono gia' facility per trattare le moltiplicazioni e le divisioni per 10 in rappresentazione unpacked, usali quando possibile" (e oggi non farlo neppure piu')
oppure
"l'istruzione AAD di trattamento del resto nelle divisioni per 10, integrata nel 8086 distrugge la parte alta di AH anche se apparentemente non necessario"
oppure
"NEG e NOT sono diversi"
oppure
"Ricordati di verificare o settare il flag di direzione prima di usare le REP" (come appunto REPNE SCASB :) )
Eppure ci sono stati tanti sviluppatori C che tali concetti li hanno potuti evitare senza problemi.
Esattamente come si puo' essere buoni sviluppatori in linguaggi piu' moderni senza dover perdere tempo con concetti che non si incontreranno presumibilmente mai.
Concludo dicendo che anche secondo me il C non e' il linguaggio migliore per iniziare.
Io ho cominciato con il visual basic 6 su windows, poi ho studiato su un libro di C su linux, e ho intenzione di imparare il C++...
Ora, è vero che con il C vieni seppellito da "segmentation fault, double delete, bug intermittenti", ma per imparare, non è questo quello che serve?
Faccio un paragone:
Se voglio diventare meccanico, non prendo un motore già fatto e lo metto nell'auto per farla camminare, perché così saprò fare andare l'auto, ma non avrò bene capito come funziona (che poi è il mio obbiettivo primario, no?).
Se invece assemblo io il motore, magari funzionerà male, ma avrò capito bene quali problemi ci sono dietro, e quindi come fa a funzionare!
Il paragone non e' analogo.
Nel mondo del lavoro oggi sara' davvero molto improbabile incontrare un segmentation fault, e raramente un memory leak, a meno che tu non lavori nelle nicchie dell'embedded o abbia bisogno di interfacciarti con librerie vecchie.
Non e' quindi necessario conoscere tali problemi secondari e i modi per evitarli, e le volte che proprio lo si dovra' fare ci si potra' concentrare, senza dover perdere tanto, tanto tempo prima. Tempo rubato all'approfondimento di concetti davvero importanti, come l'uso opportuno delle strutture dati migliori a seconda del problema che ci si pone davanti.
Alla fine tutti in C prima o poi studiano le hashtable. Ma sono talmente brutte da scrivere che si finisce sempre per non utilizzarle, e si rischia di reinventare la ruota ogni volta.
Anche solo concetti banali come le Liste vengono annegate nel rumore dei problemi.
Basti vedere come viene risolto tipicamente un problema come quello apparso pochi giorni fa: "Dati i valori 1-N, riempire un array disordinato contenente tali valori".
La soluzione proposta non sbagliata migliore era O(N^2), quando sapendo invece gestire le collezioni nel modo giusto si puo' arrivare a O(Log N)
Esattamente come un programmatore C non doveva conoscere problemi come
"In assembly Esistono gia' facility per trattare le moltiplicazioni e le divisioni per 10 in rappresentazione unpacked, usali quando possibile" (e oggi non farlo neppure piu')
oppure
"l'istruzione AAD di trattamento del resto nelle divisioni per 10, integrata nel 8086 distrugge la parte alta di AH anche se apparentemente non necessario"
oppure
"NEG e NOT sono diversi"
oppure
"Ricordati di verificare o settare il flag di direzione prima di usare le REP" (come appunto REPNE SCASB :) )
Eppure ci sono stati tanti sviluppatori C che tali concetti li hanno potuti evitare senza problemi.
Esattamente come si puo' essere buoni sviluppatori in linguaggi piu' moderni senza dover perdere tempo con concetti che non si incontreranno presumibilmente mai.
Concludo dicendo che anche secondo me il C non e' il linguaggio migliore per iniziare.
clockover
12-04-2010, 14:57
Chissà se il creatore della discussione vi sta seguendo?
Secondo me, e lo dico da non programmatore (perchè non lo sono) ma da semplice studente, state diventando troppo pensanti! Cioè nel senso.... "si ma con il C non ci puoi andare nello spazio".... oppure "no perchè con il C non puoi creare una donna virtuale che non rompe".... ecc... Queste cose si faranno solo dopo anni di esperienza, e chi meglio di voi può dare conferma!
Dare un consiglio su quale possa essere un linguaggio per cominciare non è tutta sta roba che state dicendo!
Io ho cominciato all'università con Java.... e ho fatto Java! Poi sono arrivato al terzo anno e ho fatto il C (e porco zio non ci credo che ad una facoltà di ingegneria informatica il C al terzo anno)!
Secondo me cominciare con il C non è male! Certo dirai un sacco di parolacce all'inizio ma poi la soddisfazione viene! Ora come ora lo preferisco a Java, ma magari andando avanti, scoprendo nuovi linguaggi preferirò qualcos'altro!
Secondo me, e lo dico da non programmatore (perchè non lo sono) ma da semplice studente, state diventando troppo pensanti! Cioè nel senso.... "si ma con il C non ci puoi andare nello spazio".... oppure "no perchè con il C non puoi creare una donna virtuale che non rompe".... ecc... Queste cose si faranno solo dopo anni di esperienza, e chi meglio di voi può dare conferma!
Dare un consiglio su quale possa essere un linguaggio per cominciare non è tutta sta roba che state dicendo!
Io ho cominciato all'università con Java.... e ho fatto Java! Poi sono arrivato al terzo anno e ho fatto il C (e porco zio non ci credo che ad una facoltà di ingegneria informatica il C al terzo anno)!
Secondo me cominciare con il C non è male! Certo dirai un sacco di parolacce all'inizio ma poi la soddisfazione viene! Ora come ora lo preferisco a Java, ma magari andando avanti, scoprendo nuovi linguaggi preferirò qualcos'altro!
banryu79
12-04-2010, 15:13
Vorrei rammentare che i moderatori della sezione hanno apposta indicato una discussione ufficiale (è in rilievo) che si chiama "QUALE LINGUAGGIO SCEGLIERE ? (http://www.hwupgrade.it/forum/showthread.php?t=1979444)" con tanto di topic che descrive come postare in quella discussione.
Perchè tutti quelli che hanno postato dando le loro opinioni circa i diversi linguaggi non fanno un piccolo sforzo e provano a compilare per bene un post da sottoporre a quella discussione?
Ogni volta che un newbie di questa sezione apre una nuova discussione circa quale linguaggio scegliere per cominiciare a programmare per la prima volta potremmo provare a resistere all'impulso di dire la nostra in prima battuta e invece rimandare l'utente a quella discussione.
Sono sicuro ne gioverebbe a tutti.
Le fiammate sono utili quando fuori fa freddo, e siamo ormai entrati nella bella stagione :D
Perchè tutti quelli che hanno postato dando le loro opinioni circa i diversi linguaggi non fanno un piccolo sforzo e provano a compilare per bene un post da sottoporre a quella discussione?
Ogni volta che un newbie di questa sezione apre una nuova discussione circa quale linguaggio scegliere per cominiciare a programmare per la prima volta potremmo provare a resistere all'impulso di dire la nostra in prima battuta e invece rimandare l'utente a quella discussione.
Sono sicuro ne gioverebbe a tutti.
Le fiammate sono utili quando fuori fa freddo, e siamo ormai entrati nella bella stagione :D
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.