Linguaggio di programmazione per cominciare

[giuseppemag]

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.



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



Addio.

Che moccioso presuntuoso...

PS: BlackCaesar, citeresti la mia risposta?

[Kemper Boyd]

Invece di dover lottare per scegliere un paradigma, suggerisco - giusto per beccarmi insulti e flame - un linguaggio che non ne forza nessuno perche' ne permette diversi: Perl.

Puo' essere usato come rozzissimo linguaggio di scripting, come classico linguaggio imperativo con sintassi C-like, con paradigma OO (specialmente usando Moose), ed anche funzionale (il linguaggio supporta lambda/closures, le funzioni sono first-class objects, c'e' un fantastico libro sulla programmazione funzionale in Perl, disponibile liberamente: Higher-Order Perl).

[BlackCaesar]

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!

^this

[giuseppemag]

Invece di dover lottare per scegliere un paradigma, suggerisco - giusto per beccarmi insulti e flame - un linguaggio che non ne forza nessuno perche' ne permette diversi: Perl.

Puo' essere usato come rozzissimo linguaggio di scripting, come classico linguaggio imperativo con sintassi C-like, con paradigma OO (specialmente usando Moose), ed anche funzionale (il linguaggio supporta lambda/closures, le funzioni sono first-class objects, c'e' un fantastico libro sulla programmazione funzionale in Perl, disponibile liberamente: Higher-Order Perl).

Why not? Basta trovare cose divertenti da far fare...

Io tra l'altro piú che al paradigma mi riferisco alla sintassi, che in linguaggi del genere è molto piú facile e leggera da imparare. Ad esempio piuttosto che C suggerirei Python, se solo non fosse tipato dinamicamente e quindi un po' poco strutturato per un principiante!

[Kemper Boyd]

Anche python andrebbe bene. Peraltro ha si tipi dinamici pero' "forti" (non vanno dichiarati, ma non cambiano automaticamente durante l'uso). E di sicuro insegna rigore nell'indentazione

[giuseppemag]

Anche python andrebbe bene. Peraltro ha si tipi dinamici pero' "forti" (non vanno dichiarati, ma non cambiano automaticamente durante l'uso). E di sicuro insegna rigore nell'indentazione

Il rigore nell'indentazione secondo me è fondamentale, una delle ragioni per cui consiglio linguaggi tipo F# o Haskell: fa molto bene e non passa l'idea che l'indentazione è un optional. Ho visto abbastanza listati di studenti di C che non indentano da bastare per tutta la vita, e ho 26 anni

[hendor]

L'indentazione è qualcosa che va imparata indipendentemente dal linguaggio.
E anche l'abitudine a commentare il codice.

[giuseppemag]

L'indentazione è qualcosa che va imparata indipendentemente dal linguaggio.
E anche l'abitudine a commentare il codice.

Sante parole. Una buona documentazione che raccomando sempre ai beginners è quella su carta prima di iniziare

E l'indentazione è fondamentale, ma se il primo linguaggio te la forza non c'è nulla di male...

[~spiral~]

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!

Se il paper sarà pubblico avvisami che lo leggo volentieri!

Molto interessante questa esperienza, il problema è che questi sono esperimenti sporadici, se la scuola incentivasse di più questi "lab" non ci sarebbero classi di informatica formate da 3 persone interessate e altre che "tanto ad informatica non si fa nulla per tre anni, scegliamo quella". Più che altro a scuola pochi professori insegnano approccio e metodo, ma solo istruzioni da imparare a memoria. Un buon mix tra "cose che vedo funzionare" e "come queste cose devo scriverle" sarebbe l'ideale a mio parere.

