AmigaCori ha scritto:Beh, da principiante ti posso dire che la ricorsione sembra una pratica magica...arrivi fino all'ultimo caso e poi si richiude tutto all'indietro fornendo il risultato, mi sa di gioco
In realtà la ricorsione può anche essere fatta meglio eh :)
Tipicamente una buona ricorsione *non* richiude alla fine, ma è fatta in modo tale che possa sempre riusare lo stesso stack frame (con efficienza pari ad un ciclo). Non è sempre possibile, ma spesso si.
> Pero' ho visto vari esempi ed in effetti e' molto naturale applicare il
> ragionamento della ricorsione, anche se devo ancora afferrare bene il
> concetto.
Studiando un po' di algoritmi e strutture dati lo afferri per forza.
> Non capisco...anzi credo di non sapere... "./pluto" non significa
esegui
> pluto? ovviamente se pluto e' eseguibile.
No. ./pluto vuole dire la stessa cosa di src/pluto, foo/pluto etc.
Ovvero esegui l'eseguibile pluto dentro la directory . (che è la directory corrente).
Qualifica pluto. Potresti avere anche un pluto nel PATH e lui eseguirebbe 'questo qui'.
> Se io ho pluto.cc, poi compilo ed ho pluto.out, per eseguire pluto.out,
> non devo digitare
./pluto.out?
E' un modo. Poi nessuno mette estensione .out ai files che non siano a.out, eh. :)
> Buono per iniziare pero', anche se secondo me Rebol e' portentoso per
> un megaprincipiante di programmazione: con due righe crei le prime
> finestrelle colorate!
E' una questione dibattuta. Io non sono completamente convinto che ammazzare il principiante di dettagli lo aiuti. In primo luogo lo costringe a cose veramente giocattolose, in secondo luogo gli impedisce di assumere una visione d'insieme.
Lasciando stare le finestre, io pure sono per un approccio più di alto livello. Tanto per vedere un po' cosa si può fare *e* fare qualcosa di utile.
> Intendo che ho meno *paroline* magiche (comandi cfr. sotto) da tenere
> a mente, e' come avere solo 5 lego differenti per costruire una casa e
> quindi devo solo ragionare sul come incastrare i lego.
Non sono convinto che il paragone regga. Poi chiarifico.
Tipicamente i linguaggi di basso livello come il C fanno perdere di vista la programmazione proprio perchè fanno perdere dietro una serie di dettagli implementativi che tipicamente non si vorrebbe gestire fin da subito.
Tipicamente se vedi mattoni e devi costruire case hai un problema. Rischi di essere troppo preso a costruire il muro dritto e o non finisci la casa oppure fai una casa bruttina. :)
> Si..si...ho capito cosa vuoi dire, ma sono cose *avanzate* che ad un
> vero principiante balzerebbero solo come complesse, ovvero tante cose > da imparare prima di vedere qualcosa di concreto.
Mi spiego... pensa a questo compito cretino. Prendi e vai a sostituire a tutti i files contentuti 'ricorsivamente' nella directory corrente che si chiamano 'Root' e sostituisci al loro interno la parola foo con la parola bar.
Ecco... questa è una cosa cretina che ho dovuto fare questa mattina (ho spostato un repository CVS). Ho risolto in 30 secondi con suppongo 5 righe di python (tra l'altro buttate in un'interprete interattivo). Avrei potuto pure farlo a suon di zsh e sed, per dire, ma avrei dovuto pensarci.
Immaginati di farlo in C...
Il bello di 'saper programmare' è quello di sapersi risolvere i problemi, sapere scrivere qualcosa che ci serve. Partire da C è IMHO contro questa filosofia, ecco tutto.
In pratica in un linguaggio di basso livello come C per fare qualunque cosa ci va un sacco di codice. E i principianti sbagliano più dei professionisti, per cui c'è anche il caso che rimangano frustrati *prima* di avere finito.
C ti nasconde gli errori: per cui appena superi le poche righe devi imparare *anche* il debugger. Per dire. E così via.
> Comunque non credo di poter capire cosa dici, io proprio non ho
> presente lo scenario del programmatore. sono solo felice che ci siano
> pochi *comandi* cosi' il mio cervello si trova a rigirare tra quei 3-4
> mezzi messi a disposizione dal C.
Vedi sotto.
> Non mi fare il professore ora!
> Allora, riko, ti levo subito il dubbio: il Deitel chiama
comando
> for...while....if... e dice:
le istruzioni all'interno del corpo del
> comando for...; mentre:
continue usata all'interno di
>
switch la chiama istruzione continue...
> Quando ho scritto comandi, intendevo quelle paroline particolari che il C
> si riserva e che io non posso usare, con istruzione invece intendo la
> *frase* dove descrivo al computer, tramite comandi e non solo, l'azione
> da compiere.
Allora il significato di comando di deitel è corretta. E' quello che in inglese si chiama statement (ovvero 'frase'). Quasi tutti i linguaggi 'moderni' hanno pochi *comandi*. Alcuni non hanno nemmeno il concetto di statement (perchè tutto è un'espressione).
In generale si può fare tutto con roba di libreria. Come è giusto e come fa anche il C. La differenza è su quanto esplicito devi essere.
> Quindi un programma sara' un insieme di istruzioni, all'interno delle
> istruzioni ci possono essere dei comandi, per esempio un'istruzione di
> assegnamento non contiene alcun comando.
Il concetto di 'istruzione' non è in effetti corretto (o meglio, non è preciso). Usa pure statement o comando. L'assegnamento in C è un espressione (e può stare ovunque stia un espressione, per quanto assurdo possa essere).
In C c'è il cosidetto ;-statement che trasforma un'espressione in uno statement. BTW, anche la chiamata di funzione è un'espressione. Quando scrivi printf(...); stai facendo esattamente questo. Hai lo statement; che 'contiene' un'espressione.
> Nooooooooooooooooooooooooo!
non me lo dire che lascio
> perdere subito il C!!!
Questione di gusti. Io per un principiante suggerisco Ruby o Python a scelta tua e di quanto sei 'modaiolo' :)
> Appunto...il C++ e' complesso per iniziare, il C non va bene per il C++,
> il Java peggio mi sento...insomma, dovrei iniziare dal Basic?...no
> perche' cosi manderei aff...quelpaese la programmazione strutturata
>
insomma come faccio, faccio male....
No, affatto. Aggiungo anche il PHP meglio dimenticarlo. Finito questo hai un *sacco* di scelta. Basic purtroppo vuole dire poco e nulla. E' più una famiglia di linguaggi che altro.
IMHO i linguaggi più belli da usare fra quelli procedurali/imperativi sono Python e/o Ruby. Sono estremamente facili, lineari e potenti. Per di più puoi usarli per quasi tutto, dal calcolo scientifico (ma in questo molto meglio Python) al web allo scripting di sistema alle gui.
Rebol non mi pare male, ma non lo conosco bene. Poi ci sono i linguaggi funzionali, ma se la semplice ricorsione ti mette in difficoltà... meglio evitare (visto che in molti casi hai *solo* la ricorsione).
Potrebbe essere interessante anche Objective Pascal (Lazarus). Ma resta IMHO ben più complesso di Python o Ruby. Ma è carino da usare, io però non lo conosco affatto bene.
> L'unica cosa che vorrei fare con un certo interesse e' I/O con dispositivi
> esterni: acquisizione dati e pilotaggio accrocchi elettronici.
Puoi provare imparare Python. Ci sono diverse librerie comode per questo. Poi C può davvero essere la scelta giusta, ma ribadisco, didatticamente IMHO è meglio il contrario.
> A cosa mi serve il C++?, perche' mi sembra d'aver capito che e' un
> modo migliore di programmare, un po' come quando si comprese che il
>
go to era sbagliato e c'era un modo migliore di fare le cose.
E' un modo di programmare. Il 'migliore' lo lascio mettere ad altri. Io non mi trovo male in C++. Ma fai conto che per usarlo *bene* devi lavorarci *tanto*. E dubito che senza un eccellente professore (o esperienza) le cose siano facili.
Tipicamente la maggior parte delle persone usano C++ talmente male che sarebbe meglio che usassero altro. :)
)
