Xna

[y.a.f.ake]

contingente=non necessario ma non impossibile?

Non sono esattamente abbagliato dalla profonditá della tua dissertazione: puoi elaborare in piú di due ("meccanismo", "contingente") parole?

PS: le qualitá di LINQ non sono le stesse di caratteristiche superficiali di un linguaggio, siano un parco librerie, ambienti di sviluppo, zucchero sintattico, etc. Si tratta piuttosto di un modo eccezionale per risolvere una serie di problemi della programmazione contemporanea con estrema eleganza e con conoscenze accademicamente profonde!

Beh anche io non è che sia particolarmente abbagliato dalla tua verbosità,ma dopo tutto si può essere fumosi sia essendo criptici che prolissi.
Alla fine dove uno vede "un modo eccezionale per risolvere una serie di problemi della programmazione contemporanea" un altro vede il continuo sovraccaricare un linguaggio di strumenti,già esistenti separatamente, operando commistioni in diversi paradigmi di programmazione come la ricerca di una specializzazione che lo porta ad essere troppo pesante e dispersivo e che gli fa perdere la potenza della generalità.
Adesso però veramente stiamo iniziando ad allontanarci troppo dal tema della discussione; lo sai benissimo che potremmo parlare per secoli senza smuoverci ognuno dalla propria posizione.Poi concordo con Cherno che le guerre sui linguaggi siano molto sterili, infatti sebbene mi sia lasciato trascinare in questa discussione, di solito non mi piace parlare dei massimi sistemi, ma mi piace intervenire nei thread di natura più pratica,alla fine mi sento molto più arricchito da quelle discussioni che non da queste.

[giuseppemag]

Beh anche io non è che sia particolarmente abbagliato dalla tua verbosità,ma dopo tutto si può essere fumosi sia essendo criptici che prolissi.
Alla fine dove uno vede "un modo eccezionale per risolvere una serie di problemi della programmazione contemporanea" un altro vede il continuo sovraccaricare un linguaggio di strumenti, già esistenti separatamente, operando commistioni in diversi paradigmi di programmazione come la ricerca di una specializzazione che lo porta ad essere troppo pesante e dispersivo e che gli fa perdere la potenza della generalità.

Ok. Portiamo la discussione "up a notch", cosí con maggiore tecnicismo ci capiamo meglio:

*voglio modificare con la funzione f tutti gli elementi della lista l creando l'enumerabile l':
l' = l.Select(f);
*voglio farlo in parallelo:
l' = l.AsAparallel().Select(f);

*in C#:
var l = Enumerable.Range(0,10000).ToList();
var l' = l.AsParallel().Select(i => i+1); //per sommare 1 a tutti gli elementi

*voglio tenere solo i numeri primi:
var l = Enumerable.Range(0,10000).ToList();
var primes = l.AsParallel().Where(i => Enumerable.Range(2,Sqrt(i)).All(j => i%j != 0)));

*voglio sommare a due a due tutti gli elementi di una lista:
sum = l.Aggregate((i,sum) => i+sum);
*in parallelo:
sum = l.AsParallel().Aggregate((i,sum) => i+sum);

*voglio costruire una lista che tenga solo la posizione e il raggio delle astronavi il cui nome inizia con "evil":
var evil = ships.AsParallel().Where(s => s.Name.StartsWith("evil")).Select(s => new {Position = s.Position; Radius = s.Radius});

*voglio eseguire la computazione D, che dipende da C e B, dove B dipende da A1 e A2:
var A1 = new Future<int>(A1_code);
var A2 = new Future<int>(A2_code);
var B = new Future<int>(B_code che usa A1.Value e A2.Value);
var C = new Future<int>(C_code);
var D = new Future<int>(D_code che usa B.Value e C.Value);
return D.Value;

tale computazione avviene perfettamente in parallelo e gestisce correttamente i lock e le sincronizzazioni necessarie.


Queste cose sono molto facili da assorbire, specialmente perché integrano conoscenze che derivano dal mondo delle queries su database e che il 99% degli sviluppatori ha giá. In questo modo non c'é quasi nulla di nuovo da imparare, e anzi si puó scoprire come applicare questi concetti in molti piú contesti e ottenere vari benefici utili (parallelismo, dichiarativitá del codice). Non la vedo come una modifica puramente cosmetica...

