Il talk e' stato interessante anche se io non ne condivido per nulla l'idea di fondo. Utilizzare C++ per insegnare a programmare e' secondo me assurdo per colpa di due problemi principali:
- Il linguaggio e' complicatissimo: se e' vero che si puo' scrivere codice elegante e compatto che fa la cosa giusta in modo efficiente e' anche vero che si puo' scrivere altro codice altrettanto elegante e compatto che invece fa esplodere il computer come nei film scifi anni 80.
- Quando si commettono errori non ci sono "runtime error angels" ma solo "undefined behavior daemons". Imparare il C++ per tentativi utilizzandolo e' un suicidio.
In generale credo che l'approccio "top down" proposto sia estremamente pericoloso perche' porta solo all'illusione di aver capito (illusione che in C++ si paga a caro prezzo).
L'astrazione high level del C++ fa acqua da tutte le parti (e' "leaky") ed e' secondo me comoda e potente solo se ne si comprendono i limiti e si capisce come e' costruita (ovvero se si arriva "dal basso" come comprensione).
Interessante come provocazione e come "esperimento didattico", mi ha sorpreso che si riesca ad arrivare così in là attenendosi alle "regole" mostrate nel talk.
Temo però che nel "mondo vero" la cosa non stia particolarmente in piedi, visto che le astrazioni C++ sono *estremamente* fragili, e nel momento in cui si rompono per memorizzare cosa non si deve fare è necessario spiegarne il perché, e lì ci si va inevitabilmente a sporcare le mani o con dettagli di basso livello, o con questioni storiche di standardizzazione del linguaggio che rompono definitivamente il "giardino dorato" costruito con le regole esposte nel talk.
Purtroppo temo che per "insegnare a capire" il C++ sia inevitabile tenere contemporaneamente presente i tre livelli - quello che è l'astrazione che si sta utilizzando ("cos'è un metodo di una classe" in astratto), i problemi implementativi di basso livello ("un metodo viene implementato come una funzione libera con un parametro this nascosto") e quello che dice esattamente il Sacro Standard ("chiamare un metodo su un puntatore null è sempre e comunque undefined behavior, anche se non accedi esplicitamente a campi della classe"); senza (1) non si può scrivere codice sensato, senza (2) non si può scrivere codice efficiente e risulta difficile capire e memorizzare il perché di tante scelte "strane" a livello di linguaggio, senza (3) si rischia di cadere nelle trappole dell'undefined behavior.
Infine, il talk prendeva come caso di studio l'insegnamento del C++ a persone nuove al mondo della programmazione, sostenendo che questa è una base per persone che di loro non sono interessate alla programmazione "in sé e per sé", ma che hanno bisogno di uno strumento che gli serve "farci cose" (caso tipico: ingegneri, scienziati, eccetera).
L'errore di fondo secondo me è sperare di trovare un subset del C++ per "semplici utenti" che possa essere lo strumento in questione. C++ non nasce per questo, sicuramente non si è evoluto in questa direzione e cercare di insegnarlo in questa maniera non ha molto significato - se devi insegnare a qualcuno un linguaggio in cui "fare cose" (possibilmente da subito), imparare provando e ottenendo feedback da compilatore e runtime (cosa non attuabile in C++ per via dell'undefined behavior) il C++ purtroppo è il linguaggio sbagliato.
L'unicità del C++ è il fornire astrazioni di livello molto alto (con tutti i distinguo del caso) ma con la possibilità di scendere di livello a piacimento quando serve, in tandem con la possibilità di interagire con codice C (API di sistema in primis, oltre a un parco sconfinato di librerie) in maniera diretta. Se ad una persona interessano queste nicchie il C++ "solo di altissimo livello" esposto nel talk non serve a niente - i puntatori e compagnia sono un must; al di fuori di questi e pochi altri casi, ci sono linguaggi molto più coerenti e approcciabili con meno lacrime e sangue da un programmatore inesperto con cui può applicarsi ai problemi che effettivamente vuole risolvere, senza per questo sacrificare le prestazioni o il "parco librerie".
Il talk è stato interessante e le premesse sul fatto di essere "provocatorio" sono state più che mai utili. Per me che ho fatto (come tanti di noi) molta gavetta sul C, credo che questo punto di vista piuttosto dirompente possa essere uno spunto di riflessione forse non nell'immediato ma nel lungo periodo. Sono d'accordo sul fatto che sia difficile prescindere dal concetto di puntatore, ma credo che il messaggio fosse soprattutto di lanciare un warning nei confronti di metodi di insegnamento datati e forse obsoleti per le generazioni di sviluppatori future.
Comments
Comments are closed.
Il talk e' stato interessante anche se io non ne condivido per nulla l'idea di fondo. Utilizzare C++ per insegnare a programmare e' secondo me assurdo per colpa di due problemi principali:
- Il linguaggio e' complicatissimo: se e' vero che si puo' scrivere codice elegante e compatto che fa la cosa giusta in modo efficiente e' anche vero che si puo' scrivere altro codice altrettanto elegante e compatto che invece fa esplodere il computer come nei film scifi anni 80.
- Quando si commettono errori non ci sono "runtime error angels" ma solo "undefined behavior daemons". Imparare il C++ per tentativi utilizzandolo e' un suicidio.
In generale credo che l'approccio "top down" proposto sia estremamente pericoloso perche' porta solo all'illusione di aver capito (illusione che in C++ si paga a caro prezzo).
L'astrazione high level del C++ fa acqua da tutte le parti (e' "leaky") ed e' secondo me comoda e potente solo se ne si comprendono i limiti e si capisce come e' costruita (ovvero se si arriva "dal basso" come comprensione).
Bellissima esposizione della storia del
C++!!!
Interessante sessione, avrei voluto vedere più storie reali.
Interessante come provocazione e come "esperimento didattico", mi ha sorpreso che si riesca ad arrivare così in là attenendosi alle "regole" mostrate nel talk.
Temo però che nel "mondo vero" la cosa non stia particolarmente in piedi, visto che le astrazioni C++ sono *estremamente* fragili, e nel momento in cui si rompono per memorizzare cosa non si deve fare è necessario spiegarne il perché, e lì ci si va inevitabilmente a sporcare le mani o con dettagli di basso livello, o con questioni storiche di standardizzazione del linguaggio che rompono definitivamente il "giardino dorato" costruito con le regole esposte nel talk.
Purtroppo temo che per "insegnare a capire" il C++ sia inevitabile tenere contemporaneamente presente i tre livelli - quello che è l'astrazione che si sta utilizzando ("cos'è un metodo di una classe" in astratto), i problemi implementativi di basso livello ("un metodo viene implementato come una funzione libera con un parametro this nascosto") e quello che dice esattamente il Sacro Standard ("chiamare un metodo su un puntatore null è sempre e comunque undefined behavior, anche se non accedi esplicitamente a campi della classe"); senza (1) non si può scrivere codice sensato, senza (2) non si può scrivere codice efficiente e risulta difficile capire e memorizzare il perché di tante scelte "strane" a livello di linguaggio, senza (3) si rischia di cadere nelle trappole dell'undefined behavior.
Infine, il talk prendeva come caso di studio l'insegnamento del C++ a persone nuove al mondo della programmazione, sostenendo che questa è una base per persone che di loro non sono interessate alla programmazione "in sé e per sé", ma che hanno bisogno di uno strumento che gli serve "farci cose" (caso tipico: ingegneri, scienziati, eccetera).
L'errore di fondo secondo me è sperare di trovare un subset del C++ per "semplici utenti" che possa essere lo strumento in questione. C++ non nasce per questo, sicuramente non si è evoluto in questa direzione e cercare di insegnarlo in questa maniera non ha molto significato - se devi insegnare a qualcuno un linguaggio in cui "fare cose" (possibilmente da subito), imparare provando e ottenendo feedback da compilatore e runtime (cosa non attuabile in C++ per via dell'undefined behavior) il C++ purtroppo è il linguaggio sbagliato.
L'unicità del C++ è il fornire astrazioni di livello molto alto (con tutti i distinguo del caso) ma con la possibilità di scendere di livello a piacimento quando serve, in tandem con la possibilità di interagire con codice C (API di sistema in primis, oltre a un parco sconfinato di librerie) in maniera diretta. Se ad una persona interessano queste nicchie il C++ "solo di altissimo livello" esposto nel talk non serve a niente - i puntatori e compagnia sono un must; al di fuori di questi e pochi altri casi, ci sono linguaggi molto più coerenti e approcciabili con meno lacrime e sangue da un programmatore inesperto con cui può applicarsi ai problemi che effettivamente vuole risolvere, senza per questo sacrificare le prestazioni o il "parco librerie".
Ottimo talk, anche se il C++ richiede molto "sangue", penso che un buon C++14 riesca effettivamente a ridurre complessità nell'insegnamento
Mi é piaciuto il punto di vista alternativo. A trovarli docenti come lui!
Il talk è stato interessante e le premesse sul fatto di essere "provocatorio" sono state più che mai utili. Per me che ho fatto (come tanti di noi) molta gavetta sul C, credo che questo punto di vista piuttosto dirompente possa essere uno spunto di riflessione forse non nell'immediato ma nel lungo periodo. Sono d'accordo sul fatto che sia difficile prescindere dal concetto di puntatore, ma credo che il messaggio fosse soprattutto di lanciare un warning nei confronti di metodi di insegnamento datati e forse obsoleti per le generazioni di sviluppatori future.