[Generale]Come si impara un linguaggio di programmazione?

[grigor91]

Spesso e volentieri appaiono discussioni su quale linguaggio sia meglio per iniziare a programmare, ma nessuno ha chiesto quale sia la scaletta che va seguita per imparare ad utilizzare un linguaggio, altrimenti si rischia di avere una conoscenza "a macchia di leopardo" che non è di nessuna utilità.
Aspetto pareri degli esperti :D

[grigor91]

Pensavo ci sarebbero state risposte a flotte.....
E' cosi difficile come domanda?:stordita:

[wizard1993]

domanda posta 4000 volte, usa il tasto cerca e troverai la risposta

[grigor91]

E no: Non ho chiesto con QUALE linguaggio iniziare, ma COME si studia un linguaggio di programmazione per creare programmi di livello medio/alto :)
Non penso che quando scelgo un linguaggio si debba studiarlo a casaccio: così le mie conoscenze sono solo una minestra da cui non ne cavo fuori niente.

[!fazz]

principalmente con un bel manuale poi tanta tanta pratica sbattendo la testa negli errori fino a che non si migliora gradualmente

[magix2003]

lo si studia -.-

[grigor91]

lo si studia -.-

Sì però se mi studio solo il linguaggio non mi serve a niente se non conosco le librerie del linguaggio, o i vari algoritmi utilizzati.

[blu_eye4]

Sì però se mi studio solo il linguaggio non mi serve a niente se non conosco le librerie del linguaggio, o i vari algoritmi utilizzati.

ti impari le cose basiliari e cerchi di sbatterci la testa finchè non riesci a risolvere un problema che ti trovi davanti, le librerie si imparano più tardi :asd... io non imparo programmazione a scuola, purtroppo, così mi leggo di tutto e quando sono fuori con gli amici mi capita spesso di ripensare ai listati di C... è passione, pura passione...

[grigor91]

Non ho capito una cosa: quali problemi?

[das]

Spesso e volentieri appaiono discussioni su quale linguaggio sia meglio per iniziare a programmare, ma nessuno ha chiesto quale sia la scaletta che va seguita per imparare ad utilizzare un linguaggio, altrimenti si rischia di avere una conoscenza "a macchia di leopardo" che non è di nessuna utilità.
Aspetto pareri degli esperti :D

- Scegli il linguaggio.
- Impari a scrivere 'hello world'
- impari come si usano i salti condizionati e i cicli for.
- impari a cosa servono le funzioni e le procedure della libreria standard
- impari a gestire i puntatori
- impari a programmare a oggetti.

[grigor91]

- Scegli il linguaggio.
- Impari a scrivere 'hello world'
- impari come si usano i salti condizionati e i cicli for.
- impari a cosa servono le funzioni e le procedure della libreria standard
- impari a gestire i puntatori
- impari a programmare a oggetti.

hmm.... come faccio a sapere da cosa è formata la libreria standard di un determinato linguaggio? Quella del C è facile da trovare, ma le altre?

[variabilepippo]

ma le altre?


Specifica il linguaggio di interesse e sarà possibile indicarti dove trovare la documentazione. Per esempio Java/C#/Python vengono distribuiti con una documentazione molto dettagliata delle classi standard.

[^TiGeRShArK^]

- Scegli il linguaggio.
- Impari a scrivere 'hello world'
- impari come si usano i salti condizionati e i cicli for.
- impari a cosa servono le funzioni e le procedure della libreria standard
- impari a gestire i puntatori
- impari a programmare a oggetti.
le due cose in grassetto sono assolutamente inutili e controproducenti per un linguaggio ad alto livello OOP.

[grigor91]

Specifica il linguaggio di interesse e sarà possibile indicarti dove trovare la documentazione. Per esempio Java/C#/Python vengono distribuiti con una documentazione molto dettagliata delle classi standard.

se è possibile tutti e tre :D

[variabilepippo]

C#: la documentazione è inclusa nel pacchetto .NET Framework SDK

Java SE: scarica il pacchetto Java 6 SE Documentation da http://java.sun.com/javase/downloads/index.jsp

Python: la distribuzione ActiveState Python (http://www.activestate.com/Products/activepython/index.mhtml) include una ricca documentazione sul linguaggio e sulla sua standard library.

[D4rkAng3l]

E no: Non ho chiesto con QUALE linguaggio iniziare, ma COME si studia un linguaggio di programmazione per creare programmi di livello medio/alto :)
Non penso che quando scelgo un linguaggio si debba studiarlo a casaccio: così le mie conoscenze sono solo una minestra da cui non ne cavo fuori niente.

Beh mi pare una domanda banale...prendi il manuale e lo leggi dall'inizio alla fine facendoti tutti gli esempi che ti riporta...a questo punto avrai una conoscienza didattica del linguaggio...nel senso che ne conoscerai un po' tutti gli aspetti ma non ci saprai fare nulla di concreto...quando ti ci dovrai mettere a lavorare allora dovrai trovare le soluzioni per il tuo problema...userai quindi documentazione online, forum, etcetc...per ora se non sai un cavolo di programmazione leggiti il manuale da pagina 1 fino alla fine :)

[grigor91]