[y.a.f.ake]

Ok. Portiamo la discussione "up a notch", cosí con maggiore tecnicismo ci capiamo meglio:

*voglio modificare con la funzione f tutti gli elementi della lista l creando l'enumerabile l':
l' = l.Select(f);
*voglio farlo in parallelo:
l' = l.AsAparallel().Select(f);

*in C#:
var l = Enumerable.Range(0,10000).ToList();
var l' = l.AsParallel().Select(i => i+1); //per sommare 1 a tutti gli elementi

*voglio tenere solo i numeri primi:
var l = Enumerable.Range(0,10000).ToList();
var primes = l.AsParallel().Where(i => Enumerable.Range(2,Sqrt(i)).All(j => i%j != 0)));

*voglio sommare a due a due tutti gli elementi di una lista:
sum = l.Aggregate((i,sum) => i+sum);
*in parallelo:
sum = l.AsParallel().Aggregate((i,sum) => i+sum);

*voglio costruire una lista che tenga solo la posizione e il raggio delle astronavi il cui nome inizia con "evil":
var evil = ships.AsParallel().Where(s => s.Name.StartsWith("evil")).Select(s => new {Position = s.Position; Radius = s.Radius});

*voglio eseguire la computazione D, che dipende da C e B, dove B dipende da A1 e A2:
var A1 = new Future<int>(A1_code);
var A2 = new Future<int>(A2_code);
var B = new Future<int>(B_code che usa A1.Value e A2.Value);
var C = new Future<int>(C_code);
var D = new Future<int>(D_code che usa B.Value e C.Value);
return D.Value;

tale computazione avviene perfettamente in parallelo e gestisce correttamente i lock e le sincronizzazioni necessarie.


Queste cose sono molto facili da assorbire, specialmente perché integrano conoscenze che derivano dal mondo delle queries su database e che il 99% degli sviluppatori ha giá. In questo modo non c'é quasi nulla di nuovo da imparare, e anzi si puó scoprire come applicare questi concetti in molti piú contesti e ottenere vari benefici utili (parallelismo, dichiarativitá del codice). Non la vedo come una modifica puramente cosmetica...

E chi ha detto che è una modifica cosmetica? Chi ha detto che non è un meccanismo potente?
La questione è, ricollegando il discorso anche a Xna: è giusto che ad un programmatore vengano insegnati solo questi strumenti? Qualora vengano meno questi cosa uno se ne dovrebbe fare di questi programmatori che conoscono solo C#,linq,xna?
Tu dai a C#,linq etc una certa aurea ecumenica, ma quale è la loro reale portata applicativa? Parli, per esempio, di eliminazione dei meccanismi di sincronizzazione,ma in realtà questi rimangono sotto e ci saranno programmatori che se li dovranno smazzare.
Sinceramente io non vedo di buon occhio questa corsa alla semplificazione mediante l'oscuramento della complessità sottostante.
E' vero che si aumenta la platea dei programmatori, ma allo stesso tempo se ne impoveriscono le capacità generali.

[giuseppemag]

La questione è, ricollegando il discorso anche a Xna: è giusto che ad un programmatore vengano insegnati solo questi strumenti?

Solo? Chi ha parlato di insegnare "solo"? Come disse Backus nel 1977 per il suo Turing Award: "come possiamo liberarci dall'orrido stile di programmazione di Von Neumann?", cosí io sono convinto che insegnare linguaggi di basso livello (come il C) prima di insegnare a ragionare in modo astratto rischia di fottere il cervello di un programmatore
Personalmente ci ho messo parecchio sforzo a reimparare a programmare definendo prima "cosa" e poi "come" e non viceversa. Consiglierei ad un n00b di imparare prima F# se non sa nulla, sennó prima C#/LINQ se sa giá pochino di Java/C/Pascal/...
Poi si impara il C++ e magari si vede che il template metaprogramming estremo del C++ altro non é che un linguaggio funzionale puro. Da qui, si puó andare ovunque!

Qualora vengano meno questi cosa uno se ne dovrebbe fare di questi programmatori che conoscono solo C#,linq,xna?

