Linguaggio di programmazione per cominciare

[giuseppemag]

In effetti anche io al corso di Fondamenti di Informatica 1 ho fatto ricorsione e accenni alla complessità e gli invarianti senza dover passare necessariamente per il primo corso di Algoritmi e Strutture Dati. Il problema è che il ragazzino in questione non ha 19 anni ma 13, quindi secondo me sarebbe un pochino pesante e di difficile comprensione iniziare con argomenti così "formali". Però è vero che secondo me discutere su quale linguaggio imperativo sia il migliore con cui iniziare è un po' inutile, per l'appunto come ho suggerito sarebbe utilie fargli conoscere linguaggi procedurali e funzionali e che sia poi lui a scegliere quelli che lo attirano di più.

Si, ma infatti secondo me insistere sulle cose imperative ha il difetto che è molto difficile insegnare questi fondamenti che emergono in maniera naturale (ma soprattutto informale e implicita) con altri linguaggi...

Ad esempio linguaggi visuali di programmazione reattiva/funzionale come http://research.microsoft.com/en-us/projects/kodu/ sono molto interessanti da questo punto di vista...

[Recidivo Visual]

In generale ci sono molti studi su come insegnare in modo "engaging" l'informatica, e raramente passano per il benedetto manuale di C di K&R...

HAaaaaa!
Questa e' basfemia.
Questa e' follia.
:sparta:

-----

Linguaggio C
di Kernigham Brian W. e Ritchie Dennis M.

Non e' un manuale ma la bibbia del C.
Roba che la devi sapere a memoria, anzi meglio.
Perche'?
Se l'hai letto ( il libro ) lo dovresti sapere.
Del tipo, cosa contiene il primo capitolo?

ecco, contiene concetti che prima li impari e ne apprendi significato e funzione, prima cominci a capire cosa vuol dire programmare e non sono di certo la ricorsione o le strutture, ma rullo di tamburi:
- Le variabili e i costrutti.

A 13 anni, se impara bene questo parte avvantaggiato, in barba a office, vba e sql, che scuramente avra' tempo per imparare.

P.S. Ma io ti voglio bene, e tu lo sai.

capirai ugualmente che in quell'1% residuo hai comunque bisogno di un esperto del ramo (che puoi trovare facilmente e a buon prezzo perchè son dappertutto)

Non c'e' cosa piu' sbagliata.
Si, di programmatori ce n'e' tanti e a buon prezzo.
Perche' c'e' tanta gente che sapendo scrivere un pezzetto di vba per office crede di essere programmatore.
Di programmatori bravi, non ce n'e' tanti e quelli che ci sono hanno gia' lavoro, quindi i tempi vanno a 60-90 giorni.

P.S. Anche a te volgio bene, ma un pochino meno.

[BlackCaesar]

HAaaaaa!
Questa e' basfemia.
Questa e' follia.
:sparta:

ecco, contiene concetti che prima li impari e ne apprendi significato e funzione, prima cominci a capire cosa vuol dire programmare e non sono di certo la ricorsione o le strutture, ma rullo di tamburi:
- Le variabili e i costrutti.

A 13 anni, se impara bene questo parte avvantaggiato, in barba a office, vba e sql, che scuramente avra' tempo per imparare.

Ecco questo perché tu, da bravo programmatore fossilizzato agli anni '70, consideri i linguaggi imperativi come gli unici linguaggi esistenti ed utilizzabili per programmare.

Se uno inizia a studiare informatica a partire dai linguaggi funzionali (e bada bene che è solo per motivazioni storiche che non siamo qui a fare la discussione inversa, ovvero con tu che sostieni che non sapere a memoria un manuale di Haskell è eresia) non sente nemmeno parlare di concetti come variabili e costrutti, semplicemente perché in un linguaggio funzionale non esistono. In un linguaggio funzionale non modifichi lo stato del sistema, ma valuti espressioni, quindi non operi su variabili.