Beh mi pare una domanda banale...prendi il manuale e lo leggi dall'inizio alla fine facendoti tutti gli esempi che ti riporta...a questo punto avrai una conoscienza didattica del linguaggio...nel senso che ne conoscerai un po' tutti gli aspetti ma non ci saprai fare nulla di concreto...quando ti ci dovrai mettere a lavorare allora dovrai trovare le soluzioni per il tuo problema...userai quindi documentazione online, forum, etcetc...per ora se non sai un cavolo di programmazione leggiti il manuale da pagina 1 fino alla fine :)

mah... secondo me non basta conoscere solo la sintassi di un linguaggio per poter creare programmi che non siano molto elementari :stordita:

[D4rkAng3l]

mah... secondo me non basta conoscere solo la sintassi di un linguaggio per poter creare programmi che non siano molto elementari :stordita:

OVVIO...infatti ti ho detto...prima ti impari la sintassi e la logica che stà dietro al linguaggio...poi quando inizzi a lavorarci in maniera professionale quando ti viene assegnato un compito da svolgere...ti trovi un modo per risolvere quel problema andandoti a vedere le librerie che dovrai usare e studiandotele sul momento...dopo tot progetti che hai fatto potrai dire di avere una discreta conoscienza del linguaggio.

Te lo hano già detto in molti cmq...altri metodi non esistono...se ti ostini a chiederlo è come se ci chiedessi di metterti la conoscienza dentro la tua testa eheh

[grigor91]

quindi si studia solo quando ne hai la necessità?
Vabbè, pensavo qualcosa di più sistematico e programmato, tipo prima studia la sintassi fino a quel punto... poi quella parte di librerie... poi quegli algoritmi.... .
Il problema è che a vedere i contest che ci sono in questa sezione è evidente che ci vuole molto di più che conoscere solo la sintassi di un programma o le sue librerie.

[D4rkAng3l]

quindi si studia solo quando ne hai la necessità?
Vabbè, pensavo qualcosa di più sistematico e programmato, tipo prima studia la sintassi fino a quel punto... poi quella parte di librerie... poi quegli algoritmi.... .
Il problema è che a vedere i contest che ci sono in questa sezione è evidente che ci vuole molto di più che conoscere solo la sintassi di un programma o le sue librerie.

beh i contest li risolve o gente che ha moltaaaa esperienza lavorativa o gente che oltre all'esperienza lavorativa ha studiato anche all'università.

Tipo da me all'uni studi programmazione in C (e fai la sintassi del C...scrivere programmini ed esercizietti stupidi: 2 esami)

programmazione orientata agli oggetti (2 esami, con linguaggio di riferimento Java...dove studi principalmente la logica della programmazione orientata agli oggetti e qualcosina di Java)

Un altro paio di esami con i framework

Poi c'hai 2 o 3 esami di algoritmi

etcetc

Il metodo sistematico è fare l'università dove studi tutto in maniera separata...per esempio un conto è studiare un algoritmo in Algoritmi e strutture dati, un altro conto è implementarlo in qualche linguaggio...nel primo corso studi l'algoritmo, ne dimostri la correttezza e ne calcoli la complessità...poi visto che hai studiato la sintassi e la logica di un linguaggio in altri corsi...beh lo applichi

E' questo il metodo di studio sistematico.

Però se come dice il tuo nick sei del 91...beh c'hai tempo ;)

[grigor91]

Però se come dice il tuo nick sei del 91...beh c'hai tempo ;)

Conoscerai il detto: "Chi ha tempo non aspetti tempo" :D
I miei dubbi derivano dal fatto che non vorrei perdere tempo a studiare dei costrutti che non userò mai salvo in casi rarissimi, tempo che potrei utilizzare per studiare argomenti ben + produttivi.
Se però mi dite che non c'è questo rischio mi studierò ben volentieri i vari manuali dei linguaggi :)

[D4rkAng3l]

Conoscerai il detto: "Chi ha tempo non aspetti tempo" :D
I miei dubbi derivano dal fatto che non vorrei perdere tempo a studiare dei costrutti che non userò mai salvo in casi rarissimi, tempo che potrei utilizzare per studiare argomenti ben + produttivi.
Se però mi dite che non c'è questo rischio mi studierò ben volentieri i vari manuali dei linguaggi :)

Beh i manuali sono le basi, sono proprio il minimo...senza aver studiato quelli non vai da nessuna parte...fai te

[shinya]

Io di solito faccio cosi:

- prima imparo a leggere (quindi guardo la documentazione ufficiale, e i sorgenti di qualche libreria)

- comincio a scrivere qualcosa di semplice: tipo i problemi più facili di spoj.pl o project-euler. Insomma, roba che conosci, di cui hai in testa la soluzione, e che devi solo esprimere in un altro modo.

- li riscrivo in modo più idiomatico possibile (chiedendo su irc o nei forum specializzati se la tal cosa è abbastanza idiomatica e come potrei migliorare).

- leggo qualche sorgente scritto bene

- leggo qualche sorgente scritto bene

- leggo qualche sorgente scritto bene

