Linguaggio di programmazione per cominciare

[giuseppemag]

Ehi complimenti!

[royp]

La grande domanda è se Java sta dietro oppure se i due linguaggi si sono scambiati il testimone dell'innovativitá negli ultimi anni. Lo chiedo a qualcuno piú esperto di Java di me!

Da quel che mi sembra di vedere, Java e C# stanno prendendo 2 vie differenti: Java deve mantenere la retrocompatibilità con tutto ciò che è stato fatto in precedenza, quindi le innovazioni nel linguaggio sono davvero poche e introdotte a fatica. Alla Sun quindi per ovviare al problema aggiungono il supporto ad altri linguaggi più moderni: vedi Jython e JRuby per linguaggi dinamici, e Scala per la programmazione OO e funzionale. Tutti girano in ottimamente nella JVM (che da quanto mi ho letto in giro per la rete, ha più o meno la stessa velocità del CLR), con in più il supporto a tutte le classi Java. Addirittura JRuby venendo compilato e non interpretato, ha prestazioni superiori al Ruby classico. E Scala è supportato pure su Android! Certo introdurre nuovi linguaggi crea qualche problema al programmatore Java - sempre costretto ad aggiornarsi - mentre il programmatore C# avrà un percorso di aggiornamento più semplice, visto che continuerà a utilizzare lo stesso linguaggio.
A tal proposito, volevo chiedere a chi è più informato sul supporto ai linguaggi dinamici sul versante .NET : C# 4.0 ha un supporto intrinseco ai tipi dinamici, come va? mentre IronRuby e IronPython: ho visto il primo pare abbastanza bloccato - 1 anno dall'ultima release - mentre il secondo aggiornato anche recentemente.... ma c'è qualcuno che li usa?

[Recidivo Visual]

Mamma mia, che trollaccio. La cosa carina è che costui non sa nulla di didattica. È un programmatore qualsiasi che perché un metodo ha funzionato con lui allora assume che automaticamente funzionerá con tutti gli altri.

Abbello, non funziona mica cosí

Purtroppo la didattica, soprattutto di un ambito particolare come l'informatica, è una cosa complicata da affrontare. I giovani approcciano lo studio giá partendo dal presupposto che sia noioso comparato alle loro attivitá di intrattenimento (musica, tv, videogiochi, cellulari, infotainment tipo facebook). Quando i ragazzi studiano informatica per la prima volta si aspettano che vengano loro schiuse le porte del magico mondo della costruzione delle applicazioni a cui sono abituati. Non funziona piú il fatto di fare esempi tipo i numeri primi, invertire le liste, le torri di hanoi o cose del genere, e man mano che passano gli anni la situazione si fa piú grave. Infatti i computer offrono esperienze sempre piú ricche, e il gap tra informatica percepita e quello che puó fare un beginner con l'approccio tradizionale si ampia da morire. Non a caso c'è un altissima percentuale di studenti universitari che mollano i corsi di CS perché si aspettavano di fare cose piú fighe, e buona parte degli studenti sopravvissuti aveva giá studiato programmazione da sola.

Una dimostrazione di questo trend è data dalla enorme quantitá di studi sul tema di insegnare la programmazione agli studenti del primo anno (o talvolta anche delle scuole medie e superiori) tramite videogiochi. Stranamente alcuni studi mostrano che le ragazzine FEMMINE (giá, bestia rara tra i programmatori) rispondono molto bene all'approccio ludico:

http://scholar.google.it/scholar?q=t...ames&hl=it&lr=

Certo che se questi ricercatori chiedessero a Masp cosa ne pensa si risparmierebbero un po' di fatica, magari bisognerebbe distribuire il suo contatto...

Vedi ragazzotto, il problema e' che se la gente lascia i corsi di studio perche' pensa di fare le cose fiche e invece gli si propina corsi di studio non vuol dire che i corsi di studio vadano rivisti, ma che hanno sbagliato indirizzo.

Io certo che sono un programmatore qualunque, ma sai quanti sedicenti ingenieri ho visto che non sapevano fare una beneamata sega se non riempirsi la bocca di paroloni....

che poi....

Mamma mia, che trollaccio. La cosa carina è che costui non sa nulla di didattica. È un programmatore qualsiasi che perché un metodo ha funzionato con lui allora assume che automaticamente funzionerá con tutti gli altri.

Abbello, non funziona mica cosí

Ma sei te che alla domanda cosa insegnare ad un ragazzo di 12 anni, hai linkato qualcosa di uno sviluppatore di unreal.
Chesso' partiamo dall'abc.
Poi vabbe' andare a dire ad un programmatore che studiare il C non serve a niente ... ... qualifica di per se.