Una domanda su .NET invece, quale pensi che sarà la direzione futura della piattaforma, un C# con sempre più innesti "funzionali" et simila (quando avevo visto per la prima volta un articolo del futuro "async" stavo per buttare tutto il codice già scritto dalla finestra ), o piuttosto un F# che prende più spazio e si affianca a C# (C# che quindi rimane più orientato a paradigmi OOP) per la parte funzionale? Credo più la prima delle due, anche perchè per ora non vedo molte conferenze tecniche pubblicizzate da technet o partners riguardo a F#, ma piuttosto su Parallel Framework, WPF e novità future di C# 5.0.
Rispondevo proprio l'altro giorno ad un post molto interessante su un blog di un famoso relatore di UGI.NET, Raffaele Rialdi (che non conosco direttamente, ma di cui ho seguito alcune belle sessioni in passato), che riguardava la sicurezza in ambiente MVC/JSON. Chiedevo appunto come mai la sicurezza (in particolare in ambiente web) fosse un discorso sempre poco "centrale" nei blog e nelle colonne tecniche, e che spesso si trovavano a fatica buoni articoli al riguardo. Alla fine concordavamo che probabilmente non era "trend" e "moda" parlare al pubblico di security, e che alla fine credo che prevalga sempre la logica di business imposta da Microsoft (ovviamente, dato che una società promuove i suoi nuovi prodotti, ma anche purtroppo, dato che diffondere un po'di più l'argomento non farebbe male). Per questo mi chiedevo anche che ruolo avrà F#, perchè non se ne parla moltissimo.

[giuseppemag]

Se il paper sarà pubblico avvisami che lo leggo volentieri!

Molto interessante questa esperienza, il problema è che questi sono esperimenti sporadici, se la scuola incentivasse di più questi "lab" non ci sarebbero classi di informatica formate da 3 persone interessate e altre che "tanto ad informatica non si fa nulla per tre anni, scegliamo quella". Più che altro a scuola pochi professori insegnano approccio e metodo, ma solo istruzioni da imparare a memoria. Un buon mix tra "cose che vedo funzionare" e "come queste cose devo scriverle" sarebbe l'ideale a mio parere.

Te lo giro qua appena è finito, allora!