- scrivo qualcosa di più ampio, ma sempre non troppo complesso, che tocchi diversi aspetti, tipo un piccolo Game of Life (http://en.wikipedia.org/wiki/Conway's_Game_of_Life) con qualche funzionalità di base (tipo leggere qualche formato standard per questo gioco come .lif o .rle). Nel game of life c'è un pò di tutto: I/O da file, GUI, costrutti base e volendo multithreading. Il punto ovviamente non è scrivere una roba che funzioni e basta; il punto è scrivere una roba che funzioni e che sia idiomatico, in modo da imparare a "pensare" nel linguaggio X.

[© Rocky]

Io ho cominciato molto tempo fa con lo Spectrum della Sinclair, non conoscevo un accidente di nulla, (quasi come ora) :D
pensavo stupidamente che digitando qualsiasi domanda il computer mi desse la risposta, invece accendo lo Spectrum e non c'è altro che il cursore lampeggiante affamatissimo di codice Basic antidiluviano.
Ho trascorso molte nottate solo per disegnare una riga o un cerchio sullo schermo della TV 12 pollici.
Questo è stato il via. Dopo molto tempo ho acquistato l'Atari e via a studiare il GFA basic, libri presi in prestito dalla biblioteca seguìti da grande lettura e pacioccamenti sulla macchina.
Nel 1999 finalmente acquisto un PC serio con Windows 98 se, inizio col VB 6, spendo circa un milione di lire per acquisto di libri sull'argomento, dedico molto tempo per letture, prove, esperimenti ecc. :muro:
Oggi riesco a fare tutto ciò che desidero, salvo qualche volta che, pur sapendo le cose, non ricordo di saperle e quindi chiedo soluzioni ai Forum tipo Hardware Upgrade con grande figura di M.. interiore :rolleyes:
Inutile dire che i miei occhi sono partiti :eek:

Credo che, un linguaggio di programmazione, qualunque esso sia, ha un solo ostacolo, la nostra creatività e fantasia.

Buone festività :D

[grigor91]

Io di solito faccio cosi:

- prima imparo a leggere (quindi guardo la documentazione ufficiale, e i sorgenti di qualche libreria)

- comincio a scrivere qualcosa di semplice: tipo i problemi più facili di spoj.pl o project-euler. Insomma, roba che conosci, di cui hai in testa la soluzione, e che devi solo esprimere in un altro modo.

- li riscrivo in modo più idiomatico possibile (chiedendo su irc o nei forum specializzati se la tal cosa è abbastanza idiomatica e come potrei migliorare).

- leggo qualche sorgente scritto bene

- leggo qualche sorgente scritto bene

- leggo qualche sorgente scritto bene

- scrivo qualcosa di più ampio, ma sempre non troppo complesso, che tocchi diversi aspetti, tipo un piccolo Game of Life (http://en.wikipedia.org/wiki/Conway's_Game_of_Life) con qualche funzionalità di base (tipo leggere qualche formato standard per questo gioco come .lif o .rle). Nel game of life c'è un pò di tutto: I/O da file, GUI, costrutti base e volendo multithreading. Il punto ovviamente non è scrivere una roba che funzioni e basta; il punto è scrivere una roba che funzioni e che sia idiomatico, in modo da imparare a "pensare" nel linguaggio X.

Ti devo ringraziare perchè mi hai dato quei 2 siti che cercavo da tempo.
Però non capisco una cosa: in che senso bisogna controllare se un programma è idiomatico, o meglio non capisco come non possa esserlo.

[variabilepippo]

in che senso bisogna controllare se un programma è idiomatico, o meglio non capisco come non possa esserlo.


Non è "idiomatico" se usi costrutti e approcci tipici di altri linguaggi, senza sfruttare le caratteristiche proprie del linguaggio. Per esempio se programmi in C++ e non usi né STL, né IO streams né altre funzionalità specifiche del C++ allora non stai scrivendo "codice idiomatico". ;)

[grigor91]

Non è "idiomatico" se usi costrutti e approcci tipici di altri linguaggi, senza sfruttare le caratteristiche proprie del linguaggio. Per esempio se programmi in C++ e non usi né STL, né IO streams né altre funzionalità specifiche del C++ allora non stai scrivendo "codice idiomatico". ;)

Sarebbe come programmare in java mettendo tutto in una classe?

[grigor91]

Recupero questa mia discussione per fare una domanda:
Cosa serve ad un programmatore oltre a conoscere un linguaggio di programazione?

[cdimauro]

Taaaaaaaanta esperienza. E possibilmente un bel po' di teoria, che non guasta mai (almeno per rendersi conto delle implicazioni che comporta lo sviluppo del software).

[PGI-Bis]

Teoria e pratica, teoria e pratica, teoria e pratica. Agitare (mai mescolare!) per un cinque-sei anni di seguito, ogni giorno, non meno di quattro ore al giorno. Tutta la teoria, dall'orientamento agli oggetti alla gestione della memoria, dai database ai modelli di sviluppo software, algoritmi, analisi matematica - uhhh quanta analisi, ci finisci quasi in analisi dopo tutta quell'analisi.

Quando studi un linguaggi ti prendi uno, due tre libri su quel linguaggio, li leggi - non sia mai che si pensi che basti prenderli :D. Ripetutamente, leggi. Ci sono libri che a volte rileggendoli verrebbe da dire: "Ohilà, ma questo non è il libro che ho letto l'altra volta!". Poi c'è la rete che è una preziosa fonte di informazione con tutti i blog di personaggini mica da ridere, le mailing list degli sviluppatori, i whitepaper e gli studi pubblicati da aziende e università. C'è anche tanta monnezza ma quella di solito la distingui dopo un po' che pascoli per i prati telematici.

