Italian C++ Conference 2016
14 May 2016 at Università degli Studi di Milano "Bicocca"

Il filo conduttore mi é piaciuto molto e se ne parla poco. É facile provare qualsiasi feature su progetti solitari, ben più complicate le dinamiche di squadra con skill diverse.
Un consiglio: Meno camminate sul palco!

Brillant talk, thanks for sharing your experience

Bellissimi gli esempi molto rivolti alle best practices ... quello che secondo me continua a mancare nel C++.
Ho molto apprezzato anche l'esposizione mai noisa o superficiale.

Ottimo talk, anche se il C++ richiede molto "sangue", penso che un buon C++14 riesca effettivamente a ridurre complessità nell'insegnamento

Le librerie presentate mi hanno senz'altro interessato - anche se soprattutto PPL, che era tangenziale al talk. Un po' superficiale l'esposizione, molto saltellante tra esempi di codice fatto senza spiegare in maniera compiuta il modo in cui stanno insieme i vari pezzi - anche se probabilmente l'obiettivo di un talk introduttivo come questo vuole più essere "fare fuochi d'artificio" mostrando esempi che spiegare per filo e per segno la struttura una libreria complessa e i principi dietro al suo design (cosa che personalmente avrei preferito di gran lunga).

Al di là della struttura del talk, sono rimasto a tratti perplesso sia sul codice (soprattutto sull'uso delle coroutine, abbondantemente lodate ma in genere "uccise" a colpi di co_await secchi sui task restituiti dalle funzioni dell'SDK, rendendo tutto esattamente equivalente a normale codice a sub-routine; e ho il preciso ricordo di codice portato ad esempio di conversione da stringa narrow a stringa wide fatto con un "widening ignorante", che dimentica che per passare da UTF-8 a UTF-16 non basta mettere gli stessi numeri in interi più larghi) che per quanto riguarda diverse giustificazioni date (non si può andare in listen su un socket "ovviamente" per "motivi di sicurezza"? il server HTTP su Windows pre-Vista non è disponibile perché non c'è HTTP.sys? Ma c'è comunque in bundle un webserver basato su Boost.ASIO...).

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".

This was great. I was impressed how affordable is the refactoring effort when you have right people and tools.

Un bel punto sulla pratica della programmazione di gruppo. Un discorso indipendente dal linguaggio ma il punto è molto sensibile per che lavora col c++ e un aspetto molto sottovalutato nella mia esperienza.

A wish I was good enough to grasp all from this talk but anyway it was inspiring. Well done.

Mi è piaciuta l'onestà dei relatori e la voglia di fornire più punti di vista sulle risposte. In definitiva dopo tutte quelle ore di evento si vedeva che erano un po' provati ma sarebbe strano il contrario!