Boh, gli mette in mano Mono. Oppure usa la loro abilitá superiore per fargli scrivere codice complesso in OcaML, Haskell, Scala o quel diavolo che preferiscono. Oppure gli mette in mano un qualsiasi linguaggio OO in cui possono realizzare gli stessi pattern eleganti che prima avevano di libreria, e ora si dovranno ricostruire.
La conoscenza di questa roba é di altissima qualitá, anche dal punto di vista logico/matematico. Cambiare strumento da questi al resto del mondo é facile, il problema secondo me é il viceversa...

Tu dai a C#,linq etc una certa aurea ecumenica, ma quale è la loro reale portata applicativa? Parli, per esempio, di eliminazione dei meccanismi di sincronizzazione,ma in realtà questi rimangono sotto e ci saranno programmatori che se li dovranno smazzare.
Sinceramente io non vedo di buon occhio questa corsa alla semplificazione mediante l'oscuramento della complessità sottostante.
E' vero che si aumenta la platea dei programmatori, ma allo stesso tempo se ne impoveriscono le capacità generali.

Aura ecumenica? 'azzo dici ? Studio linguaggi di programmazione per lavoro, e dico esattamente quello che vedo. Nel quotidiano uso costantemente 7/8 linguaggi diversi, a cavallo tra Linux e Win7, quindi proprio di aure ecumeniche me ne frega poco. Mi frega quali lnguaggi mi portano dove.
La reale portata applicativa di LINQ/F# é assistere lo sviuppatore nella scrittura di codice meglio strutturato, permettendo al sistema di tipi (un piccolo theorem prover) di assistere nell'individuazione di una serie di classi di errori logici che spesso si commettono quando si fa poca analisi del problema affrontato. Questi paradigmi hanno il benefit di permettere di sfruttare pattern di parallelizzazione generali, nonché di produrre codice molto conciso.
Mica si rende la programmazione piú facile, *si rende piú facile la programmazione ben ragionata*.

E poi i programmatori che si smazzano i problemi generali ci sono sempre stati. O tu fai ancora il push dei registri nello stack per ogni chiamata a funzione?

[y.a.f.ake]

O tu fai ancora il push dei registri nello stack per ogni chiamata a funzione?

Aura ecumenica? 'azzo dici ? Studio linguaggi di programmazione per lavoro, e dico esattamente quello che vedo. Nel quotidiano uso costantemente 7/8 linguaggi diversi, a cavallo tra Linux e Win7, quindi proprio di aure ecumeniche me ne frega poco. Mi frega quali lnguaggi mi portano dove.

Questo lo dici ora, prima sembrava che parlassi di C# accoppiato a Linq come medicina doloris universale.

Poi si impara il C++ e magari si vede che il template metaprogramming estremo del C++ altro non é che un linguaggio funzionale puro. Da qui, si puó andare ovunque!

Se metti il C++ al vertice di tutto e come punto di approdo definitivo a me sta bene
Solo che vedo cosa abbastanza spericolata giungere al C++ passando per C#

io sono convinto che insegnare linguaggi di basso livello (come il C) prima di insegnare a ragionare in modo astratto rischia di fottere il cervello di un programmatore
Personalmente ci ho messo parecchio sforzo a reimparare a programmare definendo prima "cosa" e poi "come" e non viceversa. Consiglierei ad un n00b di imparare prima F# se non sa nulla, sennó prima C#/LINQ se sa giá pochino di Java/C/Pascal/...

Ma il "cosa" ed il "come" sono due questioni distinte fra loro.
Imparare a ragionare in modo astratto prescinde da qualsiasi linguaggio per definizione, e siamo d'accordo che debba essere il punto iniziale. E' il come che coinvolge un linguaggio specifico, e più si sceglie all'inizio un linguaggio che ti fa comprendere come funzionano realmente le cose sotto, più potrai utilizzare in modo realmente proficuo i linguaggi che man mano ti nasconderanno i dettagli fornendoti gradi di astrazione maggiore, perchè se sarai in difficoltà e qualcosa non andrà potrai sempre scoperchiare il cofano e mettere mano al motore, laddove altrimenti non ti resterebbe altro che impersonare i panni della classica signorina che rimane in panne al bordo della strada in attesa del provvidenziale soccorso.

[y.a.f.ake]

aurea ecumenica

fail

[giuseppemag]

Questo lo dici ora, prima sembrava che parlassi di C# accoppiato a Linq come medicina doloris universale.