Ci sono i forum in cui puoi trovare spunti di riflessioni ma anche risposte. Ah, i forum. Ricordo quando mi avventurai le prime volte su quello ufficiale di Sun.

- Salve, sto imparando Java, avrei un dubbio su...
- LEGGI IL FOTTUTO MANUALE!!!

Ahhh, americani, sempre così affabili con i principianti...

[grigor91]

Riguardo alla teoria vorrei sapere quali siano le nozioni di base per poter programmare (naturalmente prendendo per scontato che si conosca già un linguaggio di programmazione)

[cdimauro]

Puoi cominciare con la teoria della computabilità, poi passare a quella della complessità, e approdare a quella dell'informazione.

[PGI-Bis]

e approdare a quella dell'informazione.

E fu così che si ritrovò giornalista...

:D

[Kralizek]

posta la conoscenza della sintassi di base, trovati un caso reale e buttatici a testa bassa...

a me ha aiutato tantissimo il sito del clan/gilda. A partire dall'ASP fino all'ASP.NET 3.5 ha passato tutte le versioni :P

[grigor91]

Puoi cominciare con la teoria della computabilità, poi passare a quella della complessità, e approdare a quella dell'informazione.

Grazie :) quando ho un po' di tempo cerco qualche libro.


Cercando in giro per internet ho trovato degli argomenti che vorrei approfondire, se qualcuno mi indicasse una scaletta per mettere in ordine in base alla difficoltà (e magari ne aggiungesse altri che ritiene utili) gli sarei molto grato :D

- codifica e compressione immagini e video
- strutture dati
- teoria dei linguaggi
- teoria dei compilatori

[banryu79]

Cercando in giro per internet ho trovato degli argomenti che vorrei approfondire, se qualcuno mi indicasse una scaletta per mettere in ordine in base alla difficoltà (e magari ne aggiungesse altri che ritiene utili) gli sarei molto grato :D

- codifica e compressione immagini e video
- strutture dati
- teoria dei linguaggi
- teoria dei compilatori

Io della scaletta che hai indicato considererei "strutture dati" affianacata a "algoritmi" (di solito vanno di pari passo) e terrei presente il fatto che, sebbene determinati settori usino un sub set specifico dei precedenti (ad esempio immagino che la voce "codifica e compressione immagini" includa indirettamente la conoscenza appunto di alcune strutture dati e algoritmi specifici) in generale fa bene conoscere almeno quelli più comuni.

Poi uno si specializza in un dato campo/contesto tecnologico.

[cdimauro]

Grazie :) quando ho un po' di tempo cerco qualche libro.

Cercando in giro per internet ho trovato degli argomenti che vorrei approfondire, se qualcuno mi indicasse una scaletta per mettere in ordine in base alla difficoltà (e magari ne aggiungesse altri che ritiene utili) gli sarei molto grato :D

- codifica e compressione immagini e video
- strutture dati
- teoria dei linguaggi
- teoria dei compilatori
La scaletta che ti consiglio è questa:
- strutture dati
- teoria dei linguaggi
- teoria dei compilatori
- codifica e compressione immagini e video.

Anche se come primo argomento io metterei sicuramente teoria della computabilità. Sarà pure un macigno, ma la trovo estremamente formativa.

[grigor91]

Teoria della computabilità che da quel che ho capito riguarda anche gli algoritmi, in accordo con il post di banryu.

[cdimauro]

Non esattamente. E' una materia estremamente teorica (http://it.wikipedia.org/wiki/Teoria_della_computabilità) (meglio la pagina in inglese, comunque).

[Kralizek]

se segue quella scaletta si annoia prima di scrivere un hello world però :P

[grigor91]

se segue quella scaletta si annoia prima di scrivere un hello world però :P

A dire la verità hello world l'ho scritto già da un pezzo :D
A settembre faccio la quinta in un istituto tecnico indirizzo informatico.

[Frank1962]

secondo me state esagendo un pò a fare i "Dottori Accademici" ....per un novizio suggerirgli di cominciare con l'Informatica Teorica è quanto di più sbagliato si possa fare!! .... cavolo ..e come se per uno che deve prendere la patente non solo gli venga suggerito di fare un corso di CAD per costruzione di motori e trasmissioni per autoveicoli ma anche un bel corso di termodinamica applicata da reperirsi nei corsi laurea di ingegneria meccanica :rolleyes: :rolleyes:

al giorno d'oggi ..vuoi imparare a programmare? uno/due manuali buoni, internet/forum/blog ecc.. e, sopratutto, tanta ma veramente tanta pazienza e tempo da dedicare a questa passione!

[Kralizek]

secondo me state esagendo un pò a fare i "Dottori Accademici" ....per un novizio suggerirgli di cominciare con l'Informatica Teorica è quanto di più sbagliato si possa fare!! .... cavolo ..e come se per uno che deve prendere la patente non solo gli venga suggerito di fare un corso di CAD per costruzione di motori e trasmissioni per autoveicoli ma anche un bel corso di termodinamica applicata da reperirsi nei corsi laurea di ingegneria meccanica :rolleyes: :rolleyes:

al giorno d'oggi ..vuoi imparare a programmare? uno/due manuali buoni, internet/forum/blog ecc.. e, sopratutto, tanta ma veramente tanta pazienza e tempo da dedicare a questa passione!