Che c'e' non basta? vuoi aggiungere qualcosa?
Chesso' che non bisogna studiare i transistor in elettronica?
Che la trigonometria non serve?

Giu', andiamo avanti.
Ma guarda te...

[BlackCaesar]

Vedi ragazzotto, il problema e' che se la gente lascia i corsi di studio perche' pensa di fare le cose fiche e invece gli si propina corsi di studio non vuol dire che i corsi di studio vadano rivisti, ma che hanno sbagliato indirizzo.

Io certo che sono un programmatore qualunque, ma sai quanti sedicenti ingenieri ho visto che non sapevano fare una beneamata sega se non riempirsi la bocca di paroloni....

Però magari il rendimento nell'apprendimento migliora con cose che stimolano di più l'interesse e l'attenzione non credi? Magari non lasciano niente, semplicemente fanno il corso raggiungendo un diametro testicolare da far invidia ad un ammalato di elefantiasi, passano l'esame e poi si dimenticano il 75% delle cose fatte perché si sono annoiati a morte.

[giuseppemag]

Vedi ragazzotto, il problema e' che se la gente lascia i corsi di studio perche' pensa di fare le cose fiche e invece gli si propina corsi di studio non vuol dire che i corsi di studio vadano rivisti, ma che hanno sbagliato indirizzo.

Io certo che sono un programmatore qualunque, ma sai quanti sedicenti ingenieri ho visto che non sapevano fare una beneamata sega se non riempirsi la bocca di paroloni....

che poi....



Ma sei te che alla domanda cosa insegnare ad un ragazzo di 12 anni, hai linkato qualcosa di uno sviluppatore di unreal.
Chesso' partiamo dall'abc.
Poi vabbe' andare a dire ad un programmatore che studiare il C non serve a niente ... ... qualifica di per se.

Che c'e' non basta? vuoi aggiungere qualcosa?
Chesso' che non bisogna studiare i transistor in elettronica?
Che la trigonometria non serve?

Giu', andiamo avanti.
Ma guarda te...

"Ragazzotto"...ti rendi conto che sono sposato e ho una figlia?

Non aggiungi nulla alla discussione, per cui adesso vai dritto dritto in ignore list. Ho di meglio da fare con il mio tempo, abbi pazienza...

[Alby87]

Scusate, non vorrei dire una blasfemia, ma che ne pensate di SmallBasic? Ovviamente non si potrà fare chissa che cosa, ma il concetto di "che cosa significa" programmare potrebbe farselo, e poi, se per lui il gioco vale la candela, penso che o C# o Java posso essere buoni (supportato da buoni libri cartacei), ma deve comunque prima capire cosa significa programmare.

[giuseppemag]

Scusate, non vorrei dire una blasfemia, ma che ne pensate di SmallBasic? Ovviamente non si potrà fare chissa che cosa, ma il concetto di "che cosa significa" programmare potrebbe farselo, e poi, se per lui il gioco vale la candela, penso che o C# o Java posso essere buoni (supportato da buoni libri cartacei), ma deve comunque prima capire cosa significa programmare.

Si, tutte le varianti di linguaggi di programmazione secondo me sono carine, ma metá del lavoro è trovare una applicazione di interesse; senza quella è difficile trovare la motivazione a stare a casa a programmare senza voti e senza riscontri se non la soddisfazione personale...

[giuseppemag]

Da quel che mi sembra di vedere, Java e C# stanno prendendo 2 vie differenti: Java deve mantenere la retrocompatibilità con tutto ciò che è stato fatto in precedenza, quindi le innovazioni nel linguaggio sono davvero poche e introdotte a fatica. Alla Sun quindi per ovviare al problema aggiungono il supporto ad altri linguaggi più moderni: vedi Jython e JRuby per linguaggi dinamici, e Scala per la programmazione OO e funzionale. Tutti girano in ottimamente nella JVM (che da quanto mi ho letto in giro per la rete, ha più o meno la stessa velocità del CLR), con in più il supporto a tutte le classi Java. Addirittura JRuby venendo compilato e non interpretato, ha prestazioni superiori al Ruby classico. E Scala è supportato pure su Android! Certo introdurre nuovi linguaggi crea qualche problema al programmatore Java - sempre costretto ad aggiornarsi - mentre il programmatore C# avrà un percorso di aggiornamento più semplice, visto che continuerà a utilizzare lo stesso linguaggio.
A tal proposito, volevo chiedere a chi è più informato sul supporto ai linguaggi dinamici sul versante .NET : C# 4.0 ha un supporto intrinseco ai tipi dinamici, come va? mentre IronRuby e IronPython: ho visto il primo pare abbastanza bloccato - 1 anno dall'ultima release - mentre il secondo aggiornato anche recentemente.... ma c'è qualcuno che li usa?