Oh, e io non sono un fan sfegatato dei linguaggi funzionali, preferisco comunque i linguaggi imperativi perché si adattano meglio al mio modo di ragionare, ma comunque trovo triste che uno sostenga che nel 2010 non SAPERE A MEMORIA un libro di C sia una cosa negativa per diventare un buon programmatore. Secondo me un buon programmatore diventa tale avendo buone basi di problem solving, algoritmica e ottimizzazione del codice, non imparando il C. Se tu hai buone basi, poi il linguaggio lo scegli tu, secondo le tue esigenze e i tuoi gusti. E' come dire che per essere un buon poeta bisogna conoscere per forza a menadito la grammatica italiana, piuttosto che quella tedesca o inglese. Per essere un buon poeta devi avere elevate capacità espressive, senso del ritmo e della musicalità delle parole, il linguaggio che usi per esprimere tutto ciò è una questione di gusti.

Se non sei in grado di ottimizzare il codice o fare un'analisi di complessità puoi sapere anche i minimi dettagli del C, sicuramente potrai fare il figo con il programmatore "inesperto" facendogli vedere che scrivi la stessa cosa che scrive lui in una riga piuttosto che 3, ma scriverai e continuerai a scrivere comunque programmi che fanno scoreggiare sangue dal punto di vista delle prestazioni e della leggibilità (e, perché no, eleganza) del codice.

[hendor]

Avvicinarsi alla programmazione partendo dai linguaggi funzionali????

[BlackCaesar]

Eh perché non si potrebbe, di grazia?!

[Recidivo Visual]

Ecco questo perché tu, da bravo programmatore fossilizzato agli anni '70, consideri i linguaggi imperativi come gli unici linguaggi esistenti ed utilizzabili per programmare.

Se uno inizia a studiare informatica a partire dai linguaggi funzionali (e bada bene che è solo per motivazioni storiche che non siamo qui a fare la discussione inversa, ovvero con tu che sostieni che non sapere a memoria un manuale di Haskell è eresia) non sente nemmeno parlare di concetti come variabili e costrutti, semplicemente perché in un linguaggio funzionale non esistono. In un linguaggio funzionale non modifichi lo stato del sistema, ma valuti espressioni, quindi non operi su variabili.

Oh, e io non sono un fan sfegatato dei linguaggi funzionali, preferisco comunque i linguaggi imperativi perché si adattano meglio al mio modo di ragionare, ma comunque trovo triste che uno sostenga che nel 2010 non SAPERE A MEMORIA un libro di C sia una cosa negativa per diventare un buon programmatore. Secondo me un buon programmatore diventa tale avendo buone basi di problem solving, algoritmica e ottimizzazione del codice, non imparando il C. Se tu hai buone basi, poi il linguaggio lo scegli tu, secondo le tue esigenze e i tuoi gusti. E' come dire che per essere un buon poeta bisogna conoscere per forza a menadito la grammatica italiana, piuttosto che quella tedesca o inglese. Per essere un buon poeta devi avere elevate capacità espressive, senso del ritmo e della musicalità delle parole, il linguaggio che usi per esprimere tutto ciò è una questione di gusti.

Se non sei in grado di ottimizzare il codice o fare un'analisi di complessità puoi sapere anche i minimi dettagli del C, sicuramente potrai fare il figo con il programmatore "inesperto" facendogli vedere che scrivi la stessa cosa che scrive lui in una riga piuttosto che 3, ma scriverai e continuerai a scrivere comunque programmi che fanno scoreggiare sangue dal punto di vista delle prestazioni e della leggibilità (e, perché no, eleganza) del codice.

Da tutto questo, capisco che te il libro che ho preso ad esempio, non lo hai letto.
E non intendevo tutto, mi bastava il capitolo 1.


P.S. Se proprio mi volevo fossilizzre, ti dicevo di leggere il manuale dello Z80. ( Si, proprio lo Zilog Z80 )

[BlackCaesar]

L'ho letto, appunto parla di variabili, lettura e scrittura di caratteri e su come si costruisce una funzione. E quindi? Saper programmare vuol dire conoscere questo, secondo te? Appunto ti ripeto, per te è impossibile incominicare a programmare a partire da un linguaggio funzionale puro tipo Haskell, in cui il concetto stesso di variabile non esiste?

Da quello che rispondi tu invece deduco che non sappia nemmeno cosa sia un linguaggio funzionale.