sottoscrivo!

[Tommo]

Non esattamente. E' una materia estremamente teorica (http://it.wikipedia.org/wiki/Teoria_della_computabilità) (meglio la pagina in inglese, comunque).

E lui dovrebbe leggersi questa roba prima di imparare a programmare? :asd:
Io so già programmare bene e non ci ho capito una mazza, figurarsi uno che non ne sa nulla :D

Inoltre è così teorico che ho serie difficoltà a capire cosa c'entri questo con l'atto di programmare una macchina.
Cioè, da quello che ho capito i problemi risolvibili davvero da un PC sono di diversi ordini di infinito minori rispetto a quelli computabili, ergo il problema non si pone davvero.

Che poi alla fine viene posta una scappatoia dicendo che "l'uomo può eseguire ogni computazione perchè non ha una natura algoritmica".
La frase puzza, perchè o si ammette un algoritmo, che per i fenomeni naturali per quanto infinitamente complesso esiste sempre o si sfocia nella fede.

Cmq è sicuramente interessante dal punto di vista filosofico... ma imho per leggersi un libro d'estate non per mettere le mani al codice.

[cdimauro]

Scusate, ma potreste anche leggerli i messaggi prima di rispondere. Grigor ha già imparato a programmare, e ha chiesto ALTRO.

Ora, mi rendo perfettamente conto che la teoria della computabilità non è certo una materia facile. L'ho anche detto. Ma a un informatico serve a capire quali sono i problemi "trattabili" da quelli "intrattabili".

"Sciocchezze", insomma, se ci aggiungiamo il fatto che si comprende meglio cos'è il software, cosa significa "codice" e "dato", e le loro implicazioni.

Tutte cose che si possono "saltare", non v'è dubbio: il programmino/one lo si realizza ugualmente anche senza, ci mancherebbe! Quanti programmatori sono passati dal foglio Excel o dal db di Access ad altri linguaggi di programmazione? Tantissimi!

Allo stesso modo, si può benissimo programmare senza andare a studiarsi quei noiosi algoritmi che ormai troviamo già implementati in quasi tutti i linguaggi di programmazione? A che serve conoscere il funzionamento dell'hash table? Degli alberi rosso-nero? Dei B-Tree? A nulla: è già tutto pronto, li usiamo "implicitamente".

Allora saltiamo anche questi, e dedichiamoci soltanto alla programmazione.

Poi, per chi ha tempo da perdere, c'è taaaanta pallosissima teoria "fine a se stessa". Che non va semplicemente letta, ma studiata, approfondita, meditata. Roba da nerd fino al midollo, insomma.

[PGI-Bis]

Programmare senza sapere la teoria è come cercare di fare un figlio senza un partner: fai una fatica dell'accidenti e non riesci a toglierti quella sensazione che per raggiungere l'obiettivo ti manca sempre qualcosa.

[Kralizek]

Scusate, ma potreste anche leggerli i messaggi prima di rispondere. Grigor ha già imparato a programmare, e ha chiesto ALTRO.

Ora, mi rendo perfettamente conto che la teoria della computabilità non è certo una materia facile. L'ho anche detto. Ma a un informatico serve a capire quali sono i problemi "trattabili" da quelli "intrattabili".

"Sciocchezze", insomma, se ci aggiungiamo il fatto che si comprende meglio cos'è il software, cosa significa "codice" e "dato", e le loro implicazioni.

Tutte cose che si possono "saltare", non v'è dubbio: il programmino/one lo si realizza ugualmente anche senza, ci mancherebbe! Quanti programmatori sono passati dal foglio Excel o dal db di Access ad altri linguaggi di programmazione? Tantissimi!

Allo stesso modo, si può benissimo programmare senza andare a studiarsi quei noiosi algoritmi che ormai troviamo già implementati in quasi tutti i linguaggi di programmazione? A che serve conoscere il funzionamento dell'hash table? Degli alberi rosso-nero? Dei B-Tree? A nulla: è già tutto pronto, li usiamo "implicitamente".

Allora saltiamo anche questi, e dedichiamoci soltanto alla programmazione.

Poi, per chi ha tempo da perdere, c'è taaaanta pallosissima teoria "fine a se stessa". Che non va semplicemente letta, ma studiata, approfondita, meditata. Roba da nerd fino al midollo, insomma.

ehi ehi... come dicono da queste parti, ta det lungt (che poi altro non é che "calm down" :P)
Sicuramente sono cose interessanti da studiare ma, stando all'OP, sembrava volesse un inizio sistematico ma di livello non cosí aulico! ;)



Spesso e volentieri appaiono discussioni su quale linguaggio sia meglio per iniziare a programmare, ma nessuno ha chiesto quale sia la scaletta che va seguita per imparare ad utilizzare un linguaggio, altrimenti si rischia di avere una conoscenza "a macchia di leopardo" che non è di nessuna utilità.
Aspetto pareri degli esperti :D

quindi si studia solo quando ne hai la necessità?
Vabbè, pensavo qualcosa di più sistematico e programmato, tipo prima studia la sintassi fino a quel punto... poi quella parte di librerie... poi quegli algoritmi.... .
Il problema è che a vedere i contest che ci sono in questa sezione è evidente che ci vuole molto di più che conoscere solo la sintassi di un programma o le sue librerie.


Forse ho frainteso io ;)