Comunque sappi che ci vorranno anni prima di capire questo approccio all'informatica orientato all'applicazione, e in generale questo è vero in giro per tutto il mondo stando ai ricercatori di Computer Science Education e i loro ultimi paper; è consolante che come nazione siamo indietro ma solo poco, per un volta . Qualcuno in USA/UK/Germania/... comincia adesso a coinvolgere le scuole medie e superiori in modo sporadico con progetti medio lunghi tipo insegnare il game development al posto delle introduzioni di informatica. Molti hanno usato linguaggi tipo ActionScript che hanno un ambiente molto visuale, altri addirittura Game Maker, altri ancora hanno creato piattaforme apposite (http://www.greenfoot.org/), ma tutto sommato stiamo andando nella giusta direzione.

Finché non viene sperimentato tanto, ma tanto, ma tanto ed è evidente, ma evidente, che funziona il ministero non se ne accorgerá proprio per nulla

Una domanda su .NET invece, quale pensi che sarà la direzione futura della piattaforma, un C# con sempre più innesti "funzionali" et simila (quando avevo visto per la prima volta un articolo del futuro "async" stavo per buttare tutto il codice già scritto dalla finestra ), o piuttosto un F# che prende più spazio e si affianca a C# (C# che quindi rimane più orientato a paradigmi OOP) per la parte funzionale? Credo più la prima delle due, anche perchè per ora non vedo molte conferenze tecniche pubblicizzate da technet o partners riguardo a F#, ma piuttosto su Parallel Framework, WPF e novità future di C# 5.0.
Rispondevo proprio l'altro giorno ad un post molto interessante su un blog di un famoso relatore di UGI.NET, Raffaele Rialdi (che non conosco direttamente, ma di cui ho seguito alcune belle sessioni in passato), che riguardava la sicurezza in ambiente MVC/JSON. Chiedevo appunto come mai la sicurezza (in particolare in ambiente web) fosse un discorso sempre poco "centrale" nei blog e nelle colonne tecniche, e che spesso si trovavano a fatica buoni articoli al riguardo. Alla fine concordavamo che probabilmente non era "trend" e "moda" parlare al pubblico di security, e che alla fine credo che prevalga sempre la logica di business imposta da Microsoft (ovviamente, dato che una società promuove i suoi nuovi prodotti, ma anche purtroppo, dato che diffondere un po'di più l'argomento non farebbe male). Per questo mi chiedevo anche che ruolo avrà F#, perchè non se ne parla moltissimo.

C# sta evolvendosi sempre di piú in modo da essere un bel linguaggio OO con innesti funzionali. Gli innesti funzionali sembra vengano inseriti con molta cautela e solo dove sono sintatticamente eleganti e molto utili; d'altro canto F# invece è un bel linguaggio funzionale e basta in cui vengono messe tutte le cose piú avanzate, ad esempio quotations e monadi...
L'anno prossimo inizieró con Microsoft Academic Italia a sperimentare la risposta che hanno l'accademia e gli studenti universitari nei confronti di F#. Abbiamo giá fatto qualche talk sporadico durante l'anno in corso con ottimi risultati, e gli studenti sembrano molto interessati da un linguaggio che sembra accademico ma in realtá ha un IDE "da linguaggio vero". Proveremo ad oganizzare un tour nazionale delle universitá e vediamo che succede in termini di feedback e partecipazione.

Se poi la cosa ha successo, come è stato per XNA (stesso processo identico) allora si passa alle conferenze nazionali tipo TechDays, Remix, etc...


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!

[giuseppemag]

Se il paper sarà pubblico avvisami che lo leggo volentieri!

Molto interessante questa esperienza, il problema è che questi sono esperimenti sporadici, se la scuola incentivasse di più questi "lab" non ci sarebbero classi di informatica formate da 3 persone interessate e altre che "tanto ad informatica non si fa nulla per tre anni, scegliamo quella". Più che altro a scuola pochi professori insegnano approccio e metodo, ma solo istruzioni da imparare a memoria. Un buon mix tra "cose che vedo funzionare" e "come queste cose devo scriverle" sarebbe l'ideale a mio parere.

Una domanda su .NET invece, quale pensi che sarà la direzione futura della piattaforma, un C# con sempre più innesti "funzionali" et simila (quando avevo visto per la prima volta un articolo del futuro "async" stavo per buttare tutto il codice già scritto dalla finestra ), o piuttosto un F# che prende più spazio e si affianca a C# (C# che quindi rimane più orientato a paradigmi OOP) per la parte funzionale? Credo più la prima delle due, anche perchè per ora non vedo molte conferenze tecniche pubblicizzate da technet o partners riguardo a F#, ma piuttosto su Parallel Framework, WPF e novità future di C# 5.0.
Rispondevo proprio l'altro giorno ad un post molto interessante su un blog di un famoso relatore di UGI.NET, Raffaele Rialdi (che non conosco direttamente, ma di cui ho seguito alcune belle sessioni in passato), che riguardava la sicurezza in ambiente MVC/JSON. Chiedevo appunto come mai la sicurezza (in particolare in ambiente web) fosse un discorso sempre poco "centrale" nei blog e nelle colonne tecniche, e che spesso si trovavano a fatica buoni articoli al riguardo. Alla fine concordavamo che probabilmente non era "trend" e "moda" parlare al pubblico di security, e che alla fine credo che prevalga sempre la logica di business imposta da Microsoft (ovviamente, dato che una società promuove i suoi nuovi prodotti, ma anche purtroppo, dato che diffondere un po'di più l'argomento non farebbe male). Per questo mi chiedevo anche che ruolo avrà F#, perchè non se ne parla moltissimo.

E il bello è che per questa discussione sono stato infilato in Ignore List da quell'altro...

[blue_tech]

ma toglietemi una curiosità qui parlate di ragazzi delle superiori, di università, di mondo del lavoro ma avete dimenticato il target del topic? IL TARGET!

Un ragazzino di 13 anni!

Le cose di cui parlate sono cose (oserei dire) innovative ed è come prendere uno che mostra interesse per la medicina e parlargli subito delle staminali senza passare dal buon vecchio esame di anatomia...


E poi perdonatemi ma se studierà informatica si scontrerà ,pensate un pò, con i sistemi operativi, con le reti, con Unix ecc... ecc... e sempre per sottolineare una cosa che dovrebbe esservi ovvia in tutte ste cose il C regna sovrano. Non potete pensare di non fornire gli strumenti per affrontare gran parte del mondo reale. Si insegna partendo da lì, poi se l'interesse cresce si va sul nuovo e sul moderno. Avrà modo di apprezzare le differenze e via così ma se gli mettono davanti il codice C, deve capirlo.

Parliamo poi, esulando dal target del topic, di prestazioni: voi mi citate l'efficienza e poi mi proponete cose come il python et simila che sono interpretati. INTERPRETATI. Vi siete mai chiesti perchè i S.O. e le applicazioni serie le scrivono in C/C++ e varie parti ancora in assembly?

Per le prestazioni. Non dover gestire le variabili rende idealmente più semplici le cose ma il problema è che perdi in prestazioni. E potete dire quello che volete è un dato di fatto.

I videogiochi sono in gran parte scritti in c++ non in python o un qualsivoglia linguaggio interpretato.

Detto ciò non intendo dire che non servano i linguaggi funzionali o che non abbiano dei vantaggi ma uno deve sapere come gira il mondo prima di avventurarsi nello spazio.

Pace e bene.

[BlackCaesar]

Ma chi l'ha detto che i linguaggi funzionali perdono in prestazioni???? Dipenderà dal compilatore come per tutti i linguaggi no?! Hai fatto test temporali per poterlo affermare?

Ah, tra l'altro, ormai in Assembly non si scrivono più nemmeno i compilatori (in realtà da 15-20 anni). Credo si scrivano solo i Driver in assembly, (ma forse utilizzano adirittura il C anche per quello).

[blue_tech]

Ma chi l'ha detto che i linguaggi funzionali perdono in prestazioni???? Dipenderà dal compilatore come per tutti i linguaggi no?! Hai fatto test temporali per poterlo affermare?

Ah, tra l'altro, ormai in Assembly non si scrivono più nemmeno i compilatori (in realtà da 15-20 anni). Credo si scrivano solo i Driver in assembly, (ma forse utilizzano adirittura il C anche per quello).

na assembly viene usato ancora in alcuni casi nella scrittura dei SO e alcuni mi pare anche in alcuni passaggi per i videogiochi per ottimizzare le prestazioni.

poi io ho parlato di linguaggi interpretati. e se un linguaggio è interpretato non ha un compilatore per definizione. c'è l'interprete. E sempre per definizione un linguaggio interpretato è più lento. Se poi hai un linguaggio funzionale che è compilato e non interpretato il discorso è diverso ma mi sembra difficile perchè la caratteristica di non dover dichiarare variabili di solito è propria dei linguaggi interpretati (php, python, perl, ...)

[blue_tech]

poi tanto per dirne ancora un paio l'assembly viene usato in sicurezza... ci scrivono i virus in assemly anche e non escludo che parte dei motori dei software antivirus siano scritti in assemlbly per le prestazioni. In ogni modo bisogna saperlo leggere e saperci lavorare se vuoi capire il virus.

Non mi pronuncio sulle reti ma sono abbastanza sicuro che parte del codice per implementare i protocolli sia scritto in assembly anche perchè si va molto a basso livello...


per ora mi sono saltate in mente queste situazioni... ma sono sicuro che ce ne siano altri sicuramente. Tipo chi sviluppa strumenti nuovi da interfacciare a pc ecc... senza assembly non programmi i chip, non scrivi i driver, ecc... ecc...

(scusate gli errori di scrittura ma ho scritto in fretta )

EDIT: e come ho già scritto sopra non parliamo dei SO che hanno una buona parte scritta in assembly... KERNEL anyone?

[Kemper Boyd]

ma toglietemi una curiosità qui parlate di ragazzi delle superiori, di università, di mondo del lavoro ma avete dimenticato il target del topic? IL TARGET!

Un ragazzino di 13 anni!

Le cose di cui parlate sono cose (oserei dire) innovative ed è come prendere uno che mostra interesse per la medicina e parlargli subito delle staminali senza passare dal buon vecchio esame di anatomia...


E poi perdonatemi ma se studierà informatica si scontrerà ,pensate un pò, con i sistemi operativi, con le reti, con Unix ecc... ecc... e sempre per sottolineare una cosa che dovrebbe esservi ovvia in tutte ste cose il C regna sovrano. Non potete pensare di non fornire gli strumenti per affrontare gran parte del mondo reale. Si insegna partendo da lì, poi se l'interesse cresce si va sul nuovo e sul moderno. Avrà modo di apprezzare le differenze e via così ma se gli mettono davanti il codice C, deve capirlo.

Parliamo poi, esulando dal target del topic, di prestazioni: voi mi citate l'efficienza e poi mi proponete cose come il python et simila che sono interpretati. INTERPRETATI. Vi siete mai chiesti perchè i S.O. e le applicazioni serie le scrivono in C/C++ e varie parti ancora in assembly?

Per le prestazioni. Non dover gestire le variabili rende idealmente più semplici le cose ma il problema è che perdi in prestazioni. E potete dire quello che volete è un dato di fatto.

I videogiochi sono in gran parte scritti in c++ non in python o un qualsivoglia linguaggio interpretato.

Detto ciò non intendo dire che non servano i linguaggi funzionali o che non abbiano dei vantaggi ma uno deve sapere come gira il mondo prima di avventurarsi nello spazio.

Pace e bene.

Ma scusa prima parti ricordando il target e poi finisci per scartare i linguaggi interpretati per via delle prestazioni? In che modo le prestazioni sono rilevanti se devi cominciare ad affrontare la programmazione?

Per cominciare a programmare personalmente penso che un linguaggio interpretato sia molto piu' abbordabile, visto che accorcia il ciclo modifica del codice -> verifica di cio' che accade e maschera molte cose con astrazioni piu' digeribili. Poi per approfondire c'e' sempre tempo. E' vero che il C come sintassi e' molto semplice, ma per capire i veri concetti che rendono il C tutt'ora usato, ci vuole tanto tempo e tanta esperienza. Io sono convinto che il C andrebbe studiato DOPO altri linguaggi, quando si ha gia' una buona familiarita' con i concetti base. Partire con gestione dell'allocazione della memoria, aritmetica dei puntatori, overflow, memory leaks puo' essere molto frustrante. La motivazione e' molto importante se si vuole andare avanti, e vedere risultati soddisfacenti entro breve tempo e' un'ottima motivazione a proseguire.

Peraltro dire che le "applicazioni serie le scrivono in C/C++ e varie parti ancora in assembly" e' fuorviante, perche' dipende dagli ambiti. Non esiste solo la programmazione di OS e driver al mondo, e i linguaggi interpretati vengono usati in tantissime applicazioni serie, perche' in molti casi la pura ottimizzazione del codice non e' il punto piu' importante.

[BlackCaesar]

na assembly viene usato ancora in alcuni casi nella scrittura dei SO e alcuni mi pare anche in alcuni passaggi per i videogiochi per ottimizzare le prestazioni.

poi io ho parlato di linguaggi interpretati. e se un linguaggio è interpretato non ha un compilatore per definizione. c'è l'interprete. E sempre per definizione un linguaggio interpretato è più lento. Se poi hai un linguaggio funzionale che è compilato e non interpretato il discorso è diverso ma mi sembra difficile perchè la caratteristica di non dover dichiarare variabili di solito è propria dei linguaggi interpretati (php, python, perl, ...)

In Haskell c'è sia la modalità interprete che il compilatore che crea un file binario.

[giuseppemag]

Le cose di cui parlate sono cose (oserei dire) innovative ed è come prendere uno che mostra interesse per la medicina e parlargli subito delle staminali senza passare dal buon vecchio esame di anatomia...

E poi perdonatemi ma se studierà informatica si scontrerà ,pensate un pò, con i sistemi operativi, con le reti, con Unix ecc... ecc... e sempre per sottolineare una cosa che dovrebbe esservi ovvia in tutte ste cose il C regna sovrano. Non potete pensare di non fornire gli strumenti per affrontare gran parte del mondo reale. Si insegna partendo da lì, poi se l'interesse cresce si va sul nuovo e sul moderno. Avrà modo di apprezzare le differenze e via così ma se gli mettono davanti il codice C, deve capirlo.

Parliamo poi, esulando dal target del topic, di prestazioni: voi mi citate l'efficienza e poi mi proponete cose come il python et simila che sono interpretati. INTERPRETATI. Vi siete mai chiesti perchè i S.O. e le applicazioni serie le scrivono in C/C++ e varie parti ancora in assembly?

Per le prestazioni. Non dover gestire le variabili rende idealmente più semplici le cose ma il problema è che perdi in prestazioni. E potete dire quello che volete è un dato di fatto.

I videogiochi sono in gran parte scritti in c++ non in python o un qualsivoglia linguaggio interpretato.

Detto ciò non intendo dire che non servano i linguaggi funzionali o che non abbiano dei vantaggi ma uno deve sapere come gira il mondo prima di avventurarsi nello spazio.

Pace e bene.

[/SIZE]

Partiamo da un "grazie" per un bel contributo alla discussione



Beh, intanto non mi sembra che i linguaggi funzionali siano poi cosí tanto piú lenti di C/C++, soprattutto se poi si normalizza per lunghezza del codice (una misura molto approssimativa del costo di sviluppo):

http://shootout.alioth.debian.org/u6...re-fastest.php

I linguaggi funzionali che ho menzionato io (Haskell, F#, Scala) sono tutti compilati. OcaML, altro bel linguaggio, è ottimizzato da paura e ci sono benchmarks in cui fa veramente cose incredibili. Certo, C/C++ vince sempre, ma a costi di sviluppo davvero paurosi. Una nota importante è che i compilatori dei linguaggi funzionali raramente si sono occupati di ottimizzazione, ma quelli che lo hanno fatto (soprattutto intorno a LISP) se la giocavano tranquilli con il C.

Al momento sono il project leader di un gioco commerciale che uso sia per scopi di ricerca che per pubblicarlo su Xbox Live Arcade con Idoru. Il C++ non ci serve. Certo, è un gioco indie, ma se mai avessimo un team piú grande non allocherei mai risorse a scrivere niente in C++ se non le parti piú strette dell'inner loop. Pensa che EA ha usato mono pesantemente nei Sims 3 (http://www.mono-project.com/Companies_Using_Mono), per cui quello di cui parli tu è certamente stato vero fino a qualche anno fa, ma adesso sta cambiando fortemente. E Python muove buona parte del codice di EVE (http://www.slideshare.net/Arbow/stackless-python-in-eve).

Nel mondo delle applicazioni di basso livello (SO, embedded, etc.) certamente C e ASM la fanno ancora da padrona, anche se qualcuno che studia se veramente è necessario e se non vale la pena migrare a linguaggi di alto livello c'è eccome (http://en.wikipedia.org/wiki/Singula...erating_system), http://tommd.wordpress.com/2009/09/1...es-in-haskell/).


Peace out anche a te

[giuseppemag]

In Haskell c'è sia la modalità interprete che il compilatore che crea un file binario.

Come in F#: c'è questa tendenza dei linguaggi funzionali ad avere un sistema di testing integrato molto veloce e interpretato + il compilatore. Niente vieta di avere interprete e compilatore per lo stesso linguaggio, anzi ha molto senso!

[giuseppemag]

na assembly viene usato ancora in alcuni casi nella scrittura dei SO e alcuni mi pare anche in alcuni passaggi per i videogiochi per ottimizzare le prestazioni.

poi io ho parlato di linguaggi interpretati. e se un linguaggio è interpretato non ha un compilatore per definizione. c'è l'interprete. E sempre per definizione un linguaggio interpretato è più lento. Se poi hai un linguaggio funzionale che è compilato e non interpretato il discorso è diverso ma mi sembra difficile perchè la caratteristica di non dover dichiarare variabili di solito è propria dei linguaggi interpretati (php, python, perl, ...)

Ti chiedo scusa ma qua devo correggere perché mi sembra ci sia qualcosa di poco chiaro:

nei linguaggi funzionali variabili e bindings possono sia essere dichiarati staticamente che dinamicamente, dipende dal linguaggio. I linguaggi della famiglia LISP (Lisp + Scheme + Racket + ...) sono linguaggi dinamici in cui il tipo delle cose viene determinato a runtime, e in questo sono relativamente simili ai linguaggi interpretati imperativi che menzioni. Ciononostante questi linguaggi sono comunque COMPILATI!

I linguaggi della famiglia Miranda/ML (Haskell, OcaML, F#) sono invece tipati staticamente, quindi piú vicini al blocco C/C++/C#/Java.


Per riassumere e forse fare un po' di chiarezza, ci sono vari assi indipendenti in un linguaggio:
- tipato staticamente o dinamicamente?
- interpretato o compilato?
- imperativo o (funzionale) puro?

e niente vieta di prendere un qualsiasi punto del cubo risultante, ossia possiamo avere un linguaggio che supporta tipi statici e dinamici, è compilato ed è sia imperativo che funzionale (C#). Possiamo avere un linguaggio con tipi dinamici, interpretato e sia imperativo che funzionale (Python). E cosí via...

[giuseppemag]

La motivazione e' molto importante se si vuole andare avanti, e vedere risultati soddisfacenti entro breve tempo e' un'ottima motivazione a proseguire.

Sante parole: ho visto molti studenti perdersi iniziando dal C perché si annoiano e perché non riescono a far fare alla macchina quello che vogliono (di solito vogliono realizzare cose che ricordino le applicazioni che solitamente loro usano)...

[blue_tech]

Ma scusa prima parti ricordando il target e poi finisci per scartare i linguaggi interpretati per via delle prestazioni? In che modo le prestazioni sono rilevanti se devi cominciare ad affrontare la programmazione?

Per cominciare a programmare personalmente penso che un linguaggio interpretato sia molto piu' abbordabile, visto che accorcia il ciclo modifica del codice -> verifica di cio' che accade e maschera molte cose con astrazioni piu' digeribili. Poi per approfondire c'e' sempre tempo. E' vero che il C come sintassi e' molto semplice, ma per capire i veri concetti che rendono il C tutt'ora usato, ci vuole tanto tempo e tanta esperienza. Io sono convinto che il C andrebbe studiato DOPO altri linguaggi, quando si ha gia' una buona familiarita' con i concetti base. Partire con gestione dell'allocazione della memoria, aritmetica dei puntatori, overflow, memory leaks puo' essere molto frustrante. La motivazione e' molto importante se si vuole andare avanti, e vedere risultati soddisfacenti entro breve tempo e' un'ottima motivazione a proseguire.

Peraltro dire che le "applicazioni serie le scrivono in C/C++ e varie parti ancora in assembly" e' fuorviante, perche' dipende dagli ambiti. Non esiste solo la programmazione di OS e driver al mondo, e i linguaggi interpretati vengono usati in tantissime applicazioni serie, perche' in molti casi la pura ottimizzazione del codice non e' il punto piu' importante.

come avrai notato ho sottolineato il target e ne ho parlato e poi mi sono adattato alla vostra discussione specificando che per quella parte di discorso tralasciavo il target

Partiamo da un "grazie" per un bel contributo alla discussione



Beh, intanto non mi sembra che i linguaggi funzionali siano poi cosí tanto piú lenti di C/C++, soprattutto se poi si normalizza per lunghezza del codice (una misura molto approssimativa del costo di sviluppo):

http://shootout.alioth.debian.org/u6...re-fastest.php

I linguaggi funzionali che ho menzionato io (Haskell, F#, Scala) sono tutti compilati. OcaML, altro bel linguaggio, è ottimizzato da paura e ci sono benchmarks in cui fa veramente cose incredibili. Certo, C/C++ vince sempre, ma a costi di sviluppo davvero paurosi. Una nota importante è che i compilatori dei linguaggi funzionali raramente si sono occupati di ottimizzazione, ma quelli che lo hanno fatto (soprattutto intorno a LISP) se la giocavano tranquilli con il C.

Al momento sono il project leader di un gioco commerciale che uso sia per scopi di ricerca che per pubblicarlo su Xbox Live Arcade con Idoru. Il C++ non ci serve. Certo, è un gioco indie, ma se mai avessimo un team piú grande non allocherei mai risorse a scrivere niente in C++ se non le parti piú strette dell'inner loop. Pensa che EA ha usato mono pesantemente nei Sims 3 (http://www.mono-project.com/Companies_Using_Mono), per cui quello di cui parli tu è certamente stato vero fino a qualche anno fa, ma adesso sta cambiando fortemente. E Python muove buona parte del codice di EVE (http://www.slideshare.net/Arbow/stackless-python-in-eve).

Nel mondo delle applicazioni di basso livello (SO, embedded, etc.) certamente C e ASM la fanno ancora da padrona, anche se qualcuno che studia se veramente è necessario e se non vale la pena migrare a linguaggi di alto livello c'è eccome (http://en.wikipedia.org/wiki/Singularity_(operating_system), http://tommd.wordpress.com/2009/09/1...es-in-haskell/).


Peace out anche a te

Ti chiedo scusa ma qua devo correggere perché mi sembra ci sia qualcosa di poco chiaro:

nei linguaggi funzionali variabili e bindings possono sia essere dichiarati staticamente che dinamicamente, dipende dal linguaggio. I linguaggi della famiglia LISP (Lisp + Scheme + Racket + ...) sono linguaggi dinamici in cui il tipo delle cose viene determinato a runtime, e in questo sono relativamente simili ai linguaggi interpretati imperativi che menzioni. Ciononostante questi linguaggi sono comunque COMPILATI!

I linguaggi della famiglia Miranda/ML (Haskell, OcaML, F#) sono invece tipati staticamente, quindi piú vicini al blocco C/C++/C#/Java.


Per riassumere e forse fare un po' di chiarezza, ci sono vari assi indipendenti in un linguaggio:
- tipato staticamente o dinamicamente?
- interpretato o compilato?
- imperativo o (funzionale) puro?

e niente vieta di prendere un qualsiasi punto del cubo risultante, ossia possiamo avere un linguaggio che supporta tipi statici e dinamici, è compilato ed è sia imperativo che funzionale (C#). Possiamo avere un linguaggio con tipi dinamici, interpretato e sia imperativo che funzionale (Python). E cosí via...

però spetta parli del blocco c/c++/java/C# ma non è un blocco... cioè sono simili come sintassi ma java è interpretato e mi pare anche c# (o no? ) il compilato che fa java e bytecode che viene poi interpretato... è il motivo per cui i programmi stile openoffice sono di solito più pesanti... perchè cmq un applicativo java per quanto ottimizzato sarà cmq più lento di un equivalente c++

Tu per compilati intendi che vengono compilati specificatamente per il sistema su cui si trovano e quindi alla fine hai un binario reale o è uno pseudocompilato tipo java che poi però alla fine è sempre interpretato?

Sante parole: ho visto molti studenti perdersi iniziando dal C perché si annoiano e perché non riescono a far fare alla macchina quello che vogliono (di solito vogliono realizzare cose che ricordino le applicazioni che solitamente loro usano)...

si però se tu gli insegni a non ragionare su quello che sta sotto, quando poi arriveranno a doverlo studiare sarà un impatto ancora più traumatico perchè loro saranno abituati a non pensare a cosa stanno comandando.


E' come mandare uno sull'autoscontro a imparare a guidare. Quando arriva in una macchina vera ha il "trauma"... Meglio imparare prima con calma e pazienza a guidare e poi se esce una macchina automatica che mi risparmia la fatica buon per me ma un domani se devo guidare la macchina dell'amico posso farlo senza problemi.

[Kemper Boyd]

si però se tu gli insegni a non ragionare su quello che sta sotto, quando poi arriveranno a doverlo studiare sarà un impatto ancora più traumatico perchè loro saranno abituati a non pensare cosa stanno comandando.

Non sono assolutamente d'accordo. Apprendere prima un linguaggio di livello piu' alto ti insegna le cose un po' per volta, e sono convinto che la gradualita' nell'apprendimento sia fondamentale. Se per te e' piu' facile scontrarsi direttamente con l'ostacolo piu' alto, boh a me sembra assurdo.

[blue_tech]

ho fatto spesso l'esempio della mia università dove al primo anno fanno java e al secondo devi scontrarti con C. Ora potete immaginare la gente alle prese con liste, puntatori, allocazioni di memoria...

In java queste cose son trasparenti ed è un bene quando cmq sai che ci sono e come funzionano perchè ti tolgono un fastidio ma ne sei consapevole. Nel loro caso il fastidio se lo trovano il 2° anno con il fatto che sono del tutto spaesati perchè arrivano dal JAVA.

Per fare un esempio io ho imparato gli alberi col C++, è uno sbattimento perchè lavorarci e gestire i puntatori per tutte le operazioni non è simpatico, ma maledizione ho imparato a lavorare con i puntatori.
Certe cose non si possono sottointendere se non sai che esistono e come funzionano.

Tenete presente il famigerato NULL_POINTER_EXCEPTION in java. Come lo gestisci se non sai cos'è un puntatore?

[Kemper Boyd]

Ho capito, ma non concordo sul fatto che uno sia piu' spaesato se conosce gia' un linguaggio. Cioe' lo sara' se e' totalmente privo di elasticita' mentale, ma quello e' un problema della persona, non del metodo di insegnamento. Altimenti non e' che sia piu' facile capire i puntatori da zero.

O vuoi dire che e' java in particolare che ti annebbia il cervello?