[Recidivo Visual]

L'ho letto, appunto parla di variabili, lettura e scrittura di caratteri e su come si costruisce una funzione. E quindi? Saper programmare vuol dire conoscere questo, secondo te? Appunto ti ripeto, per te è impossibile incominicare a programmare a partire da un linguaggio funzionale puro tipo Haskell, in cui il concetto stesso di variabile non esiste?

Da quello che rispondi tu invece deduco che non sappia nemmeno cosa sia un linguaggio funzionale.

Ma benedetto figliolo, la discussione e'
"Cosa insegnare o come avviare un tredicenne all'informatica"


http://it.wikipedia.org/wiki/Haskell_(linguaggio)

Non ha variabili. ( cit )


-----

E la tua risposta e' fargli un corso di informatica 1 da universita'?

[BlackCaesar]

Ma no, però si può benissimo incominciare a programmare in Haskell come in un qualsiasi linguaggio imperativo. Certo non vai a spiegargli in dettaglio i formalismi dietro ad una monade, ma le cose basilari le puoi fare tranquillamente.

Infatti non ha variabili come puoi leggere qui:

http://it.wikipedia.org/wiki/Haskell_%28linguaggio%29

[hendor]

Eh perché non si potrebbe, di grazia?!

Perchè è un tipo di programmazione basata principalmente sul concetto di ricorsione, che a sua volta è la versione informatica del ragionamento per induzione.
E tutto ciò è tutt'altro che intuitivo, soprattutto per un ragazzino, che dovrebbe avere una base di matematica non banale, e che a quell'età certamente non hai. In realtà non è detto che tu ce l'abbia anche da grandicello...

Variabili, cicli, istruzioni condizionali, oltre che a consentire di programmare in uno stile molto più intuitivo e quindi di facile comprensione, anche se spesso con più righe di codice, rappresentano anche piuttosto bene quella che è la logica di funzionamento base di un qualunque calcolatore. Non si tratta solo di imparare la programmazione, ma in generale come ragiona quell'attrezzo strano con il quale finora hai solo giocato.

Quindi, imho, cominciare dalla programmazione funzionale è folle.
Del resto ci sarà anche un motivo per cui qualunque corso di programmazione a qualunque livello parta dalla programmazione imperativa e non da quella funzionale.

[BlackCaesar]

Beh, il motivo è che in pochi la conoscono e la usano. Comunque è vero, però un minimo di programmazione funzionale si può accostare ad un corso di linguaggi imperativi, e non è vero che la ricorsione va per forza spiegata formalmente a livello induttivo con le equazioni di ricorrenza, basta esporre in maniera chiara il concetto di sotto problema. Poi sull'inuitività è una questione soggettiva, c'è gente che va meglio a ragionare in modo ricorsivo, altri come me che ragionano in modo sequenziale, dipende dalla persona.

[Recidivo Visual]

A 13 anni?

[BlackCaesar]

E perché a 13 anni dovrebbe essere più semplice capire un ciclo FOR?

[~spiral~]

E perché a 13 anni dovrebbe essere più semplice capire un ciclo FOR?

Perchè fin da piccoli le cose si imparano per ripetitività, non per ricorsione. Esempio classico le moltiplicazioni (e quindi le tabelline): 7x7 = 7 volte 7, te lo spiegano come un ciclo for, non come un'operazione ricorsiva.