Programmare senza sapere la teoria è come cercare di fare un figlio senza un partner: fai una fatica dell'accidenti e non riesci a toglierti quella sensazione che per raggiungere l'obiettivo ti manca sempre qualcosa.

Vero, ma insegneresti mai ad un bimbo di 5 anni a giocare a pallone spiegandogli le sovrapposizioni ed il fuorigioco? Certo la teoria serve, ma il piacere di programmare almeno per me é fondamentale.
Poi vabbé, io sono un caso estremo perché dico che mi pagano non per programmare in sé ma per sopportare il reparto vendite e quello informazioni durante l'orario di lavoro (durante sono invece decisamente un "bel vedere" :oink: )

[grigor91]

Già a scuola qualcosa di teorico sui sistemi e sugli automi a stati finiti abbiamo fatto, comunque se ho chiesto suggerimenti è perchè, essendo a conoscenza del livello di difficoltà, credo sia indispensabile un approccio il più possibile lineare.

Oltretutto come carattere quando imparo una cosa voglio sapere nel dettaglio come funziona.
(Anche utilizzare codice auto-generato mi innervosisce :D )

[Tommo]

Scusate, ma potreste anche leggerli i messaggi prima di rispondere. Grigor ha già imparato a programmare, e ha chiesto ALTRO.

Ora, mi rendo perfettamente conto che la teoria della computabilità non è certo una materia facile. L'ho anche detto. Ma a un informatico serve a capire quali sono i problemi "trattabili" da quelli "intrattabili".

"Sciocchezze", insomma, se ci aggiungiamo il fatto che si comprende meglio cos'è il software, cosa significa "codice" e "dato", e le loro implicazioni.

Tutte cose che si possono "saltare", non v'è dubbio: il programmino/one lo si realizza ugualmente anche senza, ci mancherebbe! Quanti programmatori sono passati dal foglio Excel o dal db di Access ad altri linguaggi di programmazione? Tantissimi!

Allo stesso modo, si può benissimo programmare senza andare a studiarsi quei noiosi algoritmi che ormai troviamo già implementati in quasi tutti i linguaggi di programmazione? A che serve conoscere il funzionamento dell'hash table? Degli alberi rosso-nero? Dei B-Tree? A nulla: è già tutto pronto, li usiamo "implicitamente".

Allora saltiamo anche questi, e dedichiamoci soltanto alla programmazione.

Poi, per chi ha tempo da perdere, c'è taaaanta pallosissima teoria "fine a se stessa". Che non va semplicemente letta, ma studiata, approfondita, meditata. Roba da nerd fino al midollo, insomma.

Guarda che mi trovi d'accordo, non suggerivo affatto un percorso "terra-terra" :asd:
Solo che quello che hai proposto mi sembrava decisamente troppo "elevato", tanto più se non viene accompagnato da un approfondimento della pratica (si può imparare anche con 30 anni di esperienza, non credo che l'OP possa dire di "sapere tutto").
Per esempio saper reimplementare una hash-table o roba del genere è spesso utile, perchè quelli che ti forniscono altri sono per loro natura generici o poco performanti... mentre invece il teorema di Incompletezza di Godel per quanto filosoficamente interessante non vedo che c'entri con una CPU.

[cdimauro]

Serve a capire cosa NON può fare una CPU. ;)

[Tommo]

Serve a capire cosa NON può fare una CPU. ;)

Una CPU illimitatamente potente montata su una memoria infinita... è un modello così banale che è quasi inutile IMHO.
Come pretendere di studiare una centrale elettrica coi circuiti RLC del liceo.
Gli algoritmi che può svolgere realisticamente sono un subset drammaticamente limitato di quelli computabili, e mi riesce difficile credere che le miriadi di HW esistenti oggi rientrino in tutto e per tutto nel modello della macchina di Turing...
inoltre se una CPU non può fare una cosa questa è drammaticamente pesante/complicata/cervellotica e si capisce anche intuitivamente.
Per dire, non mi son mai trovato a dire "cavolo ho pensato un algoritmo che la CPU non può fare" :asd:

[cdimauro]

Finché c'è gente convinta che i programmi si possano realizzare privi di bug, c'è sempre spazio per lo studio della teoria della computabilità. ;)

P.S. Ovviamente non mi riferisco a te. :)

[Tommo]

Finché c'è gente convinta che i programmi si possano realizzare privi di bug, c'è sempre spazio per lo studio della teoria della computabilità. ;)

P.S. Ovviamente non mi riferisco a te. :)

No gombrendo :stordita:
:asd:

[PGI-Bis]

Finché c'è gente convinta che i programmi si possano realizzare privi di bug

Eccomi.

public class Main {
public static void main(String[] args) {
System.out.println("hello world");
}
}

Quanti bug ha? Se ne ha zero allora la teoria che i programmi non possano essere privi di bug è falsa.

[Kralizek]

Eccomi.

public class Main {
public static void main(String[] args) {
System.out.println("hello world");
}
}

Quanti bug ha? Se ne ha zero allora la teoria che i programmi non possano essere privi di bug è falsa.

dipende, se si intende per bug anche la possibilità che la JVM non abbia memoria disponibile per allocare la stringa "hello world", beh, è un bug.

E ad ogni modo del codice java/.net così semplice sai bene che comporta tanto codice alle spalle che potrebbe nascondere un bug.