Sembrava, mica lo ho asserito...Trovo sia un ottimo linguaggio come inizio percorso e un buon (non come unico) linguaggio per la produttivitá generale.

Se metti il C++ al vertice di tutto e come punto di approdo definitivo a me sta bene
Solo che vedo cosa abbastanza spericolata giungere al C++ passando per C#

Questo é un interprete di lambda calcolo (fratello funzionale delle macchine di Turing) eseguibile tutto a tempo di compilazione tramite il sistema di template del C++. Sono convinto che sia molto difficile imparare questo tipo di (meta-)programmazione senza prima essere passati per linguaggi piú semplici ma che ti aiutano ad impostare il ragionamento analitico. Partire dal C e arrivare al C++ vero secondo me é doppiamente difficile, anche se si puó fare. Comunque mi pare siamo sulla stessa lunghezza d'onda...

#include "iostream"
#include "string"
#include "strstream"
template<int X> struct Var { static void print(std:stream &cout) {cout << X;} };
template<int X, class T> struct Abs { static void print(std:stream &cout) {cout << "\\" << X << "."; T::print(cout);} };
template<class T1, class T2> struct App { static void print(std:stream &cout) {cout << "("; T1::print(cout); cout << ") ("; T2::print(cout); cout << ")";} };
template<int X, class T1, class T2> struct Replace {typedef T1 Result;};
template<int X, class T> struct Replace<X,Var<X>,T> {typedef T Result;};
template<int X, int Y, class T> struct Replace<X,Var<Y>,T> {typedef Var<Y> Result;};
template<int X, int Y, class T1, class T2> struct Replace<X,Abs<Y,T1>,T2> {typedef Abs<Y,typename Replace<X,T1,T2>::Result> Result;};
template<int X, class T1, class T2, class T3> struct Replace<X,App<T1,T2>,T3> {typedef App<typename Replace<X,T1,T3>::Result,typename Replace<X,T2,T3>::Result> Result;};
template<class T> struct Eval {typedef T Result;};
template<int X, class T1, class T2> struct Eval<App<Abs<X,T1>, T2>> {typedef typename Replace<X, T2, T1>::Result Result;};
template<class T1, class T2> struct Eval<App<T1,T2>> {typedef typename Eval<App<typename Eval<T1>::Result,typename Eval<T2>::Result>>::Result Result;};

typedef Abs<0, Var<0>> LX_X;
typedef Abs<1, Abs<2, App<Var<1>,Var<2>>>> LY_LZ_Y_Z;
typedef App<LX_X, LY_LZ_Y_Z> X;
typedef Eval<X>::Result Y;
int_tmain(int argc,_TCHAR* argv[])
{
X::print(std::cout);
std::cout << " ->* ";
Y::print(std::cout);
std::cout << std::endl;
return 0;
}

Ma il "cosa" ed il "come" sono due questioni distinte fra loro.
Imparare a ragionare in modo astratto prescinde da qualsiasi linguaggio per definizione, e siamo d'accordo che debba essere il punto iniziale.

Chiaramente. Peró imparare il cosa in un linguaggio che permette cast a void* é molto difficile, perché uno spesso finisce con l'imparare a "gestire" la difficoltá intrinseca del linguaggio piuttosto che a programmare!

E' il come che coinvolge un linguaggio specifico, e più si sceglie all'inizio un linguaggio che ti fa comprendere come funzionano realmente le cose sotto, più potrai utilizzare in modo realmente proficuo i linguaggi che man mano ti nasconderanno i dettagli fornendoti gradi di astrazione maggiore, perchè se sarai in difficoltà e qualcosa non andrà potrai sempre scoperchiare il cofano e mettere mano al motore, laddove altrimenti non ti resterebbe altro che impersonare i panni della classica signorina che rimane in panne al bordo della strada in attesa del provvidenziale soccorso.

Su questo non sono d'accordo. Non sottovaluterei la difficoltá di costruire una mente analitica, relegando tale processo di apprendimento ad una seconda battuta. Il mondo é zeppo di sviluppatori che scrivono ottimo codice ma mal strutturato, e secondo me il problema é proprio quello di dare eccessiva importanza alla conoscenza del "come", che alla fin fine é piú un problema di chi scrive compilatori...