Nota a margine del discorso, nel mondo del lavoro odierno 8 lavori "standard" su 10 richiedono l'uso dei linguaggi imperativi, e questo è credo il motivo principale per cui i linguaggi funzionali siano ancora molto meno diffusi.
Il saper padroneggiare entrambe le tipologie di linguaggi, comunque, ti dà un'apertura mentale notevole, e ti permette di risolvere in maniera brillante alcuni sotto-problemi degli applicativi commissionati (ma raramente l'intero ventaglio di problemi). Il dato di fatto è però che, purtroppo, la maggior parte degli universitari si trova in grossa difficoltà (o meglio, l'azienda nei suoi confronti, che vorrebbe tempi stretti e concisi) in 8 lavori su 10, in quanto la loro produttività è inficiata da un'analisi estremamente complessa per problemi in realtà molto più semplici. Ovvio che un non-laureato nei restanti 2 lavori su 10, rispetto ad universitario, con ogni probabilità non saprebbe dove girarsi.

[BlackCaesar]

Perchè fin da piccoli le cose si imparano per ripetitività, non per ricorsione. Esempio classico le moltiplicazioni (e quindi le tabelline): 7x7 = 7 volte 7, te lo spiegano come un ciclo for, non come un'operazione ricorsiva.

Dipende dall'insegnante, io avevo una maestra furba che mi ha insegnato una sorta di "programmazione dinamica" per fare le tabelline (e quindi necessariamente ricorsiva come ragionamento).

7x0= 0
7x1= (7x0) + 7
7x2= (7x1) + 7
...

Infatti c'erano bambini, e sono sicuro che ci sono tutt'ora, che se gli dici che 7x8= 56 e chiedi loro quanto faccia 7x9 cominciano dall'inizio della tabellina (cioè sommano 9 volte 7) invece di sommare a 56 7, perché appunto, per ricavarsi l'intera tabellina, sono abituati a fare:

t[0] = 0
for i = 1 to 7 do
    m = 0
    for j = 1 to i do
          m = m + 7
    t[i] = m

Non c'è un metodo unico ed efficace per spiegare le cose, dipende sempre da come le spieghi. Nel mio caso spiegare le tabelline in forma ricorsiva (certo non con tutte le formalizzazioni dietro) è stato possibile e anche utile perché si fa meno fatica

[hendor]

Io le tabelline le ho imparate a memoria e basta...
Anche perchè francamente c'è molto poco da ragionare.

In ogni caso non mi pare che il ragionamento del FOR/WHILE sia una cosa cosi complicata. Cosa c'è da capire in "Fai questo X volte" o "Fai questo finchè..."?

[giuseppemag]

Io le tabelline le ho imparate a memoria e basta...
Anche perchè francamente c'è molto poco da ragionare.

In ogni caso non mi pare che il ragionamento del FOR/WHILE sia una cosa cosi complicata. Cosa c'è da capire in "Fai questo X volte" o "Fai questo finchè..."?

A parte il fatto che personalmente il manualetto di K&R lo conosco benissimo, cosí come Algorithms in C, Algorithms in C++ e la vera bibbia, il Cormen. Li ho tutti nella mia libreria personale.

Non capisco in quale oscuro e strano mondo

f 0 = 1
f n = n * (f (n-1))


sia peggio di


int f(int n) {
if(n == 0) return 1;
return n * f(n-1);
}


Comunque di modi per insegnare linguaggi molto semplici come notazione e come semantica (come LISP e SCHEME) ce n'è un sacco. Un link lo ho riportato in un mio messaggio poco sopra ma vedo che è passato inosservato...

In ogni caso insegnare un linguaggio dotato di aritmetica dei puntatori e di null ad un ragazzino di 13 anni mi pare follia pura.


In ogni caso siccome noi accademici dei linguaggi funzionali siamo tutti coglioni e non vale la pena starci a sentire, vi riporto una cosa che dovete leggere (chi è in grado) da parte del creatore di Unreal:

http://lambda-the-ultimate.org/node/1277

[Recidivo Visual]

Se non capisci la differenza di difficoltà tra l'iterazione e la ricorsione. L'ultima tua affermazione, è tristemente vera.

[hendor]

Non capisco in quale oscuro e strano mondo

f 0 = 1
f n = n * (f (n-1))

sia peggio di

int f(int n) {
if(n == 0) return 1;
return n * f(n-1);
}

Forse non mi sono spiegato. Il punto non è se è facile o meno ragionare per induzione. Il punto è se è facile per un ragazzino di 13 anni.
Secondo te, per spiegare il fattoriale è più facile la definizione che hai dato tu o è più facile
1*2*3*4*......*n ?

Poi, lascia perdere le definizioni già note. Immagina un problema nuovo. Che so, gli dici di scrivere una funzione per prendere una stringa e rigirarla al contrario. Secondo te, la naturale soluzione che gli verrebbe in mente è quella ricorsiva?
Se è cosi, si vede che tu eri un 13enne anomalo

In ogni caso insegnare un linguaggio dotato di aritmetica dei puntatori e di null ad un ragazzino di 13 anni mi pare follia pura.

Quando arrivi al capitolo dei puntatori non stai più studiando programmazione, stai facendo qualcosa di più avanzato.
E comunque c'è anche il Java, il TP....ce ne stanno quanti ne vuoi. Si consiglia il C perchè è un linguaggio che oltre ad essere didatticamente ottimo è anche utile.

In ogni caso siccome noi accademici dei linguaggi funzionali siamo tutti coglioni e non vale la pena starci a sentire, vi riporto una cosa che dovete leggere (chi è in grado) da parte del creatore di Unreal:

http://lambda-the-ultimate.org/node/1277

Non scadiamo nel vittimismo, nessuno qui ti ha dato del coglione. Il fatto di essere un accademico dei linguaggi funzionali, però, ti sta facendo dare per scontato che un ragazzino di 13 anni possa imparare i linguaggi funzionali più facilmente di quanto farebbe con un qualunque linguaggio imperativo.

[giuseppemag]

Non scadiamo nel vittimismo, nessuno qui ti ha dato del coglione. Il fatto di essere un accademico dei linguaggi funzionali, però, ti sta facendo dare per scontato che un ragazzino di 13 anni possa imparare i linguaggi funzionali più facilmente di quanto farebbe con un qualunque linguaggio imperativo.

Si, era ironico ma non riguardo a me stesso che la cosa mi tange ben poco...

Intendo dire che c'è della gente che sta realizzando che l'idea di programmazione che ha il programmatore medio è talvolta persino dannosa, e che l'uso fin dall'inizio di linguaggi piú potenti potrebbe essere una soluzione a molti dei problemi che piagano l'informatica moderna.

Non a caso ho citato un link di un grandissimo linguaggista moderno (Tim Sweeney) che in questo forum dovrebbe suscitare GRANDE rispetto. Il link andrebbe aperto e studiato.


Comunque personalmente ho perso anni di vita a studiare C/C++, e dubito fortemente siano serviti a qualcosa. A posteriori mi è stato molto utile studiare HLSL e il modello data parallel degli shaders, ben piú interessante e formativo.

[giuseppemag]

Se non capisci la differenza di difficoltà tra l'iterazione e la ricorsione. L'ultima tua affermazione, è tristemente vera.

A parte che per un programmatore l'uso di sintassi corretta dovrebbe essere rilevante, e lo scempio che hai fatto della nostra buona lingua è angosciante, hai aperto il link di sopra?

Il messaggio era contestualizzato. Per chi non capisce il sarcasmo, i linguaggisti di oggi studiano le astrazioni di linguaggio che verranno usate fra 10/20 anni. Ogni singola feature che amate oggi dei vostri linguaggini imperativi object-oriented viene dai linguaggisti di una volta.

A seguire un blocco di cose che non sono ancora molto diffuse ma lo saranno presto (hanno tutte iniziato a entrare nel mainstream):

Monadi --> patterns di astrazioni
Async del C# 5.0 e simili, Task Parallel Library --> patterns di threading
List comprehensions/query comprehensions --> iteratori
Funzioni di ordine superiore --> (molti) design patterns


Ed ecco invece la lista delle cose giá entrate; alcune di queste credete siano "intuitive" ma è solo perché le avete studiate da giovani:


Delegates/funzioni lambda/event handlers --> interfacce con un solo metodo (di solito "invoke")
Subclassing/inheritance --> structs con preludio uguale o allineate
Oggetti --> structs con puntatori a funzione
Structs --> buffer formattati con vari dati
Procedure --> best practices per l'uso dello stack
If/For/While --> best practices per l'uso di jump


Considerate che le cose dell'ultima lista sono tutte state oggetto di discussioni come quella corrente. Secondo me un ragazzino che inizia oggi deve studiare le cose che stanno diventando rilevanti, non lo stato dell'arte che sará presto reso obsoleto!

[Recidivo Visual]

A parte che per un programmatore l'uso di sintassi corretta dovrebbe essere rilevante, e lo scempio che hai fatto della nostra buona lingua è angosciante, hai aperto il link di sopra?

Il messaggio era contestualizzato. Per chi non capisce il sarcasmo, i linguaggisti di oggi studiano le astrazioni di linguaggio che verranno usate fra 10/20 anni. Ogni singola feature che amate oggi dei vostri linguaggini imperativi object-oriented viene dai linguaggisti di una volta.

A seguire un blocco di cose che non sono ancora molto diffuse ma lo saranno presto (hanno tutte iniziato a entrare nel mainstream):

Monadi --> patterns di astrazioni
Async del C# 5.0 e simili, Task Parallel Library --> patterns di threading
List comprehensions/query comprehensions --> iteratori
Funzioni di ordine superiore --> (molti) design patterns


Ed ecco invece la lista delle cose giá entrate; alcune di queste credete siano "intuitive" ma è solo perché le avete studiate da giovani:


Delegates/funzioni lambda/event handlers --> interfacce con un solo metodo (di solito "invoke")
Subclassing/inheritance --> structs con preludio uguale o allineate
Oggetti --> structs con puntatori a funzione
Structs --> buffer formattati con vari dati
Procedure --> best practices per l'uso dello stack
If/For/While --> best practices per l'uso di jump


Considerate che le cose dell'ultima lista sono tutte state oggetto di discussioni come quella corrente. Secondo me un ragazzino che inizia oggi deve studiare le cose che stanno diventando rilevanti, non lo stato dell'arte che sará presto reso obsoleto!

A parte essere palesemente fuori argomento, sei anche palesemente in errore, anche perche':
"Secondo me un ragazzino che inizia oggi deve studiare le cose che stanno diventando rilevanti"

Ok, allora invece che le espressioni, facciamogli le derivate.
O no? le espressioni sono vecchie.
Nell'istruzione non si deve tenere conto dell'eta' o del grado di preparazione delle persone, NO.
Bisogna studiare le cose che stanno diventando rilevanti.

Cioe', qui siamo alla follia.
Dai, o provochi o sei un benedetto ignorante, ma non di quelli che sbagliano a scrivere digitando di fretta e furia, ma di quelli che proprio hanno dei concetti sbagliati.

Ma ora mi ricordo di te. ...
Ma figurati..
Ora mi ricordo bene.

Comunque personalmente ho perso anni di vita a studiare C/C++, e dubito fortemente siano serviti a qualcosa. A posteriori mi è stato molto utile studiare HLSL e il modello data parallel degli shaders, ben piú interessante e formativo.

Da oggi, entri prepotentemente nelle persone la cui opinione non solo non conta niente, ma:



Addio.

[BlackCaesar]

Troll Score 1/10

Ah, a proposito della tua lista di ignore

Poi il parallelismo con espressioni e derivate è palesemente poco azzeccato: le espressioni si fanno per acquisire un automatismo di calcolo, le derivate sono uno strumento per analizzare le funzioni.

[~spiral~]

A parte che per un programmatore l'uso di sintassi corretta dovrebbe essere rilevante, e lo scempio che hai fatto della nostra buona lingua è angosciante, hai aperto il link di sopra?

Il messaggio era contestualizzato. Per chi non capisce il sarcasmo, i linguaggisti di oggi studiano le astrazioni di linguaggio che verranno usate fra 10/20 anni. Ogni singola feature che amate oggi dei vostri linguaggini imperativi object-oriented viene dai linguaggisti di una volta.

A seguire un blocco di cose che non sono ancora molto diffuse ma lo saranno presto (hanno tutte iniziato a entrare nel mainstream):

Monadi --> patterns di astrazioni
Async del C# 5.0 e simili, Task Parallel Library --> patterns di threading
List comprehensions/query comprehensions --> iteratori
Funzioni di ordine superiore --> (molti) design patterns


Ed ecco invece la lista delle cose giá entrate; alcune di queste credete siano "intuitive" ma è solo perché le avete studiate da giovani:


Delegates/funzioni lambda/event handlers --> interfacce con un solo metodo (di solito "invoke")
Subclassing/inheritance --> structs con preludio uguale o allineate
Oggetti --> structs con puntatori a funzione
Structs --> buffer formattati con vari dati
Procedure --> best practices per l'uso dello stack
If/For/While --> best practices per l'uso di jump


Considerate che le cose dell'ultima lista sono tutte state oggetto di discussioni come quella corrente. Secondo me un ragazzino che inizia oggi deve studiare le cose che stanno diventando rilevanti, non lo stato dell'arte che sará presto reso obsoleto!

Wow, bel post!

Quello precedente era un po'sintetico, ma qui devo dire che è ben chiaro il tuo punto di vista e da' degli ottimi spunti di discussione. Ho avuto tra l'altro un attimo di tempo per leggere il ppt del creatore di unreal linkato e devo dire che è decisamente una diagnosi interessante, anche perchè partendo da concetti inerenti al ciclo di sviluppo di un gioco espone concetti validi ovunque nel mondo del software. Il primo pdf linkato non ho ancora avuto modo di leggerlo con calma.

Per come la penso io, però, andrei un attimo cauto sull'abbandonare l'insegnamento di tecnologie ancora in voga in favore di nuovi paradigmi; dico questo perchè credo che difficilmente in futuro i nuovi paradigmi sostituiranno totalmente quelli vecchi: in alcuni ambiti, e parlo in particolare di quelli business aziendali in cui solitamente opero, trovo difficile che la rappresentazione delle entità in gioco (ordini, magazzino, ecc) non passi da paradigmi OOP e correlati. E' però plausibile che molti di processi aziendali (e quindi le relazioni tra queste entità), la cui rappresentazione in sistemi imperativi è inutilmente complessa e macchinosa, trovi più respiro in un elegante risoluzione funzionale. Cioè la domanda in poche parole è: siamo sicuri che in tutti gli ambiti del software i nuovi paradigmi soppianteranno quelli vecchi di ormai anni e che invece non li miglioreranno o affiancheranno semplicemente?

Diciamo anche che il linguaggio funzionale, lavorando in pratica per "definizioni", è molto vicino, sia per concetti che per sintassi, ad un tipo di analisi matematica che non viene quasi mai affrontata fino al primo anno di università (e qui, secondo me, sta la difficoltà nell'introdurlo troppo presto). Portare alle scuole superiori una programmazione funzionale al posto o complementare a quella imperativa (che poi quando ero studente io 12 anni fa non mi hanno nemmeno accennato alla OOP e ho dovuto studiarmela dai libri da solo, e credo che le cose non siano migliorate di molto) richiederebbe secondo me una rivisitazione anche dei programmi di matematica/geometria, e non solo di informatica.

[giuseppemag]

Wow, bel post!

Quello precedente era un po'sintetico, ma qui devo dire che è ben chiaro il tuo punto di vista e da' degli ottimi spunti di discussione. Ho avuto tra l'altro un attimo di tempo per leggere il ppt del creatore di unreal linkato e devo dire che è decisamente una diagnosi interessante, anche perchè partendo da concetti inerenti al ciclo di sviluppo di un gioco espone concetti validi ovunque nel mondo del software. Il primo pdf linkato non ho ancora avuto modo di leggerlo con calma.

Per come la penso io, però, andrei un attimo cauto sull'abbandonare l'insegnamento di tecnologie ancora in voga in favore di nuovi paradigmi; dico questo perchè credo che difficilmente in futuro i nuovi paradigmi sostituiranno totalmente quelli vecchi: in alcuni ambiti, e parlo in particolare di quelli business aziendali in cui solitamente opero, trovo difficile che la rappresentazione delle entità in gioco (ordini, magazzino, ecc) non passi da paradigmi OOP e correlati. E' però plausibile che molti di processi aziendali (e quindi le relazioni tra queste entità), la cui rappresentazione in sistemi imperativi è inutilmente complessa e macchinosa, trovi più respiro in un elegante risoluzione funzionale. Cioè la domanda in poche parole è: siamo sicuri che in tutti gli ambiti del software i nuovi paradigmi soppianteranno quelli vecchi di ormai anni e che invece non li miglioreranno o affiancheranno semplicemente?

Diciamo anche che il linguaggio funzionale, lavorando in pratica per "definizioni", è molto vicino, sia per concetti che per sintassi, ad un tipo di analisi matematica che non viene quasi mai affrontata fino al primo anno di università (e qui, secondo me, sta la difficoltà nell'introdurlo troppo presto). Portare alle scuole superiori una programmazione funzionale al posto o complementare a quella imperativa (che poi quando ero studente io 12 anni fa non mi hanno nemmeno accennato alla OOP e ho dovuto studiarmela dai libri da solo, e credo che le cose non siano migliorate di molto) richiederebbe secondo me una rivisitazione anche dei programmi di matematica/geometria, e non solo di informatica.

Uhh, grazie! Finalmente qualcuno che ha capito e non risponde provocando in modo idiota. Chissá che riusciamo a creare una discussione intelligente in piú di tre (io, te e BC ).

Certamente, la tua osservazione è molto a proposito. Ovviamente ogni evoluzione dei linguaggi rende piú abili i programmatori, ma non soppianta le evoluzioni precedenti. Chiaramente l'idea di rappresentare oggetti è molto potente, sopattutto se intendiamo gli oggetti come strutture polimorfe in grado di rispondere a domande su se stesse. I limiti della object orientation vengono molto fuori quando si usano gli oggetti per rappresentare operatori; ad esempio se uno volesse creare un mini-linguaggio con oggetti si troverebbe a scrivere cose tipo:

new If(new MyCond(), new OnMyCondTrue(), new OnMyCondFalse())

dove MyCond eredita BooleanExpression e OnMyCondTrue e OnMyCondFalse ereditano Statement.

Una cosa del genere diventa facilissima e molto bella in Haskell o F# tramite una monade:

let! b = my_cond
if b then
__do! my_cond_true
else
__do! my_cond_false

(ho usato _ come spazio per comoditá). In pratica ho costruito lo stesso oggetto di prima in modo leggibile e con un framework (la mia monade) piú granulare. Questo genere di cosa permette di definire linguaggi di scripting (o DSL) che rendono molto piú facile programmare il proprio dominio, impedendo a se stessi di costruire programmi che non rispettano a pieno la propria conoscenza delle limitazioni del nostro ambito.

Insomma, dove i linguaggi moderni sono eccellenti a rappresentare i dati ma non a rappresentare i processi che manipolano i dati, i nuovi linguaggi stanno imparando a fare proprio questo prendendo a prestito concetti recenti dei linguaggi funzionali, che da sempre hanno fatto da prima sandbox di testing alle innovazioni programmative. Un esempio di cosa che migliora con questo approccio? La programmazione concorrente:

http://blogs.msdn.com/b/ericlippert/...nce-await.aspx

non a caso C# integra molte di queste cose, avendo assunto Microsoft Research alcune delle piú grandi teste esistenti nello studio dei linguaggi di programmazione...



Per quanto riguarda lo studio dei giovani, ho appena terminato (ci sto scrivendo un paper) un brevissimo ciclo di lezioni che abbiamo fatto a degli studenti delle superiori qui a Ca' Foscari. I ragazzi hanno usato un linguaggio funzionale che non avevano mai usato prima (F#) per creare shaders e simulazioni fisiche con equazioni differenziali. Avevamo previsto, internamente tra gli oganizzatori, che nessuno studente avrebbe completato i percorsi previsti senza aiuto, vista la difficoltá delle esercitazioni. Beh, ci siamo sbagliati di grosso. I ragazzi si sono tuffati con entusiasmo, ed il feedback grafico degli shaders e della pallina che rimbalza li hanno stimolati al punto che hanno tutti completato le esercitazioni nella loro interezza.

La morale che ne traggo è che se il problema è abbastanza interessante, allora un ragazzino le cose se le divora. I linguaggi funzionali, avendo poca sintassi da imparare, risultano piú amichevoli per un beginner. Per caritá, la cosa è opinabile, ma almeno nella mia universitá ho personalmente condotto studi a riguardo per cui ho dati sperimentali a supportare la mia posizione!