Fosse stato scritto in qualche linguaggio che viene compilato nativamente... beh allora le probabilità crollano...

[PGI-Bis]

Una teoria se vale vale per tutto. Quello lì da solo è un programma fatto e finito. E' o non è privo di bug?

Ps: la JVM non c'entra. Il linguaggio di programmazione Java è del tutto indipendente dalla macchina virtuale Java.

[cdimauro]

L'esempio che hai portato riguarda questo (http://it.wikipedia.org/wiki/Macchina_che_termina_sempre).

Io mi riferivo a quest'altro (http://it.wikipedia.org/wiki/Macchina_di_Turing#Il_problema_dell.27arresto_e_la_sua_indecidibilit.C3.A0). :O

[PGI-Bis]

Halting problem? Se sì, no. Perchè non dice che non sia possibile scrivere programmi privi di bug.

[cdimauro]

Dice che non è possibile scrivere un'applicazione che, data una qualunque applicazione, determini se si arresta o meno.

Dove arrestare lo possiamo interpretare come assenza di bug (sto semplificando: so benissimo che si può arrestare e non calcolare correttamente il risultato), mentre il mancato arresto indica la presenza di bug.

Per programmi banali si può provare facilmente se un'applicazione ha o meno bug (specialmente se è riconducibile a una "funzione ricorsiva primitiva").

Per programmi più "complicati" (quindi sicuramente NON funzioni ricorsive primitive) no.

Esempio. Prendiamo i sorgenti di Java e posto che ti sia concesso il tempo per leggerli tutti quanti: mi sapresti dire, poi, con assoluta certezza che siano del tutto privi di bug? :O

[marco.r]

L'esempio che hai portato riguarda questo (http://it.wikipedia.org/wiki/Macchina_che_termina_sempre).

Io mi riferivo a quest'altro (http://it.wikipedia.org/wiki/Macchina_di_Turing#Il_problema_dell.27arresto_e_la_sua_indecidibilit.C3.A0). :O

Basta scegliere un modello che non sia la macchina di turing...

[cdimauro]

Ma i linguaggi che usiamo generalmente sono Turing-completi.

[PGI-Bis]

Il problema non è se l'applicazione sia piccola o grande, se sia Hello World o tutto il codice di Windows. Il problema è che non è possibile dimostrare nello stesso modo che la decidibilità del programma "Hello World" valga anche per il programma "Windows". O è possibile ma allora non sarà possibile dimostrare che il programma "JVM" sia decidibile nello stesso modo di "Hello World" e "Window". O magarì per quei tre vale ma...eccetera eccetera...ci sarà sempre almeno un programma la cui decidibilità non è dimostrabile come lo è per tutti gli altri.

Non dice affatto che uno specifico programma sia dimostrabilmente privo di bug.

Questo per come l'ho capita io: la faccenda è molto complicata.

[cdimauro]

E lo è sicuramente. Il nocciolo della questione è che non è possibile realizzare un'applicazione che sia in grado di decidere se una qualunque altra applicazione sia bacata o meno (senza tirare in ballo il concetto di arresto).

Quindi è una questione prettamente programmatica o, usando un termine caro a noi programmatori, di automazione di questo tipo di calcolo, che è irrealizzabile.