Uhm, dici? Non mi sembra tanto dal lato C#, ossia tutte le features aggiunte a C# non sono mai breaking-changes (forse peró ti riferivi alla VM, allora avrebbe senso!). Anche nel mondo .Net abbiamo i "linguaggi nuovi" come F#, anche se il supporto è un po' migliore di quello dato a Scala e simili.

Non voglio assolutamente che questa cosa che sto per scrivere venga interpretata male, anche perché il mio affetto per Java è molto forte: senza saremmo ancora bloccati al solo C/C++, ma mi sa che la spinta innovativa di Java si è un pochino spenta e dove negli anni '90 Java era innovativo al massimo ora sembra che il testimone sia passato a C#. Ovviamente le cose cambiano facilmente, per cui chissá chi sará il prossimo innovatore di linguaggi...google?

[Recidivo Visual]

"Ragazzotto"...ti rendi conto che sono sposato e ho una figlia?

Non aggiungi nulla alla discussione, per cui adesso vai dritto dritto in ignore list. Ho di meglio da fare con il mio tempo, abbi pazienza...

Vabbe' via.
Io c'ho provato.

E ricordiamo:

Che moccioso presuntuoso...

[blue_tech]

tornando in-topic pur rimanendo dell'idea che le ossa ce le si fa con il percorso c/c++/java posto questo link con due tool di introduzione alla programmazione. Ho provato quello per Ruby che pare carino.

C'è sia per ruby che per python

[giuseppemag]

tornando in-topic pur rimanendo dell'idea che le ossa ce le si fa con il percorso c/c++/java posto questo link con due tool di introduzione alla programmazione. Ho provato quello per Ruby che pare carino.

C'è sia per ruby che per python

Carino!

Da un punto di vista di "imparare i rudimenti del linguaggio" c`e' un graziosissimo sito, http://www.tryfsharp.org/, che implementa in F# una mini-console interattiva in cui provare gli esempi che ti vengono spiegati e mostrati. In pratica un mini-IDE su web...

A parte che alla lista aggiungerei anche C# (ovunque ci sia Java secondo me ci sta anche C# vista la cuginanza tra i due), vorrei chiarire un dettaglio: secondo me c'e' una grossa distanza tra dove cominci e dove ti fai le ossa. Per intenderci iniziare in C/C++ trovo sia perverso perche' i dettagli sono troppi e la programmazione rischia di sembrare una sorta di incomprensibile arte oscura e molto noiosa; per cui inizierei assolutamente con un paio di anni di linguaggi "fun". Poi che si DEBBA passare per C/C++ per essere un buon programmatore secondo me e' un dato assoluto, ma solo quando si sono accumulate abbastanza "riserve di interesse" e curiosita' per andare a scoprire cosa c'e' sotto senza farsi scoraggiare...

[masterz]

lettoniente ,
io uso .net ( in particolare visual basic , perche' mi faceva comodo in quanto venivo da vb6 , rispetto a c# cambia la sintassi e poche altre cose )

posso dire per certo che .net e' immediato ,
sicuramente si possono scrivere cose divertenti gia da subito anche da profano ed e' anche un linguaggio abbastanza potente per molti usi professionali , tant'e' vero che la maggior parte degli annunci di lavoro per programmatori cercano o java o c#.

c/c++ , io ho iniziato da quelli e devo dire che mi rotolavano veramente le palle (avevo circa 13 anni )

[Recidivo Visual]

Se c'e' una cosa che mi fa specie di questa discussione sono le accampate difficolta' del C.
Difficolta'?

aprendo explorer e giu' di li ..

Sono buoni linguaggi, ma con una sintassi complicata, che non facilita il loro apprendimento. Inoltre l'uso di puntatori rende il loro utilizzo, anche da professionisti, spesso difficile. Il vantaggio è che questi linguaggi possono essere utilizzati su più piattaforme (dopo la compilazione) e che, una volta imparati, gli altri appaiono più semplici.
Sono ancora ampiamente utilizzati nel mondo professionale.
Ad usare se si vuole lavorare nell'informatica.

Ai miei tempi vigeva:
"quello non sa lavorare con i puntatori ... "

oggi e' difficile.

Oggi e' una cosa difficile per chi sta li nell'informatica.

I piu' usati sistemi operativi sono stati scritti con il C dove era possibile non usare l'assembly.

Il C che e' palloso. Non ho parole.
Il miglior linguaggio che ci sia, quello che ti da liberta' di fare veramente quello che vuoi, di arrivare a gestire le risorse fino al livello piu' basso.

mi fate un esempio di cosa divertente da scrivere e di una noiosa?

[hendor]

Se c'e' una cosa che mi fa specie di questa discussione sono le accampate difficolta' del C.
Difficolta'?

aprendo explorer e giu' di li ..



Ai miei tempi vigeva:
"quello non sa lavorare con i puntatori ... "

oggi e' difficile.

Oggi e' una cosa difficile per chi sta li nell'informatica.

I piu' usati sistemi operativi sono stati scritti con il C dove era possibile non usare l'assembly.

Il C che e' palloso. Non ho parole.
Il miglior linguaggio che ci sia, quello che ti da liberta' di fare veramente quello che vuoi, di arrivare a gestire le risorse fino al livello piu' basso.

mi fate un esempio di cosa divertente da scrivere e di una noiosa?

Sono d'accordo.
Però pare che la gioventù di oggi se non è in grado di rifare campo minato entro i primi 20 minuti dal primo approccio al mondo dell'informatica, si arrende e passa ad altro.

Io ho imparato con il vecchio metodo e la cosa mi ha appassionato. E se devo consigliare un linguaggio per iniziare ribadisco il C. Java a seguire.
Se la cosa annoia, beh vuol dire che non era aria.

[blue_tech]

Sono d'accordo.
Però pare che la gioventù di oggi se non è in grado di rifare campo minato entro i primi 20 minuti dal primo approccio al mondo dell'informatica, si arrende e passa ad altro.

Io ho imparato con il vecchio metodo e la cosa mi ha appassionato. E se devo consigliare un linguaggio per iniziare ribadisco il C. Java a seguire.
Se la cosa annoia, beh vuol dire che non era aria.

esattamente quello che penso anche io

[Edward Gein]

Dopo aver letto 6 pagine di str... opinioni personali su didattica e approccio imperativo vs. funzionale, mi ci tuffo dentro anche io.

Per cominciare a programmare, C tutta la vita. È sintatticamente semplice, ha costrutti semplici.
L'aritmetica dei puntatori non la capiscono solo le capre ignoranti dato che sono addizioni, sottrazioni e basta sapere come è organizzata concettualmente la RAM in una macchina.

I costrutti con il C sono semplici.
Non insegni al ragazzino di tredici anni come descrivere, ma gli fai apprendere il significato operativo della cosa. Ovvero, non definisco il fattoriale, ma la procedura per calcolarlo.
Dopo, e soltanto dopo, si possono utilizzare figate (dal punto di vista di sinteticità sintattica) come la programmazione funzionale.
Sporcarsi le mani, capire come è possibile realizzare qualcosa, non ha prezzo.
Altrimenti è come provare a spiegare l'integrale senza passare dai concetti di somma, moltiplicazione e limite.

È per questo che avvengono brutte cose, come l'esempio dell'utente qualche post fa, dove trovi programmatori Java che usano puntatori tutto il tempo e non sanno cosa sia un puntatore (anche dove mi sono laureato io si faceva Java al primo anno e laboratorio di Algoritmi con C al secondo, e davvero ho visto troppi, troppi studenti perdersi sui puntatori. Questi qua teneteli lontano il più possibile dall'informatica applicata).

Passando ad altro:
non è vero che il codice C# viene tradotto da IL a linguaggio macchina alla prima esecuzione, la JIT agisce dove ritiene necessario, nonostante tutto è anni luce più avanti di Java.
Il 5-10% di prestazioni in meno rispetto a C mi giunge invece nuovo e stento un po' a crederci.
Il fatto che mono, o che qualche linguaggio di scripting venga utilizzato per fare videogiochi, non vuol dire che si possono rimpiazzare totalmente linguaggi a basso livello. Semplicemente, una volta progettato bene il tutto, scrivere "actor.moveTowards(player)", e poter modificare senza dover re-buildare tutto o parte, è il modo più veloce dal punto di vista produttivo per creare/testare/modificare.
Non è vero che l'assembler è usato in maniera estensiva nei kernel degli OS. In particolare, C è stato inventato apposta per non dover legare l'OS alla macchina. L'assembler viene usato nelle parti strettamente dipendenti dall'architettura. Ad esempio:

http://fxr.watson.org/fxr/source/i38...c.h?v=FREEBSD8
http://fxr.watson.org/fxr/source/arm...c.h?v=FREEBSD8
http://fxr.watson.org/fxr/source/spa...c.h?v=FREEBSD8

(nel terzo dovete andare un po' a fondo).

Il grosso del kernel sa che c'è una funzione chiamata atomic_set_32 e userà quella, indipendentemente dall'architettura, invece di stare a riempire il codice di #ifdef.

Infine: si, alcune cose vanno fatte per forza in asm. Come sfruttare la VFP-unit dell'ARMv6 (provate a inventarvi un compilatore che lo faccia meglio di un umano), come usare le SIMD dei processori (si, in genere ci sono le intrinsics del compilatore... ma sai che differenza...), sfruttare il CELL di PS3, etc. etc..

[Recidivo Visual]

Non è vero che l'assembler è usato in maniera estensiva nei kernel degli OS.

Non intentedevo questo.

Infine: si, alcune cose vanno fatte per forza in asm. Come sfruttare la VFP-unit dell'ARMv6 (provate a inventarvi un compilatore che lo faccia meglio di un umano), come usare le SIMD dei processori (si, in genere ci sono le intrinsics del compilatore... ma sai che differenza...), sfruttare il CELL di PS3, etc. etc..

Non si rimpiange mai di programmare in asm,
pero' son bei ricordi.

[giuseppemag]

Dopo aver letto 6 pagine di str... opinioni personali su didattica e approccio imperativo vs. funzionale, mi ci tuffo dentro anche io.

Per cominciare a programmare, C tutta la vita. È sintatticamente semplice, ha costrutti semplici.
L'aritmetica dei puntatori non la capiscono solo le capre ignoranti dato che sono addizioni, sottrazioni e basta sapere come è organizzata concettualmente la RAM in una macchina.

I costrutti con il C sono semplici.
Non insegni al ragazzino di tredici anni come descrivere, ma gli fai apprendere il significato operativo della cosa. Ovvero, non definisco il fattoriale, ma la procedura per calcolarlo.
Dopo, e soltanto dopo, si possono utilizzare figate (dal punto di vista di sinteticità sintattica) come la programmazione funzionale.
Sporcarsi le mani, capire come è possibile realizzare qualcosa, non ha prezzo.
Altrimenti è come provare a spiegare l'integrale senza passare dai concetti di somma, moltiplicazione e limite.

È per questo che avvengono brutte cose, come l'esempio dell'utente qualche post fa, dove trovi programmatori Java che usano puntatori tutto il tempo e non sanno cosa sia un puntatore (anche dove mi sono laureato io si faceva Java al primo anno e laboratorio di Algoritmi con C al secondo, e davvero ho visto troppi, troppi studenti perdersi sui puntatori. Questi qua teneteli lontano il più possibile dall'informatica applicata).

Passando ad altro:
non è vero che il codice C# viene tradotto da IL a linguaggio macchina alla prima esecuzione, la JIT agisce dove ritiene necessario, nonostante tutto è anni luce più avanti di Java.
Il 5-10% di prestazioni in meno rispetto a C mi giunge invece nuovo e stento un po' a crederci.
Il fatto che mono, o che qualche linguaggio di scripting venga utilizzato per fare videogiochi, non vuol dire che si possono rimpiazzare totalmente linguaggi a basso livello. Semplicemente, una volta progettato bene il tutto, scrivere "actor.moveTowards(player)", e poter modificare senza dover re-buildare tutto o parte, è il modo più veloce dal punto di vista produttivo per creare/testare/modificare.
Non è vero che l'assembler è usato in maniera estensiva nei kernel degli OS. In particolare, C è stato inventato apposta per non dover legare l'OS alla macchina. L'assembler viene usato nelle parti strettamente dipendenti dall'architettura. Ad esempio:

http://fxr.watson.org/fxr/source/i38...c.h?v=FREEBSD8
http://fxr.watson.org/fxr/source/arm...c.h?v=FREEBSD8
http://fxr.watson.org/fxr/source/spa...c.h?v=FREEBSD8

(nel terzo dovete andare un po' a fondo).

Il grosso del kernel sa che c'è una funzione chiamata atomic_set_32 e userà quella, indipendentemente dall'architettura, invece di stare a riempire il codice di #ifdef.

Infine: si, alcune cose vanno fatte per forza in asm. Come sfruttare la VFP-unit dell'ARMv6 (provate a inventarvi un compilatore che lo faccia meglio di un umano), come usare le SIMD dei processori (si, in genere ci sono le intrinsics del compilatore... ma sai che differenza...), sfruttare il CELL di PS3, etc. etc..

Uhm, "stronzate e opinioni personali" un piffero, ho citato un pacco di articoli peer-reviewed di gente con le contropalle sul tema. Poi che uno non si fidi della cultura scientifica bon, ma l'insulto gratuito era una cacchiata. Comunque passiamo ad altro, che l'intervento è molto intrigante


Intanto una nota tecnica: il JITter del C# compila l'entry point degli assembly e gli stub dei metodi giá in x86 (o quale che sia il codice macchina), che vengono riempite man mano che sono invocate e i moduli caricati. Quello che descrivi mi sembra il JITter della JVM. Non sono molto diversi, ma non mi pare che la tua descrizione sia accurata. In caso andiamo a cercare su msdn perché c'era un bell'articolo sui .Net Framework Internals!


Il C è un linguaggio sintatticamente semplice, true. Ciononostante è legato ad una semantica molto ben precisa, quella di una macchina con stack, heap e un singolo processore. Questa architettura è stata la piú diffusa fino ad alcuni anni fa, ma con l'avvento capillare delle macchine multi-core queste semantiche cominciano a mostrare il peso degli anni, e compilarle in modo efficiente e parallelizzarle automaticamente è molto difficile. Non a caso i sistemi piú usati per la concorrenza nel "mondo vero" sono funzionali/dichiarativi, con cose come task, futures, linq/plinq o gli attori di Erlang (**molto** usato nelle telecom).


Il problema che si pone è questo: insegniamo le architetture operazionali (A) o insegniamo a *ragionare sul codice* indipendentemente da linguaggio e architettura (B)? Io continuo a pensare CHE I DUE APPROCCI NON SI ESCLUDANO A VICENDA, e che è solo una questione di ordine: un buon programmatore sa sia ragionare sul codice che la semantica operazionale dell'assembly della sua CPU (per cui http://news.ycombinator.com/item?id=2466568 di Sony Entertainment non risulta arabo) ma sa anche ragionare sui modelli del codice (in modo da capire come le coroutines in Unity 3D funzionano). Se siamo d'accordo sono felice
Ora il secondo problema che si pone è quello di accattivare uno studente giovane in modo da permettergli di restare attento e interessato abbastanza da innescare un circolo virtuoso.

In conclusione, l'approccio (A) -> (B) va bene per la gente molto motivata, ma se ne perdono tantissimi di ragazzi con questo sistema se usato a scuola perché (A) viene percepito come noioso e troppo tecnico prima ancora di avere suscitato interesse; l'approccio (B) -> (A) rischia che gli studenti ignorino le cose di (B) perché percepite come inutilmente noiose dopo le cose piú divertenti/espressive di (A). L'approccio solo (A) genera gente che talvolta non sa organizzare bene il codice e spreca lavoro ad ottimizzare parti di codice non essenziali. L'approccio solo (B) genera inevitabilmente gente folle che scrive codice lentissimo ("0.1 è solo un fattore costante di slowdown, non è mica algoritmicamente inefficiente"). Insomma, dove la si tira la coperta è un po' corta...

[Edward Gein]

Uhm, "stronzate e opinioni personali" un piffero, ho citato un pacco di articoli peer-reviewed di gente con le contropalle sul tema. Poi che uno non si fidi della cultura scientifica bon, ma l'insulto gratuito era una cacchiata. Comunque passiamo ad altro, che l'intervento è molto intrigante

Str... non era rivolto a nessuno in particolare, ma in 6 pagine di topic ne ho lette.

Intanto una nota tecnica: il JITter del C# compila l'entry point degli assembly e gli stub dei metodi giá in x86 (o quale che sia il codice macchina), che vengono riempite man mano che sono invocate e i moduli caricati. Quello che descrivi mi sembra il JITter della JVM. Non sono molto diversi, ma non mi pare che la tua descrizione sia accurata. In caso andiamo a cercare su msdn perché c'era un bell'articolo sui .Net Framework Internals!

Mea culpa, hai perfettamente ragione, ho fatto un po' di confusione.

Il C è un linguaggio sintatticamente semplice, true. Ciononostante è legato ad una semantica molto ben precisa, quella di una macchina con stack, heap e un singolo processore. Questa architettura è stata la piú diffusa fino ad alcuni anni fa, ma con l'avvento capillare delle macchine multi-core queste semantiche cominciano a mostrare il peso degli anni, e compilarle in modo efficiente e parallelizzarle automaticamente è molto difficile. Non a caso i sistemi piú usati per la concorrenza nel "mondo vero" sono funzionali/dichiarativi, con cose come task, futures, linq/plinq o gli attori di Erlang (**molto** usato nelle telecom).

Va bene, ma il fatto che un linguaggio presenti dei costrutti per la parallelizzazione non toglie che, secondo me, di base bisogna avere un'idea del flusso delle cose. Voglio dire, se uno è curioso si chiede le cose di base. Mi ricordo che a quell'età (a dire il vero 7 anni prima, col C12 anche se vedevo già le "figate" (i giochi), mi esaltavo ugualmente scrivendo qualche riga di basic per leggere l'input e sommare numeri. Eppure ero lontanissimo dalle cose che vedevo fare ad altri, ma ero consapevole di fare dei progressi.
Poi dipende sempre dagli ambiti, in certi ambiti astrarsi dall'architettura è uno svantaggio.

Il problema che si pone è questo: insegniamo le architetture operazionali (A) o insegniamo a *ragionare sul codice* indipendentemente da linguaggio e architettura (B)? Io continuo a pensare CHE I DUE APPROCCI NON SI ESCLUDANO A VICENDA, e che è solo una questione di ordine: un buon programmatore sa sia ragionare sul codice che la semantica operazionale dell'assembly della sua CPU (per cui http://news.ycombinator.com/item?id=2466568 di Sony Entertainment non risulta arabo) ma sa anche ragionare sui modelli del codice (in modo da capire come le coroutines in Unity 3D funzionano). Se siamo d'accordo sono felice
Ora il secondo problema che si pone è quello di accattivare uno studente giovane in modo da permettergli di restare attento e interessato abbastanza da innescare un circolo virtuoso.

In conclusione, l'approccio (A) -> (B) va bene per la gente molto motivata, ma se ne perdono tantissimi di ragazzi con questo sistema se usato a scuola perché (A) viene percepito come noioso e troppo tecnico prima ancora di avere suscitato interesse; l'approccio (B) -> (A) rischia che gli studenti ignorino le cose di (B) perché percepite come inutilmente noiose dopo le cose piú divertenti/espressive di (A). L'approccio solo (A) genera gente che talvolta non sa organizzare bene il codice e spreca lavoro ad ottimizzare parti di codice non essenziali. L'approccio solo (B) genera inevitabilmente gente folle che scrive codice lentissimo ("0.1 è solo un fattore costante di slowdown, non è mica algoritmicamente inefficiente"). Insomma, dove la si tira la coperta è un po' corta...

Secondo me il problema da porsi è un altro: perché "accattivare" qualcuno a tutti i costi? Voglio dire, se ti piace sei motivato, altrimenti hai sbagliato indirizzo. Il problema dell'educazione di oggi è fondamentalmente questo: nel lavoro senza una laurea non entri, la laurea è necessaria quindi qualcosa bisogna pur farla, anche se da piccolo sogni di fare l'idraulico.
Ho conosciuto gente, ad esempio, che m'ha detto "faccio informatica perché mi piacciono i videogiochi", del tipo "boh, dovevo scegliere un corso di laurea, quindi ho scelto in base ad un criterio scorrelato".
L'opener del topic vuole un consiglio perché il ragazzino di 13 anni ha detto "mi interessa" o vuole provare ad "accattivarlo"? Se il ragazzo è già interessato, (A) è importante per le basi e secondo me adatto all'età, (B) arriverà col tempo se deciderà di proseguire lungo il percorso, e saprà capire se per un insieme di 10 elementi è meglio usare un array C piuttosto che un rb-albero per le operazioni di ricerca, se un quicksort è davvero necessario o se una roba si può fare scrivendo tre righe in Erlang piuttosto che 200 righe in C, perché tanto gira su macchine potenti e lo slowdown è trascurabile nel contesto.

Secondo me, che non sono un esperto di pedagogia e simili, sviluppare le inclinazioni di qualcuno rende più che sfruttare le sue doti (memoria, capacità logiche, etc. etc.) per fargli imparare qualcosa che non gli interessa.

[giuseppemag]

Voglio dire, se uno è curioso si chiede le cose di base. Mi ricordo che a quell'età (a dire il vero 7 anni prima, col C12 anche se vedevo già le "figate" (i giochi), mi esaltavo ugualmente scrivendo qualche riga di basic per leggere l'input e sommare numeri. Eppure ero lontanissimo dalle cose che vedevo fare ad altri, ma ero consapevole di fare dei progressi.

Si, capisco bene cosa intendi. Personalmente ho imparato puntatori, alberi e pathfinding in C/C++ sull'SDK delle DirectX 8.1. Per cui ho imparato abbastanza presto a divertirmi anche se scrivevo codice complicato senza avere riscontro diretto. Peró devo ammettere che il fatto di avere del riscontro ogni tanto (DirectX comunque usavo) mi ha permesso di divertirmi di piú e di avere piú entusiasmo, soprattutto a fronte del fatto che dovevo togliere tempo ad altre attivitá come lo studio scolastico e quindi avevo "un costo" da sostenere.

Secondo me il problema da porsi è un altro: perché "accattivare" qualcuno a tutti i costi? Voglio dire, se ti piace sei motivato, altrimenti hai sbagliato indirizzo. Il problema dell'educazione di oggi è fondamentalmente questo: nel lavoro senza una laurea non entri, la laurea è necessaria quindi qualcosa bisogna pur farla, anche se da piccolo sogni di fare l'idraulico.
Ho conosciuto gente, ad esempio, che m'ha detto "faccio informatica perché mi piacciono i videogiochi", del tipo "boh, dovevo scegliere un corso di laurea, quindi ho scelto in base ad un criterio scorrelato".
L'opener del topic vuole un consiglio perché il ragazzino di 13 anni ha detto "mi interessa" o vuole provare ad "accattivarlo"? Se il ragazzo è già interessato, (A) è importante per le basi e secondo me adatto all'età, (B) arriverà col tempo se deciderà di proseguire lungo il percorso, e saprà capire se per un insieme di 10 elementi è meglio usare un array C piuttosto che un rb-albero per le operazioni di ricerca, se un quicksort è davvero necessario o se una roba si può fare scrivendo tre righe in Erlang piuttosto che 200 righe in C, perché tanto gira su macchine potenti e lo slowdown è trascurabile nel contesto.

Secondo me, che non sono un esperto di pedagogia e simili, sviluppare le inclinazioni di qualcuno rende più che sfruttare le sue doti (memoria, capacità logiche, etc. etc.) per fargli imparare qualcosa che non gli interessa.

Uhm, questo è decisamente il punto più problematico. Purtroppo sugli educatori c'è una grossa pressione da parte della società che vuole che "nessuno sia lasciato indietro culturalmente", visto che è sempre più importante avere una preparazione approfondita in qualcosa per farcela nel sistema del lavoro corrente (con ovvie eccezioni!). Ovviamente ci sono coloro che sono interessati, e quelli sono già a posto come dici tu. Poi ci sono quelli che non sono interessati, e quelli amen, devono fare altro. Personalmente a me interessano quelli a metà; esiste un gruppo di persone che se adeguatamente stimolate possono fare della materia la loro strada personale con soddisfazione e buoni risultati. Questi studenti secondo me vanno appassionati con trucchi vari in modo che quando hanno acquisito confidenza e un bagaglio di esperienza decente non si scoraggino davanti alle cose più complesse. Non so se è chiaro quello che ho scritto, ma penso che questa alla fine sia davvero la parte centrale del discorso dal punto di vista filosofico

[Filosganga]

a dire il vero ho lurkato ma capendoci poco, causa incompetenza mia e non avendo modo di fornire un apporto alla discussione

mi rendo anche conto che chiedere in soldoni quale strada sia meglio intraprendere è futile, ho notato diversi pareri che portano in direzioni differenti.

purtroppo ancora non ho chiaro cosa rispondere a domande tipo: "cosa devo iniziare a studiare?"

più che rimandarlo alla guida online là non ho fatto, unitamente a installare Microsoft Visual C++ 2010 Express
che entrambi non abbiamo capito nemmeno come funzia

Prova a guardarti questo e quelli a fianco

http://www.youtube.com/watch?v=TDWXYKdLL-A

[DomenicoMugugno]

ciao a tutti, stò usando l'account di mio fratello per postare.
ho iniziato con questa lettura http://eineki.wordpress.com/2009/12/19/il-linguaggio-c/

però quando trasferisco questo

/* hello.c */

#include <stdio.h>

int main(void) {
printf ("Hello world!\n");
return 0;
}

dall'editor in dev c++ e tento di eseguirlo, appare una finestra di prompt per una frazione di secondo, potete dirmi dove sbaglio?

P.S. la sintassi è corretta come da esempio. Non mi era successo con small basic e pascal.

grazie

[giuseppemag]

ciao a tutti, stò usando l'account di mio fratello per postare.
ho iniziato con questa lettura http://eineki.wordpress.com/2009/12/19/il-linguaggio-c/

però quando trasferisco questo



dall'editor in dev c++ e tento di eseguirlo, appare una finestra di prompt per una frazione di secondo, potete dirmi dove sbaglio?

P.S. la sintassi è corretta come da esempio. Non mi era successo con small basic e pascal.

grazie

Aggiungi una lettura di tasto qualsiasi, cosí la console si ferma...

[masterz]

system("pause"); va bene uguale

[Lo Sparviero]

madò, mi ha fatto installare mezzo mondo, coso g++ , bloodshed dev c, mingw, etc

"io seguo le istruzioni, ma non riesco, mi aiuti?"

DERP

mo pare aver risolto usando coso Microsoft Visual C++ 2010 Express che ha già dentro il coso compila cosi lì