Su singole, specifiche, applicazioni la questione è decidibile o meno, a seconda se riusciamo a produrre una dimostrazione.
Quindi data l'applicazione f e l'input x provare che il calcolo viene completato (non c'interessa il tempo, purché sia sicuramente finito) e l'output sia effettivamente y (quello che ci aspettavamo).

Questo sul piano formale rimanendo nell'ambito della pura teoria della computabilità.

Nella realtà, invece, la situazione è anche peggiore, perché valgono anche le considerazioni di Kralizek, per cui anche il tuo banalissimo "Hello, world!" può risultare bacato, a seconda delle condizioni esistenti al momento della sua esecuzione.

[Kralizek]

E lo è sicuramente. Il nocciolo della questione è che non è possibile realizzare un'applicazione che sia in grado di decidere se una qualunque altra applicazione sia bacata o meno (senza tirare in ballo il concetto di arresto).

Quindi è una questione prettamente programmatica o, usando un termine caro a noi programmatori, di automazione di questo tipo di calcolo, che è irrealizzabile.

Su singole, specifiche, applicazioni la questione è decidibile o meno, a seconda se riusciamo a produrre una dimostrazione.
Quindi data l'applicazione f e l'input x provare che il calcolo viene completato (non c'interessa il tempo, purché sia sicuramente finito) e l'output sia effettivamente y (quello che ci aspettavamo).

Questo sul piano formale rimanendo nell'ambito della pura teoria della computabilità.

Nella realtà, invece, la situazione è anche peggiore, perché valgono anche le considerazioni di Krallo, per cui anche il tuo banalissimo "Hello, world!" può risultare bacato, a seconda delle condizioni esistenti al momento della sua esecuzione.

fixed, so che é stupido, ma Kralizek é troppo "ufficiale", un po' come se mi chiamassi "sig. Nome Cognome" :P

[cdimauro]

OK, Krallo. :p

[banryu79]

Credo sia neccessario, per chiarezza, considerare sempre il linguaggio in cui è espresso il programma in questione.

[1]
Come si legge in quelle pagine di Wikipedia, un Decider (macchina che termina sempre) è meno potente di una MdT, però non soffre del problema della fermata (che anzi garantisce sempre).

Il fatto è che un Decider ha a che fare con programmi espressi in linguaggi ricorsivi.

La MdT invece, ha a che fare con linguaggi ricorsivamente enumerabili e c'è il problema della fermata.
Per come l'ho capita io, le implicazioni di questo teorema non sono che "non è mai possibile determinare se un programma terminerà in un tempo finito" o meno, ma soltanto(si fa per dire) che "non è possibile realizzare un algoritmo che riesca a determinare se un programma terminerà o no, per qualsiasi programma espresso in un linguaggio ricorsivamente enumerabile ci venga in mente".

[2]
Prendendo l'esempio di PGI:

public class Main {
public static void main(String[] args) {
System.out.println("hello world");
}
}

Questo programma è un esempio di programma che, seppur scritto in un linguaggio ricorsivamente enumerabile (Java) non presenta operazioni che ne rendano impossibile determinare quando terminerà.

Cito un passaggio importante:

In pratica, è possibile costruire una macchina che termini sempre, e già computa molte funzioni interessanti, come da esempio, quando si limita le capacità di controllo di flusso così che nessun programma farà entrare la macchina in un ciclo infinito. Come esempio banale, un albero di decisione finito non contiene cicli, così termina naturalmente. Non si richiede che la macchina non abbia capacità di svolgere cicli. Se si limitano i cicli ad un ben definito limite prevedibile (come il ciclo FOR in BASIC), possiamo esprimere tutte le funzioni ricorsive primitive (Meyer and Ritchie, 1967). Un esempio di tale macchina è fornito dal linguaggio di programmazione giocattolo PL-{GOTO} di Brainerd e Landweber (1974).


Quindi come una MdT, per determinati programmi, non riesce "a consumare" tutto il flusso di esecuzione a tal punto da riuscire a dire che il programma terminerà oppure entrerà in un ciclo infinito senza prima esserci entrata lei stessa nel ciclo infinito, così non è (secondo me) possibile garantire con un algoritmo che un programma scritto in un linguaggio Turing-completo sia privo di bug, proprio perchè quell'algoritmo deve essere mandato in esecuzione con il modello di calcolo della MdT stessa, soffrendo dei limiti associati al problema della fermata.

Certo ciò non significa che "è impossibile scrivere un programma privo di bug" ma solo che "è impossibile provare, per qualsiasi programma espresso in un linguaggio ricorsivamente enumerabile, eseguito da una MdT, che quel programma è privo di bug".

O almeno è quello che ho capito io.
Come ha detto marco.r, forse bisogna passare ad un altro modello diverso da quello della MdT.

[Kralizek]

certo che a studiare teoria della computazione, leopardi si sarebbe sparato una dose endovena. "questa roba" (cit.) é piú pessimista di lui



(tralasciamo che in realtá lui fosse un ottimista secondo alcuni critici letterari, per la massa lui é Il Pessimista)

[cdimauro]

E non avrebbe avuto tutti i torti. :D

Comunque le macchine che terminano sempre (decider) risolvono soltanto una parte dei problemi formalizzabili sotto forma di algoritmi. Non possono, pertanto, computare tutti i tipi di problemi che una macchina Turing-completa (o equipotente che dir si voglia) è in grado di risolvere.

Se praticamente tutti i linguaggi di programmazione conosciuti sono Turing-completi non è certo per capriccio, ma perché serve la loro "potenza espressiva".

Per quanto riguarda il problema di bug / terminazione & affini, è corretta l'interpretazione di banryu (e di PGI in precedenza), ma... anche l'osservazione di monsieur Krallo. ;)

[~FullSyst3m~]

Teoria e pratica, teoria e pratica, teoria e pratica. Agitare (mai mescolare!) per un cinque-sei anni di seguito, ogni giorno, non meno di quattro ore al giorno. Tutta la teoria, dall'orientamento agli oggetti alla gestione della memoria, dai database ai modelli di sviluppo software, algoritmi, analisi matematica - uhhh quanta analisi, ci finisci quasi in analisi dopo tutta quell'analisi.

Quando studi un linguaggi ti prendi uno, due tre libri su quel linguaggio, li leggi - non sia mai che si pensi che basti prenderli :D. Ripetutamente, leggi. Ci sono libri che a volte rileggendoli verrebbe da dire: "Ohilà, ma questo non è il libro che ho letto l'altra volta!". Poi c'è la rete che è una preziosa fonte di informazione con tutti i blog di personaggini mica da ridere, le mailing list degli sviluppatori, i whitepaper e gli studi pubblicati da aziende e università. C'è anche tanta monnezza ma quella di solito la distingui dopo un po' che pascoli per i prati telematici.

Ci sono i forum in cui puoi trovare spunti di riflessioni ma anche risposte. Ah, i forum. Ricordo quando mi avventurai le prime volte su quello ufficiale di Sun.

- Salve, sto imparando Java, avrei un dubbio su...
- LEGGI IL FOTTUTO MANUALE!!!

Ahhh, americani, sempre così affabili con i principianti...

Questa dell'agitare 4 ore al giorno per 5/6 anni non me l'avevi mai detta... mi hai dato pacco in pratica :D

Poi tu che andavi nei forum?? :eek: :eek: