Benvenuti su Gitbar, il podcast dedicato al mondo dei full stack developer, i mezzo artigiani, i mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.Bene, benvenuti in questo nuovo episodio di Gitbar.abbiamo un fantastico ospite con noi lo aspettavo da un po' ma finalmente ce l'abbiamo qua nel nostro bar comunque manda le ciance e vi ricordo rapidamente i contatti e partiamo.Info che ho c'è la github.it @brianrepo per scrivermi e il nostro gruppo telegram che ormai conoscete benissimo cui nome è github.it detto questo una piccola pausa e partiamo subito con l'episodio di oggi.Eccoci qua con me ho Luca Molteni vi dico solo che è un functional developer e quindi già a prescindere mi sta simpatico.No voi ormai sapete che sono in fissa per la programmazione funzionale pur non capendo niente e quindi chi meglio di lui può aiutarci e aiutarmi, quindi faccio uso del tutto personale del podcast in questo episodio, nell'esplorare questo mondo che è molto interessante e soprattutto ci propone un esercizio di sforzo mentale per uscire da quella che è la nostra zona di comfort.Ciao Luca come stai? Ciao Mauro, tutto bene grazie, grazie di avermi invitato al tuo podcast e scusami per il ritardo con cui siamo riusciti a registrare questa puntata a questo punto.Guarda non c'è nessun tipo di problema l'aspettavo con ansia.Hai presente come si aspetta la partita della domenica no? Con la sciarpa e con la tuta e allo stesso modo ti aspettavo.Luca ti faccio subito una domanda ma chi è Luca Molteni e cosa fa nella vita? Bella domanda, Luca Molteni è un poveretto, assolutamente un poveretto.Ma io sono un programmatore, oramai è 15 anni che faccio questo lavoro.Non fare il modesto però, ti prego.Io non è che faccio il modesto, io sono veramente un poveretto.Cioè oramai, pensaci, è 15 anni che faccio questo lavoro ma in fondo non so fare nient'altro nella vita.Pensa, siamo in due.Se ci toglieressero questo lavoro noi non sapremmo cosa fare, quindi siamo solo dei poveretti.No, io sono sono un appassionato di programmazione che è stato molto fortunato.Sono stato molto fortunato perché ho avuto un mentore che mi ha insegnato la programmazione e questo mentore incidentalmente era appassionato di programmazione funzionale e quindi mi ha potuto insegnare direttamente la programmazione, tutta la programmazione e ovviamente siamo finiti a parlare della programmazione funzionale.Io credo che in questo ambiente avere una persona che ti segua sia un qualcosa di importante.È una figura che ancora forse non è diffusissima e io sono stato veramente fortunato ad averla.Tu hai parlato di mentore, no? Dal tuo punto di vista qual è il ruolo del mentore nell'introdurre una persona non tanto a un linguaggio ma anche un paradigma, un modello di pensiero che è quello che appunto la programmazione funzionale? Guarda, il ruolo del mentor è importantissimo, secondo me soprattutto nel riconoscere ovviamente le potenzialità di una persona, ma soprattutto a superare tutta quella serie di pregiudizi che ci andiamo a creare su noi stessi, sul fatto che non ci meritiamo di poter fare i programmatori, magari la famosa sintoma dell'impostore, quella di cui si parla spesso in questo periodo, oppure il fatto che ad esempio c'è questo pregiudizio secondo il quale la programmazione funzionale sia solo per appunto matematici o solo per universitari, che è un pregiudizio fondato d'altra parte, ma la maggior parte dei pregiudizi deriva sempre da un qualche cosa di vero, giusto? Il pregiudizio di per sé non è vero, ma all'origine il fatto che comunque ASC, che comunque altri linguaggi di programmazione funzionale, vengano dall'accademia, ha generato un po' questo mito.In più c'è un discreto feticismo verso l'utilizzo di termini che vengono dalla matematica, o comunque dalla teoria delle categorie, che ovviamente questo non aiuta.E appunto nel mio caso specifico, avere un mentor che mi spiegasse, che mi raccontasse queste cose, come se fossero la cosa più normale del mondo, come se stessimo parlando di che cosa abbiamo mangiato ieri sera, ma invece si parlava di programmazione funzionale, di...perché no, diciamolo, di mona, di...anche concetti avanzati per me è stato molto importante, perché appunto nell'individualità si esprime anche un certo tipo di relazione che non puoi ottenere da università, non puoi ottenere da un corso su Corsera.Non è che per fare pubblicità alla mia azienda, però ad esempio io adesso lavoro in Red Hat ed è un'azienda grande, comunque un'azienda americana che ha tanti sedi e loro hanno internamente un programma di mentoring e si sta sviluppando questa cosa in tempi recenti ed è interessante secondo me.Perché noi partiamo un po' dal mito che il programmatore con i soli corsi online può imparare tutto, giusto? Vai su Corsera, ti fai il corso su Scala.Lo corso su Scala su Corsera è stato famosissimo.Era fatto da desk in persona, infatti.Andavi e lo facevi così.Però ovviamente c'è così tanto materiale, così tanti blog post, così tante conferenze, che è anche difficile capire esattamente da dove partire, da non partire.E poi metti caso che ti ritrovi in quel materiale in cui proprio non ti ci trovi perché è troppo difficile, proprio non capisci niente.Magari ti trovi un paper.Esempio, questa cosa succede spesso in ASCEL.Ti dicono "il modo migliore per capire argomento X è andarsi a leggere il paper originale".Sì, tu prendi il paper originale, lo leggi e non ci capisci niente.Per quello che prima ti dicevo che sono un poveretto, io non ho fatto informatica, ho fatto un sottocorso di informatica alla Statale di Milano e mi rendo conto che non ho necessariamente familiarità con un certo tipo di pubblicazioni scientifiche, soprattutto quelle che vengono dall'informatica.Però questo vuol dire che non si è riusciti a utilizzarne e utilizzare la programmazione funzionale con successo in produzione e anche a fare un minimo di divulgazione.Questo è il messaggio che mi piacerebbe portare, cioè anche se uno si sente che non è abbastanza bravo per fare un certo tipo di cose.Non è vero, sono tutti i pregiudizi mentali che andiamo a crearci.La programmazione funzionale è alla portata di tutti.Ha semplicemente un pregiudizio legato all'accademia che dobbiamo sapere che esiste e dobbiamo saperlo un po' gestire.Vero, assolutamente sì.Il side effect che dobbiamo mettere all'angolo quello.Poi ce lo racconterai.Questa infatti era una sorta di spoiler.No, quello che dici lo condivido al 100%.Anzi lo dicevo l'altro giorno che ero ospite in un altro podcast.Dicevo che il fatto di avere un mentor ti dà la possibilità di apprendere le cose al tuo ritmo, cosa che invece internet e i corsi online spesso non ti danno perché perché i corsi online hanno un primo un primo problema che è quello che hai detto cioè quello di orientarti nella giungla fitta delle risorse che trovi il problema di internet è che sta diventando sempre più vasto per fortuna di informazioni per orientarsi tra tutte queste informazioni diventa complesso e là entra in gioco il mentore che ti dice non perdere tempo con questo forse ti conviene puntare il focus su quest'altro e poi c'è il fatto che avere un mentore hai quella velocity col mentore tarata su te stesso nel senso che se io per capire adesso lo dico perché è una cosa che ho già detto un seno la funzione seno o la funzione coseno ho bisogno di un un omino che cammina sulla sinusoide, che rincorre la donna che cammina sul coseno, per capirlo ho bisogno di questo.Il mentore che ho davanti capisce quanto deve semplificare quel livello d'astrazione, quanto deve trasformare in un concetto concreto e te lo fa, ma lo fa in funzione di quello che sai tu, di quello che è il tuo modello d'apprendimento e secondo me è questo veramente il jolly da giocare.Ma dal tuo punto di vista ad oggi, oltre alla parte insomma del velo accademico che sta sulla programmazione funzionale che già incute questo timore reverenziale verso il mondo, quali sono gli elementi di complessità oggettivi, fisici del paradigma stesso di programmazione funzionale? Allora, personalmente, questa è la mia opinione, sono convinto che il problema principale nell'approccio alla programmazione funzionale è proprio il pregresso che abbiamo di programmazione procedurale.Io sono assolutamente convinto che se la programmazione funzionale fosse il primo paradigma di programmazione che viene insegnato a un neofita o comunque all'universitario, non avremmo veramente questo problema di approccio all'inizio, perlomeno non avremmo più problemi nell'approcciare la programmazione funzionale di quanti non abbiamo avuti a approcciare la programmazione procedurale.Purtroppo veniamo da un contesto storico in cui la programmazione procedurale, per motivi storici, è stata più importante rispetto alla programmazione funzionale.La programmazione funzionale, se è antecedente la programmazione procedurale, è stata ignorata per la larga parte del tempo del boom economico dei computer, semplicemente perché era troppo lenta.Esistevano le eSmart Machine, esistevano implementazioni di programmi di linguaggi funzionali, ma erano semplicemente troppo lenti e giustamente non avevamo la quantità di transistor per poterle usare in modo efficace.Adesso che ci possiamo permettere di sprecare cicli di clock...stavo per fare una battuta brutta, ma poi...La battuta è comunque utilizzare le web application oggigiorno.Io la vivo un po' come uno spreco di clock.Stiamo utilizzando dei computer veramente al minimo delle loro potenzialità, perché utilizzare questi processori potentissimi che abbiamo nei nostri telefoni, nelle nostre macchine, per utilizzare delle cose renderizzate sul server e mandarle in quello che è definito internet sostanzialmente un debug mode, perché tutto in chiaro, tutte cose così, secondo me è uno spreco assoluto di energia, proprio l'ettica, stiamo sprecando il mondo e questo ce ne renderemo conto.Infatti adesso oggigiorno si parla di green computing, cose di questo genere.Comunque oggi siamo proprio nella fase di spreco, i nostri tower hanno alimentatori da 300 watt, 600 watt, che utilizziamo per generare codici per inventarci delle valute.Cioè, siamo proprio in una situazione bruttissima di spreco.Comunque, in questa situazione di spreco non si può più dire che i linguaggi programmazioni funzionali sono lenti, che era la critica numero uno con cui non utilizzavano i linguaggi di programmazione funzionale tipo l'ISP, non so, negli anni '70, negli anni '80, quando si programmava tutto, sai, con linguaggi di basso livello tipo il C e così così.Vero, qui il paradigma funzionale porterà poi dei vantaggi che proprio in termini di performance che racconteremo poi.Per cui, da questo punto di vista tu dici noi possiamo approcciare alla programmazione funzionale se smettiamo di guardarla come il mostro o la cosa complessa e iniziamo a dire ok è il mostro la cosa complessa divide e timpera prendi il primo pezzettino prova a capirlo poi vado al pezzettino 2 e proverò a capirlo e mi piace tantissimo quello che hai detto no la programmazione funzionale se noi l'approcciassimo come primo paradigma sarebbe semplicissimo perché è legato veramente a alcuni concetti mi vengono in mente che ne so i tipi algebrici no? che sono alla base davvero della matematica più spicciola che impariamo alle elementari cioè somma e prodotto.Assolutamente Ma scorda che fare un passo prima, scusami se ti interrompo, senza entrare nel sistema di tipi.Ignoriamo un secondo il sistema di tipi, prendiamo una programmazione funzionale non tipata, proprio quella dell'ISP.Il concetto di funzione, per quanto venga dalla matematica, però come dici giustamente te, la funzione arriva abbastanza presto nel corso di studi, nel minimo esclusivo di matematica, il concetto di funzione è semplice, non facile, ma semplice.Non facile perché comunque richiede un certo sforzo da parte delle persone per capirlo, ma una volta che l'hai capito il concetto di funzione è quello.Ed è esattamente il concetto di funzione che otteniamo dalla matematica.Certi concetti che vengono dall'obietto-oriented programming invece, per fare un paragone, sono complessi, magari più facili.Cioè un po' questa ortogonalità tra semplice e complesso e facile e difficile.Quindi l'OP può sembrare più facile da approcciare all'inizio, ma ha un bagaglio culturale così importante, così complicato, che l'OP non è semplice, è complicata.Cercare di spiegare cos'è una classe di oggetti, stanze di oggetti, metodi che passano tra oggetti, pattern, tutte queste cose qua, è tanta roba.Quando invece dall'altro lato è una funzione, che è una funzione che una volta capita, cioè semplicemente la funzione, non c'è nient'altro, hai finito.Io mi son dato una spiegazione perché giustamente ho sbattuto la testa al muro i primi giorni quando provavo a capire e sono partito dal concetto di funzione cioè la funzione è qualcosa che gli entra un dato in ingresso e sputa uno o x dati in uscita, meglio uno.Però la programmazione oggetti invece è un oggetto che ha proprietà, metodi.Fermiamoci qua.ok quando noi guardiamo queste due cose la funzione ci viene spiegata e insegnata in quanto concetto astratto certo e invece quando veniamo introdotti siamo accompagnati nel mondo della programmazione oggetti la prima cosa che ti dicono e che mi han detto anche a me è ok la classe è la mia macchina, la macchina ha i sedili, la proprietà sedile e il metodo accelera.Adesso sto banalizzando.Però c'è subito la relazione all'elemento concreto che butta sul cestino quel livello di astrazione ed è un po' come l'omino che dicevo prima che cammina sulla sinusoide, cioè è una salita e una discesa invece la funzione e tutti i concetti che ne vengono dopo della programmazione funzionale perché fino alla funzione diciamo che ci possiamo arrivare però quando entri nel mondo delle monadi o delle operazioni algebriche sui tipi beh a quel punto dici "ah che roba è" perché non hai un modello mentale.Io vivo di metafore.I ragazzi e le ragazze del podcast lo sanno.E se non esiste una rappresentazione concreta per me è un problema andarlo a capire la cosa.Però niente, semplicemente per me la difficoltà vera che sta alla base del concetto di programmazione funzionale tolto il velo accademico è proprio questo.Nella tua esperienza come si può affrontare questo livello d'astrazione? Questa è proprio una bella domanda, quello che dici te ha assolutamente senso.L'insegnamento tradizionale di OP, quello che ho ricevuto anch'io, passa da appunto l'utilizzo di metafore del mondo reale e quello è vero.Il problema di questa cosa sono due.Il primo è che non sono sicuro che nell'idea originale di OP ci fosse questo proprio, questa idea del mondo reale.Noi facciamo l'esempio della macchina, Lan Kay faceva l'esempio delle cellule, mi sembra che si scambiavano messaggi.Si è perso un po' il concetto iniziale di OP, presto OP è diventato quello di C++ e Java e C# e così così.OP è originariamente nato con Smalltalk, OP è nato senza tipi banalmente, erano proprio queste entità che si scambiavano oggetti senza tipi e poi quando tu vai a chiedere a un laureato, non è colpa sua ovviamente, quello che gli insegnano che cos'è OP, lui ti dice "OP è è quel paradigma basato sui concetti di incapsulamento, ereditarietà e polimorfismo.Cosa che è una definizione accademica ma che non ha nessun senso e anche storicamente è anche errata.Perché Alan Kay quando ha creato Small Talk non aveva né in mente Java, non aveva né in mente C++.Queste sono parole testuali sue.Quindi proprio l'esempio di OP che hai definito te, quello dei tipi, non era neanche nell'idea iniziale di OP.E se ci pensi, se c'è già una dissonanza così alla base, come si può ottenere qualcosa di buono? Io ultimamente, negli ultimi anni, sto parlando male di OP e mi dispiace un po' perché appunto si suona sempre un po' alitari quando si parla male di una tecnologia, pure tra l'altro è una tecnologia che ci sfa, ma io lavoro in Java tutti i giorni, quindi è anche ingiusto nei confronti di OP.D'altra parte, un tentativo di cercare di capire, insomma, le basi di OP sono difficili.Secondo me è emblematico che dopo anni decenni che utilizziamo OP ancora non ne capiamo le basi e di questo ne ho parlato, mi spiace per lo shameless plug, ma ne ho parlato in un altro talk dove parlavo di vari tipi di polimorfismo.Tra l'altro ti interrompo un attimo, mi mandi il link così lo mettiamo nelle note dell'episodio se sei pubblico, se c'è un video, se qualcosa.Fortunatamente io non ho fatto tanti video online quindi puoi pure mettere tutti.Volentieri.Adesso sono tipo tra quattro.Vi ho parlato in un altro in cui appunto ho parlato dei vari tipi di polimorfismo, in cui è una cosa che un po' mi ha ossessionato negli ultimi anni, che è appunto dire che il polimorfismo fa parte dei principi basi di OP è anche errato, visto che anche altri sistemi che non sono OP hanno il concetto di polimorfismo, anche se è un concetto diverso.Quindi appunto questa idea di che hai citato te, quella della macchina, di oggetto di origine dei programmi, si scontra un po' con la realtà di utilizzare il linguaggio di programmazione durante il giorno, perché l'esempio della macchina o del triangolo, l'altro esempio classico, il triangolo o quadrato, quando fanno vedere i limiti di OP, non c'entra niente con la programmazione originale del lavoro, scusate, con la programmazione moderna al lavoro.Quando tu vai al lavoro non devi modellare una macchina, non devi modellare una figura, un quadrato, un rettangolo, devi definire, devi modellare un'interazione con un database.E come la modelli, nella definizione di database? Ti fai tutto un film sul quale tu hai degli oggetti concreti e degli oggetti concreti li devi mappare le tabelle di un database, per fare un esempio.Ma ti rendi conto che c'è proprio un errore, un errore di impedenza tra le due cose, perché oggetti e tabelle hanno un ciclo di vita totalmente diverso.E tutto lo sforzo mentale che fai, perché ti hanno insegnato OP, magari all'università, o magari per il conto tuo, perché tu sai che ci devono essere questi oggetti che interagiscono tra di loro nel cercare di mappare le tabelle del database su degli oggetti è sforzo sprecato perché sono due cose diverse, sono due concetti diversi.È come fare una metafora, una similitudine e cercare di trovare tutte le somiglianze per cercare di far quadrare la tua metafora e la tua similitudine.E' energie sprecate.Scusami Mauro, lo so che tu hai detto che tu vivi di metafore, quindi non volevo...No, no, no, no, no, assolutamente.Anzi mi stai accompagnando a una domanda che volevo farti.Io ho già fatto, stavo cercando se lo trovo un libro giusto per contestualizzare ed è il libro di Domain Driven Design di Vernot.E tu hai accompagnato la discussione in questo mondo, nel senso che dici noi abbiamo delle macchine che ragionano in un certo modo con alcuni costrutti e con la programmazione a oggetti portiamo questi costrutti modellandoli in una simile realtà in un modello che rappresenti la realtà.Tutto questo sforzo che serve per semplificare fondamentalmente il nostro lavoro di sviluppatori nel comprendere il modello che stiamo andando a disegnare è un sacco di energia sprecata se solo ci dotassimo di un minimo di capacità di astrazione potremmo usare degli altri strumenti dimmi se sto capendo bene la tua posizione potremmo usare degli altri strumenti che ci permettono di essere più efficienti e anche più efficaci probabilmente.Mi chiedo allora siccome io ho amato il domain driven design ma proprio alla follia nel senso che mia moglie c'era quasi gelosa, mi chiedo quello che il giorno 2 che ho approcciato alla programmazione funzionale mi son chiesto è ok io sto modellando questo livello d'astrazione però la realtà non è come la disegniamo e come la vediamo ma la realtà, corregimi se sbaglio, vive di processi, cioè di evoluzioni di cose che vanno da A a B e a quel punto, cioè di cose che succedono no? e tu… Io l'ho chiamato funzioni, non processi.Processi secondo me sono un po' come un dettaglio implementativo di una CPU.Processo, di un'A.Vero, vero.Io ragionavo più in otica aziendale, non un processo.Ah, processo aziendale.Cioè qualcosa che porta da uno stato A a uno stato B.Ok? Da una condizione A a una condizione B.Quindi essendo la nostra realtà, dei software che stiamo sviluppando, non la realtà che viviamo perché i software non sono la realtà che viviamo, i software sono degli strumenti.Correggimi se sbaglio.Questo è il ragionamento.Quindi dico ha senso sviluppare questo software? Io la mia risposta ce l'ho ed è sì io posso modellare la realtà a processi tanto che sto leggendo un bellissimo libro di programmazione e di domain driven design in ambito funzionale credo sia fantastico quel libro e utilizza i tipi e le funzioni per rappresentare il dominio e mi piace.Come si chiama il libro? C'è lo nel Kindle.C'è un bellissimo...Ci scriviamo dopo? No, ma lo mettiamo...Se tu cerchi "ddd function" gli esempi di codice sono in F# perché tra l'altro secondo me è la functional programming e domain driven design.Interessante comunque sì sì.Ed è molto interessante perché intanto perché tu approccia quel mondo che è il mondo del che tendevi a modellare col domain driven design però lo fai con un approccio differente quindi quel problema di ingresso nell'ecosistema domain driven design, quindi nel tuo modellino di classi e di proprietà e di metodi, che ha un problema in ingresso, che è quello che dicevi, i dati miei stanno sulla database, in quel caso è pensato in termini di processi e quindi tutto più più fluido, tutto più più più più collegato, non mi viene difficile spiegare.Assolutamente ha senso quello che dici, due cose secondo me avevano detto.La prima è, stanno cercando di stare un po' sul pezzo, una volta che vedi le librerie di accesso al database di Haskell o di Scala o di FHark, ti rendi conto di quanto siano semplici rispetto a un ORM classico, per non citare il più grande classico ORM diffuso che è Hibernate in Java.Sono incredibilmente semplici.Attenzioni, non facili, ma semplici, nel senso che c'è poco, poco codice, pochi concetti, poche metafore e quello è indubbio, evidente.Spiegare il ciclo di vita degli oggetti in Hibernate a una persona, quando lo utilizzavo tanto, mi ci voleva qualche giorno.E' un concetto complicato.Il secondo, scusami, prima pensavo a processi, pensavo al processo di ACP, invece tu intendevi processi aziendali.Incidentalmente io adesso in Red Hat mi occupo proprio di Process Automation, che è l'automazione dei processi, e ti dico che gli strumenti che noi forniamo a livello process automation che sono sostanzialmente DRLS, il rule engine, DMN che è il decision model notation e JVPM che è un rule flow engine.Nessuno di questi tre è basato su dei concetti che vengono dalla programmazione orientata agli oggetti.Tutti i sistemi, generalmente DMN è stateless, è senza stato, è proprio un concetto che viene proprio dalla programmazione funzionale.Anche ed Rules, il rule engine su cui lavoro io, ha un linguaggio di programmazione che è dichiarativo, abbiamo parlato recentemente proprio con la mia azienda, dichiarativo è proprio quasi un mondo diverso rispetto alla programmazione procedurale e ti fa pensare appunto perché i processi aziendali che si mappino meglio su dei concetti che non che non vengono dalla OP.Mi dispiace che stai inventando un po' un dissing della OP o un parlare male della OP.No, no, no, no, No assolutamente, tra l'altro mi dà da mangiare quindi come dà da mangiare a te, per cui assolutamente e tra l'altro è molto vicina al mio modo di pensare, vivo per metafore, quindi la OP è perfetta.Però io sono assolutamente convinto che in un paio di generazioni, qui qui lo dico come la citazione famosa di quello che diceva "i computer non avranno più di due megabyte di ram", cosa che diceva quella gente, io sono convinto che probabilmente nel futuro, nel nostro futuro non ci sarà OP.Mi dispiace ma mi dispiace per il valore storico che ha avuto ma sono quasi convinto che non ci sarà.Qualcuno ascolterà questa cosa tra 60 anni e dirà "ah, hai visto che cazzata?" Io non lo so se può essere un contributo interessante oppure un elemento in modalità cazzeggio però esiste un canarino che è quello che si porta in miniera, no? Per vedere se muore di questa adozione di massa della programmazione funzionale e lo vedo nei functional components di React.React è uno dei framework più adottato a livello massivo.Quando noi usiamo gli effect dentro un functional component di React per modellare tutto quello che è il side effect che tra un po' vediamo il concetto di side effect che tra un po' vediamo e usiamo le funzioni per creare un componente che in realtà è qualcosa che mentalmente abbiamo come concetto fisico e non di portare un elemento dallo stato A allo stato B ma proprio come elemento entità a sé stante, beh questo può essere un canarino in miniera che dici se muore, se schiatta oppure se sopravvive.Quindi è un indicatore no? Sì, però oramai la programmazione funzionale ovunque come dici giustamente te anche in React, in realtà ha appascato tantissimo la programmazione funzionale, oramai è sul front-end, è sul back-end, non possiamo più ignorarla e non possiamo più ignorarla perché ci chiedono di invece andare nel concreto la funzione, per quanto il concetto di funzione per quanto sia appunto difficile da capire e approcciare è molto semplice e compone molto bene.Compone in modo preciso, sta lì un po' l'idea della programmazione funzionale, l'idea della composizione di funzioni che è definita in modo matematico, però voglio dire si possono anche utilizzare dei metodi più pragmatici per spiegarlo.Ho visto la gente spiegare la composizione di funzioni con il Lego, quindi potrei spiegarlo anche mio figlio di tre anni volendo.Una volta che si capisce l'idea di composizione e funzione ti rendi conto di quanto semplice sia questo concetto su cui ci puoi costruire delle cose giganti, cosa che invece la composizione in Object Oriented Programming non è così banale come sembra.Quindi da un lato è il lato di modellazione dei dati, che qui sembra scontato, ma poi quando questi dati devono interagire tra di loro non è per niente scontato e quindi è brutto da dire, ma le funzioni si compongono praticamente solo in un modo e in Haskell questa cosa è proprio emblematica.Se proviamo a parlare un po' di Haskell, è un type system forte, è strongly typed.Il type system di Haskell è molto diverso dai type system cui siamo abituati oggigiorno, è anche proprio una sintassi diversa.Anche questa cosa che le definizioni di tipi delle funzioni sono definite su un'altra riga rispetto all'implementazione.È aliena, giusto? Se uno viene dalla programmazione procedurale, qui ci ricolleghiamo con il discorso di prima, il problema è il predilizio.Noi abbiamo imparato a programmare con C o con Java, quindi siamo abituati ad avere i tipi in line.Avere già i tipi su un'altra riga è una cosa che se uno parte da zero non gliene fiega niente.Se invece uno ha un bagaglio di 10-20 anni a usare i tipi in un modo, comunque è un tipo alieno, ma questi questi tipi rappresentano proprio l'unico modo con cui puoi comporre queste funzioni ed è proprio il meccanismo con cui si modellano i programmi in Haskell, proprio si utilizza il compilatore proprio in modo molto forte e c'è questo stereotipo, anche questo si è uno stereotipo in Haskell, che si dice che quando il programma compila allora fa quello che vuoi.Ok? E' una una cosa molto forte perché all'inizio se uno non compila, ma per come hai fatto Askel, per questa cosa dei side effects così, della purezza di cui magari parliamo un po' dopo, in effetti una volta che hai compilato tutto il tuo programma è l'unica soluzione che hai, deve funzionare di sicuro, non c'è proprio niente, nessun dettaglio che ti sta nascondendo, non c'è il concetto di puntatore, area di memoria, virtual table, cose di questo tipo, tutte cose che sono dei dettagli che ci portiamo dietro alla storia, non c'è.Ci sono solo le tue funzioni che sono composte nell'unico modo in cui si possono compore.E ti dirò di più.C'è un bellissimo libro che ho citato in un talk, che è un libro rosso, si chiama "Functional Programming in Scala".Qui Scala è un dettaglio, ce l'hai grande.Quello è proprio di Rounar.E c'è l'altro, non mi ricordo come si chiama.Scusate, dopo mettiamo dei link.Vabbè, comunque, è un linguaggio di...c'è scritto in Scala, Quello è un libro su Functional Programming, Scala è solo il modulo in cui ti mostrano gli esempi.E proprio all'inizio lui ti fa questo esempio di una funzione da cui, definito il tipo della funzione, c'è una sola implementazione valida.E questo è incredibile se ci pensi, perché una volta che siamo sicuri che c'è una sola implementazione valida, possiamo rilassarci.Anche questo l'ha detto un altro talk.La programmazione funzionale è rilassante, perché non ci sono cose nascoste, non ci sono interazioni strane.Tutto quello che vedi è tutto quello che c'è.Il funzionamento sarà sempre uguale.C'è questa idea del determinismo, no? L'idea che è dato uno stesso input otterrai sempre lo stesso output.Questa cosa ci dovrebbe fare dormire di notte.E' per noi importante.Insomma, dormire bene è importante."Riceverete proprio questo materasso.Non un materasso arrotolato, sottovuoto, senza sostegno ma il vero materasso ortopedico.Assolutamente quindi il concetto di funzione è fondamentalmente quello che hai detto tu quindi qualcosa che dato un input noto di tipo noto ci risponde un output che già prevediamo che sia di quel tipo cioè se io il distributore di benzina se io metto 10 euro, sono sicuro che usciranno 10 euro di carburante, ok? Perché mi aspetto che escano 10 euro di carburante.Tu prima hai detto che le funzioni in realtà, dato un ingresso, ti devono dare sempre un'uscita.Sono tutti esempi calzanti.Allora diciamo che nel mondo delle idee la nostra teoria è che se tu dai dei soldi ottieni qualche cose.Quindi se io dovesse definire la mia funzione più semplice che c'è, è una funzione che prende come parametro in input i soldi e mi restituisce un oggetto.Il mondo reale non è fatto così, il mondo reale ha tutta una serie di interazioni che non vengono dalla...che non vengono, non sono così semplici da modellare.Tipo banalmente i soldi potrebbero non essere spropicciati e la macchinetta non me li prende, la coca cola potrebbe essere finita, qualcuno potrebbe aver sbagliato...no, questo non è un gran esempio.Oppure, non so, la macchinetta si potrebbe staccare, andrebbe via la corrente mentre cerca di ottenere la cosa, oppure si inceppa il meccanismo.Tutti questi sono side effects e ci sono nel mondo reale, ma non rendono il nostro principio meno vero di quello che serve.Se un tuo business model è fare soldi con le macchinette, gli utenti otterranno, metteranno dei soldi e otterrai un risultato.Non so se mi segui.Qui abbiamo proprio due lati della vicenda.Abbiamo da un lato la funzione pura che rappresenta il nostro business model, le nostre regole di business, citando anche un concetto della process automation.D'altro canto hai i side effect.Storicamente ci siamo concentrati di più su side effect, quindi abbiamo programmato con la programmazione procedurale in C come se fosse tutto un gigantesco side effect, come se tu dovessi definire un numero e ti dovresti già preoccupare di quel numero dove lo dovrei mettere.E allora quando dovrei avere un numero dovevi pensare che dovevi metterlo nell'area di memoria.O se ho una lista di numeri ti dovrei preoccupare ad esempio di quanta memoria allocare per questa lista di numeri.Perché in C è così, se utilizzi un array in C devi dire quanto è grande un array.Oppure se devi utilizzare una lista ti devi preoccupare di come fare la lista, devi capire i puntatori.Questi sono tutti dettagli implementativi, ma la verità è che una macchinetta metti i soldi ottieni i risultati.Quando devi modellare i side effect, lì la questione diventa molto interessante, perché Haskell l'ha approcciato in un modo, tutti gli altri linguaggi di programmazione funzionale che abbiamo citato prima come F#, come Lisp o come Scala ad esempio, l'hanno approcciato in un altro modo.Non c'è un modo migliore degli altri, sono semplicemente modi diversi però ci sono delle idee diverse chissà in futuro quale utilizzeremo.Quindi ricapitolando fondamentalmente la nostra macchinetta prende in ingresso i soldi e sputa la bibita adesso potrebbero succedere delle cose queste cose che per esempio la stampa dello scontrino piuttosto che la corrente che manca che esulano da quello che teoricamente il processo standard della mia macchina ma che interagiscono col mondo esterno ok vengono definite side effect quindi effetti collaterali dell'acquisto della mia bibita.Esatto.E questo è chiaro.Poi hai introdotto il concetto di funzione pura.Esatto.E' proprio qui il discorso.L'idea di funzione pura è un'idea di di una funzione che dato lo stesso input ci restituisce sempre lo stesso output.Che appunto è molto facile da...scusate non è facile, è semplice da capire nel caso in cui stiamo ragionando con la matematica, i classici esempi tipo 2+2=4, però giustamente la gente mi dice "la programmazione non è 2+2=4, la programmazione interagisce con il database, chiama il web service oppure anche manda la lattina di coca cola, perché alla anche queste macchinette vengono programmate.Nella funzione pura non c'è proprio questa idea del side effect, o perlomeno modellare l'idea del side effect ha più a che fare con l'insistema di tipi che col concetto di funzione.Diciamo che nella funzione non c'è.Vari programmi di linguaggio e programmazione funzionale pura hanno utilizzato vari metodi.Comunque una metafora intuitiva, visto che tu vivi di metafore, scusami.Sì, io vivo solo di quello.Che però è abbastanza facile da capire, è quella da cui si parte da una funzione pura dove il suo input è il mondo e l'output è il mondo.È arrivato la rovina.Ok, questa metafora ci fa intuire come si può iniziare a modellare una serie di interazioni con il mondo reale con un linguaggio di programmazione funzionale puro.È vero che ci sono varie condizioni, ma è vero che se noi mettessimo il mondo nella condizione in cui era quando l'abbiamo dato come input, probabilmente ci sarebbe lo stesso mondo nella condizione in cui l'abbiamo dato come output.Noi siamo abituati a pensare al mondo mutabile, giustamente.Se io prendo la borraccia che ho qua e la sposto qua, sto effettivamente spostando una cosa.Però con un minimo di sforzo mentale possiamo pensare che quando ho risposto la borraccia avanti la borraccia che è qua, stiamo creando un nuovo mondo in cui la borraccia è in un'altra posizione e questo proprio nuovo mondo è così anche nel passare del tempo se ci pensiamo.Potremmo pensare che la cosa stiamo spostando ma la realtà è che il tempo è passato noi mentre dicevo questa frase e quindi è già un nuovo mondo, è un mondo con cinque secondi in più.questo è un po' troppo filosofeggiante, però è interessante.No, sì, è giusto il concetto ed è una delle complessità che si vedono quando si approccia, o che io ho avuto quando si approccia la programmazione funzionale, è quello di lavorare con degli stati mutabili perché dico "ma caspita, di per sé il programma che sto facendo serve per alterare dei dati, far evolvere dei dati, ma se io non li faccio mutabili o dei dati nuovi cosa farò? In realtà invece proprio l'usare questo approccio quindi l'utilizzo dei dati mutabili ci dà intanto una gestione migliore del processo che stiamo andando a creare perché per esempio mettiamo all'angolo tutta una serie di problemi che potremmo avere con la modifica del dato, dello stato che altrimenti essendo mutabile non renderebbe la nostra funzione predicibile.Quindi io non posso prevedere cosa mi aspetto come risultato dalla funzione.Esatto, allora ad Orebicronaca ti devo dire che hai utilizzato il termine "migliore" che è un termine un po' rischioso in questi discorsi perché giustamente "migliore" è soggettivo e opinabile.Scusami se te lo devo dire perché poi ci rischi di dire "ah, Luca Voltini, Mauro Murrico, vanno in giro a dire che la Provenza di Funzionale è migliore".Io non la conosco bene, quindi tutto quello che dico potrebbe essere una fesseria.Allora, migliore dal punto, se fissiamo un punto fermo, che è quello del determinismo.È più deterministico, quindi è migliore nel senso che è deterministico.Banalmente non è migliore a livello, caso tipico che fanno, non è migliore a livello di allocazione di memoria.Perché ovviamente se io per definire una cosa prendo tutto il mondo e ci cambio solo lo stato della borraccia e tutto il mondo occupa 2 terabyte, pensa che bello se il mondo occupasse 2 terabyte, potremmo prendere e modificare così, ridarti un altro mondo di 2 terabyte solo per avere un bit spostato fa un po' ridere, no? E ci ricolleghiamo al discorso di prestazioni di prima.Quindi questa cosa non è necessariamente migliore da tutti i punti di vista, è semplicemente più deterministica.Però sì, il modello programmazione funzionale pura utilizza questi ragionamenti di immutabilità, di determinismo, per dare un certo tipo di comportamento.Adesso scusami ma già che stiamo filosofeggiando, fammi ritornare un secondo sull'idea del tempo, perché anche questo è importante.Nella programmazione procedurale noi siamo abituati, quando leggiamo un listato in un codice sorgente, a ragionare a livello temporale, anche se è implicito, perché in un linguaggio procedurale le istruzioni vengono eseguite in ordine.Quindi se c'è un'istruzione dopo un'istruzione precedente, noi siamo abbastanza sicuri che l'istruzione dopo sarà eseguita dopo, dopo proprio fisicamente, proprio dal clock della CPU che gira, l'istruzione dopo sarà eseguita dopo con la prima.Una cosa fin tanto che scontata.In un linguaggio funzionale puro come Haskell, l'ordine con cui vengono scritte le cose non citta assolutamente niente con l'ordine con cui vengono evalutate, vengono valutati.E valutato è un neologismo bruttissimo.E il tempo anche se ci pensi anche nell'istato di Haskell i programmi in Java storicamente si scrivono dall'alto verso il basso e i programmi in Haskell si scrivono da sinistra verso destra.Si, ma in Blue Wind esatto.Potrei metterci un nemoji per rappresentare la mia faccia adesso.No ho capito quello che vuoi dire spero di non aver confuso troppo con...Ma questo è il bello è confondere le persone no? Fatti Allora, sembra che stiamo andando un po' per la tangente, stiamo filosofeggiando, parlando del mondo, del tempo, delle cose reali.C'è poca attinenza col mondo reale.È una cosa diversa rispetto alla programmazione.La programmazione procedurale è storica, ha a che fare con la CPU, la memoria e cose così.La programmazione funzionale non c'entra veramente niente.Questo è proprio il messaggio che vogliamo fare arrivare, cioè io vorrei fare arrivare alle persone.Non c'entra niente.È proprio un'altra cosa.Per molti questo è bello perché è un nuovo inizio, si riparte da zero così.Io capisco che le persone che invece vogliono avere una certa continuità con quello che vogliono, con quello che stanno già usando, non è necessariamente l'approccio ideale per loro.Quindi io consiglio sempre di studiare Haskell perché è un po' il linguaggio più emblematico, è quello che ha tutti questi concetti e non ha nessun compromesso, diciamoci la verità.Prende questi concetti partito Fresh Start e ha utilizzato questo e incontri solo concetti nuovi.Ma per imparare la programmazione funzionale uno non è obbligato ad utilizzare ASCRE.Se uno vuole continuità, secondo me, non dovrebbe neanche utilizzarlo ASCRE.Ci sono una serie di altri linguaggi che sono più docili da questo punto di vista e ci si arriva con più tranquillità alla programmazione funzionale, tipo passare da JavaScript, tipo passare da Java, così, e si introducono i vari concetti di programmazione funzionale, quindi le funzioni, le funzioni di di ordine superiore e altre varie concetti.Che non puoi citare, si vede ti stai sforzando.No no no, e poi piano piano si introducono.Che poi è il mio percorso.Io il percorso che sto facendo in realtà parte da javascript.Ieri per esempio mi sono scritto la mia funzione compose è la mia pipe e sono fierissimo ho anche fatto la mia funzioncina carry per il carrying poi andremo a vedere cosa è rapidamente visto che il tempo corre ma giusto.C'è così tanta cosa da dire.Sì davvero ce n'è tantissimo e a quel punto arrivi a un certo punto e dici bene ok javascript fighissimo forse ho bisogno di un type system non lo so però mi sono fatto la ho giocato col concetto di funtore che poi questa cosa complessa non è nel senso che prendi la tua roba il tuo dato in ingresso lo metti dentro una scatoletta che potrebbe essere anche vuota fai entrare la scatoletta nella funzione ti aspetta una scatoletta in uscita.Che dire La metafora del mondo reale applicate a questo tipo di concetti può essere utile nell'imparare questi concetti.Abbiamo citato prima il concetto di Mona, i vari esempi che derivano da… che utilizzano anche quello le scatole, ho visto i robottini, cos'è burrito, c'è di tutto online.Sì, però sai cos'è Luca, quello che penso io la metafora aiuta a non spaventare una volta che hai utilizzato la metafora per capire la composizione quindi il tubo d'acqua per rappresentare la pipe e dentro quell'acqua ci sono dei filtri delle grie quello che ti pare una volta che non ti spaventa quel concetto Allora vai e ti scrivi la tua funzione che ti fa la Function Composition.E' arrivato la rotina.I type systems sono un discorso un po' controverso diciamo.Io quando ho iniziato a lavorare io si parlava proprio di linguaggi dinamici tanto.Ma si parlava tanto proprio come una cosa nuova.Si parlava di linguaggi di programmazione senza il type system come se fossero il futuro.Poi piano piano si è andato in un'altra direzione, quindi quando ho iniziato a lavorare io, era 2007, utilizzare Python voleva dire utilizzare in qualche cosa di nuovo, fresco, moderno, così.Il problema è che in un linguaggio di programmazione funzionale, dove la composizione è tutto, non avere i tipi, secondo me, non ti aiuta a capire quello che sta succedendo.Perché, appunto, abbiamo detto, sono concetti semplici ma difficili da capire.Quindi c'è poche cose, però ci vuole un discreto sforzo.E per avere questo discreto sforzo un sistema di tipi che ti descrive esattamente quello che sta succedendo ti aiuta a ragionare.Se non ce l'hai lo devi tenere in memoria.E quindi tenere in memoria è faticoso.E quindi siccome le nostre risorse sono limitate non vogliamo necessariamente fare la cosa più difficile che c'è.Noi vogliamo fare la cosa più semplice che c'è, giusto? Il problema secondo me è sempre il punto d'accesso, cioè l'approccio alla complessità, all'astrazione, che è là lo snodo, una volta che si supera quel passaggio...In certa parte è il nostro lavoro creare astrazioni così.Comunque dove volevo arrivare col sistema di tipi è comunque successo di linguaggi anche sul front end come TypeScript dimostrano che in effetti il sistema di tipi in dieci anni hanno cambiato faccia.Magari il sistema di tipi di Java e C++ non piaceva particolarmente perché i programmatori non lo trovavano particolarmente utile, ma una volta che si inizia a ragionare con funzioni, fruttori, monoidi o tutte quelle cose che si vengono a programmazione di funzioni che fanno un po' paura perché hanno dei nomi un po' strani, farlo senza il sistema di tipi è semplicemente sconveniente.Una cosa molto interessante è che probabilmente il sistema di tipi, io lo vedo da da TypeScript sta entrando anche nel diciamo nella nella sta diventando abbastanza utilizzato da tutti i programmatori a tutti i livelli sì ecco la cosa interessante è che tutto sommato TypeScript ha un buon sistema di tipi non è eccezionale però per essere cioè per sapere che c'hai javascript sotto il sederino dici "wow è fighissimo" e questo sistema di tipi oltre che a darti quella quella quella quella a sapere cosa sta succedendo fondamentalmente, ti previene tutto un lavoro di type checking che faresti in fase di testing? Sì assolutamente sì, infatti è molto importante, sono strumenti, sono tutti strumenti che dovremmo utilizzare, probabilmente il pregiudizio verso i sistemi di tipi che è stato generato negli ultimi anni, negli anni appunto storici, quando se ne parlava male, derivava dal fatto che i tool non erano così convenienti.Ad esempio in Haskell, che abbiamo citato prima, qui i tool non è che brillino proprio per bellezza, però il sistema di tipi può essere omesso e questo non rende Haskell un sistema, un linguaggio di programmazione non tipato, lo rende comunque tipato, però anche senza scrivere una riga di tipo, a meno di casi eccezionali.E questo se ci pensi è incredibile, perché unisce il meglio dei due mondi, cioè il fatto che il compilatore ti verificherà subito se il tuo programma è scritto senza doverlo girare o senza dover scrivere dei test espliciti per testarlo, ma allo stesso tempo tu da programmatore non devi scrivere neanche una riga di tipo.E questo comunque si può fare solamente perché il sistema di tipi di Haskell è un sistema di tipi diverso, sì ma è forte, ma non è lo stesso sistema di tipi dell'oggetto oriente del programma in classico.Il sistema di tipi di Haskell è unico, si chiama...oddio, spero di dire quello giusto...mi sembra che si chiama Hitman Miller, prende nome dai due che l'hanno inventato.Ed è anche qui, è totalmente diverso da quello di Object-Oriented Programming.In Object-Oriented Programming c'è questa idea alla base che è molto forte nei sistemi di tipi di Java e C#, c'è questa idea del tipo che viene dall'esterno.Quindi immagina di programmare su delle interfacce, storicamente C++ in Java si chiama interfacce.Programmare sulle interfacce vuol dire che quando scrivo il programma e non interessa l'implementazione concreta dell'oggetto, mi interessa semplicemente che quell'oggetto soddisfi con l'interfaccia.Che vuol dire? Che questo tipo può venire dall'esterno e questo tipo può non esistere.Ok? Può non esistere quando io scrivo il programma per arrivare all'esterno.E' molto forte, è molto potente questo sistema quando devi scrivere dei plug-in ad esempio.Tu sai che scrivi una serie di interfacce e poi te lo do a te e tu, senza dover ricompilare la cosa, perché da qui il fulcro della vicenda è questa.Storicamente l'hanno inventato in Java per poter aumentare il comportamento dei nostri programmi senza dover ricompilare, perché al tempo di ricompilare ci vuole un sacco di tempo.Io me lo ricordo, prima delle SSD con le CPU poco potenti, compilare ci voleva proprio tanto tempo.La scala ci vuole ancora oggi.Ah sì, la scala ci vuole ancora.E comunque l'idea è quella, tu mi davi un jar, un pacchettino dall'esterno.Questo pacchettino definiva dei nuovi tipi, ma io sapevo che questi nuovi tipi soddisfavano le mie interfacce e quindi tutto funzionava, tutto componeva.In Haskell questo non è possibile.Haskell, nel momento della compilazione, deve sapere ogni tipo che esiste.Una volta che ha questa assunzione, poi qui c'è un asterisco perché poi si possono simulare questo comportamento anche in Haskell, però non si fa.Tendenzialmente nell'Haskell base non si fa.Quindi quando tu a compile time sei già tutte le varie definizioni dei tuoi tipi, tutti i tuoi vari i sottotipi, le declinazioni, chiamiamole un po' come si vuole, il sistema di inferenza dei tipi che hai citato prima, type inference in inglese, può fare delle assunzioni molto forti.Sa già tutti i comportamenti, tutti i branch in cui vuole ottenere la cosa, perché non può mai arrivare qualcuno all'esterno a dire "ah, non hai considerato questo tipo", giusto? E quindi facendolo così è più riduttivo, ma è più forte, ha un controllo molto maggiore.Capire questo vuol dire che ti puoi permettere ad esempio di...lui può indovinare tutti i tipi senza dover nemmeno specificare neanche uno.Che però è un bel vantaggio, diciamocelo.Forse nel 2020 è un vantaggio più grande di avere invece il vantaggio storico dei vari programmi che permettevano di prendere un pacchettino dall'esterno e aggiungerlo e aumentare la funzionalità.Anche perché è cambiato un po' il contesto.Esatto.La compilazione è diventata più veloce.Prima non si ricompilava ogni volta.Ad esempio prima in Java, nell'ecosistema Java, c'era questa idea degli application server, questi baracconi che giravano in memoria, in cui tu andavi e fornivi una nuova implementazione, loro continuavano a girare in memoria, toglievano la vecchia implementazione e la mettevano a nuova.Adesso non si fa più così, nel mondo del hybrid cloud, tra l'altro del serverless, si fanno delle compilazioni, prendi i compili, mandi su e basta.Ogni volta ricompili, ogni volta riparti le nuove istanze dei tuoi nodi del cluster.È cambiato tutto.Bellissimo, guarda più ne parli più mi viene veramente la quella che io chiamo la mia scimmietta sulla spalla, no? Che dice guardalo, guardalo.In realtà la cosa che credo più figa in assoluto dal mio punto di vista è proprio quello di provare a cambiare completamente paradigma e a giocare.Quindi giusto per ritornare nel nostro discorso iniziale provare un nuovo linguaggio e provare Askel come primo linguaggio ti aiuta a fare quel gioco quando arriva il nuovo videogioco e devi capire le dinamiche di gioco.Sì.No? E quindi può essere divertente.Spesso è difficile prendere un progetto nuovo e farlo partire in Askel.Quindi dal mio punto di vista secondo me Haskell è quell'esercizio che però, e questo lo dico con quelle due cosettine che ho visto di programmazione funzionale, migliora di brutto anche la parte di programmazione oggetti che faresti.Questo è quello che sto sperendo in questo momento.È interessante, è una formazione forte tra l'altro.Certi principi della programmazione funzionale quando applicati l'obietto orientato al programming danno dei vantaggi innegabili, tipo l'immutabilità, il determinismo, quello non hai bisogno di utilizzare la programmazione funzionale per utilizzarne.E in questo senso hai assolutamente ragione, probabilmente scrivendo programmi procedurali, ma stando attento a utilizzare appunto l'immutabilità, così hai delle garanzie migliori sul tuo codice.D'altra cosa, che dici che ti fa migliorare a livello di programmatore OP, forse sì, ad esempio c'è un pattern classico nella storia di OP che si chiama il visitor pattern.Tu cosa stavi citando? No io sto usando per esempio, ho sostituito parte degli strategi pattern.Abbiamo fatto un talk con il mio collega amico Mario qualche tempo fa in cui andavamo a fare vedere...Visto.Quindi, il visitor pattern non potevo dirlo di averlo capito fino a che non ho utilizzato Haskell.Poi, quando ho utilizzato un po' Haskell e ho iniziato a capire cose, ho detto "ah, ma aspettate".Ma quando ho rivisto il visitor pattern, ho detto "questo è un modo molto scomodo per definire una funzione che si applica su NTP in Haskell".Quindi, in questo senso, sì, vedere un'altra prospettiva ti fa anche diventare un migliore programmatore OP.C'è da dire che va detto che si possono creare un po' delle situazioni un po' strane tipo quella che si è creata in Scala oggigiorno.Io adesso è un po' che sono fuori dal mondo della Scala, devo dire la verità.Il mostro a due teste.Esatto, quello che citavo, non mi ricordo che lo diceva però fa abbastanza ridere.I programmatori Scala si dividono in due persone, una battuta, una buttada.Quelli che vorrebbero che fosse Jama e quelli che vorrebbero che fosse Askel, in sostanza.Ed è però, fa ridere perché, anche con queste battute, è basato su un fondo di verità.Ci sono quelli che cercano di utilizzare Scala alla funzionalità OP e ci sono un sacco di persone che cercano di reimplementarsi le librerie più famose di Askel e la Standard Library in Scala, con dei risultati che non sono sicuro che siano efficaci.Cioè, risultati che una volta che li vedi dici "sì, ma perché allora non abbiamo utilizzato Askel direttamente".La verità è che Scala, girando la GWM storicamente era un po' più facile da introdurre al business.Esatto, secondo me, secondo me Scala ha il suo senso, cioè questa doppia testa, questo mostro a due teste ha il suo senso e secondo me ha il suo senso per tipologie di sviluppatori che vogliono, che si trovano nella mia condizione quindi vogliono provare delle robe funzionali senza sentirsi direttamente improduttivi immediatamente improduttivi no? E quindi cercare di realizzare qualcosa fatto male certo perché però creare qualcosa ci sono degli sviluppatori come come come sono io, che hanno necessità della soddisfazione di aver creato qualcosa di concreto, che poi sia veramente uno schifo, un bug piuttosto che una feature, però hai subito questa soddisfazione immediata e da questo punto di vista Scala ti permette di fare questo, ovvero è che io conosco delle aziende, non farò il nome, delle multinazionali che proibiscono l'approccio funzionale nella loro codebase scala, proprio da guideline, come Biasimarne.Però loro dicono che il ragionamento che fanno è in termini di accessibilità del codice, è un lungo discorso che abbiamo fatto con Matteo Tommasone parlando di code review qualche tempo fa.Cioè se io mi vado a implementare questa parte con un approccio funzionale poi rischio che il newcomer o l'onboarding venga particolarmente rallentato per tutto quello che ci siamo detti prima, Luca, no? A senso, a senso.Sono tutte situazioni che derivano dal contesto storico.Se si fosse partiti direttamente dall'insegnare la programmazione funzionale, è per quello che dico che nel giro di una generazione non ce ne preoccuperemo perché man mano che è più diffuso, magari le persone usciranno dall'università o dalle scuole professionali utilizzando già la programmazione funzionale e non avranno questo problema di dire "ah mi devi spiegare cos'è una funzione di ordine superiore per iniziare a lavorare".Io so che avendo vissuto la community Scala mi ricordo ancora un talk di un ragazzo allo Scala Italy di cui ho profonda stima che però per mostrare le type signature di questa libreria funzionale di Scala, che si chiama Scala Z, ma sono uguali, Scala Z e Scala Z fanno più o meno la stessa cosa.Mi sembra che fosse ancora il tempo Scala Z, forse era Cats.Mostrava la documentazione di Haskell e sinceramente c'era una situazione un po' strana, perché veramente se devi spiegare Haskell per spiegare, per far capire scala z, allora forse questo turno sta venendo particolarmente bene.D'altra parte ci sta perché io anche io ho fatto lo stesso errore, se mi concedi il termine.Anche io, piuttosto che non...proprio per lavorare in funzionale ho preso il primo lavoro con il primo linguaggio funzionale che c'era, proprio per il gusto di dire "ho fatto programmazione funzionale per vivere, cioè ho guadagnato con la formazione funzionale.Ovviamente ho imparato tanto, quindi non è stato proprio un errore, però alla fine magari poi finisci per mettere delle robe troppo avanzate in un linguaggio che non è troppo espressivo per esprimere quel genere di cose.Soprattutto uscirò a scala 3 e sinceramente sono un po' fuori dal mondo, però so che forse stanno risolvendo certi problemi tipo...Io vedo che mia moglie lo attende con ansia quindi...La tua moglie lo attende con ansia? Sì.Lo attende con ansia sì perché dovrebbe essere una soluzione ufficiale a certi problemi che ci sono proprio in scala 2 tipo banalmente come definire una type class dovrebbe essere risolto questo, anche se scusate ma non abbiamo detto che cos'è una type class però qualcuno magari lo attende in scala e sente questo.Ho visto che il tempo sta volando, Io volevo farti un'altra domanda.Quindi abbiamo detto che Askel dai possiamo farcela, motivaci da questo punto di vista.Allora se ce l'ho fatta io ce la potete fare anche voi.Io sono il più poveretto.Assumete che io sia la persona meno competente tra di voi.Veramente.E ce l'ho fatta.Quindi il problema non è quello.Il mio consiglio è trovatevi, se ci riuscite ovviamente quello che dicevo all'inizio, un mentore che vi segua.Il problema del mentore ovviamente che a quel punto diventa una funzione di quanto è bravo il mentore ed è molto rischioso.Io se volete imparare Askel, quello che vi consiglio è prendete contatto con la community italiana di Askel.La community italiana di Askel non è stata fondata da me, come qualcuno va in giro a dire, io semplicemente l'ho un po' organizzata per qualche anno, adesso ultimamente con i figli ci sono un po' staccato, però è piena di persone brave, competenti e gentili.Anche c'è questa nomea della community Haskell di essere un po' tossica, se si va su Twitter così, sinceramente nella community Haskell italiana non c'è mai stata.Veramente persone che sono sempre disponibili a tutte le ore del giorno a cercare di rispondere ogni di ogni risultato e c'è veramente tutti i livelli di gente che inizia da zero.Un tempo organizzavamo degli incontri italiani, ci incontravamo e spieghiamo le basi, iniziamo a iniziare.Ed era interessante, c'erano anche 30-40 persone.Il primo incontro c'erano 12 persone, però vabbè.Poi mano a mano abbiamo capito che anche lì è una funzione di dove lo fai, in che città lo fai, quando lo fai, insomma nel weekend, poi la gente magari non ha tempo, non ha voglia.Però veramente, nella comunità italiana di Askel, che è Askel, il cui sito dopo mettiamo nei link, mi sembra che sia askelita.it, perché Askelit non ce l'abbiamo perché ci hanno rubato il dominio, ma questa è un'altra storia.Comunque, nella comunità c'è piena di gente, c'è una mailing list che adesso purtroppo è morta, ma c'è un canale di telegramma invece dove scrivono ogni giorno.La gente chiede, fa domande su Ask e riceve risposte.C'è un canale su IRC se vi piacciono queste genere di cose, che è uguale, è lo stesso canale collegato, sì esatto, che si riescono a ottenere risultati e poi che si parta da un libro.Ora, la situazione dei problemi di un libro, sul canale di Askle vi possono consigliare tutti i libri adatti.Ci sono tanti libri, tanti libri diversi, non c'è un libro migliore dell'altro, però veramente fatelo.Dove non c'è teoria delle categorie spero.No, ma la teoria delle categorie...allora, la verità è che fare delle battute su Askle è stato un po' come sparare sulla croce rossa.aveva all'interno dei concetti che avevano dei nomi così astrusi che farci delle battute sopra venivano veramente troppo facili.Purtroppo si è creato un po' un senso di celodurismo dietro queste cose, un senso di superiorità di qualche tipo, ma è una sensazione tossica che andrebbe smontata sostanzialmente.Quando vedo un talk, che succede un sacco di volte, quando vedo un tolk a una conferenza di cui qualcuno si vergogna di dire la parola monade, o magari fa monade e poi fa l'occhiolino, quelle robe lì, sono cose tristissime, diciamocelo.Cioè sono cose che non aiutano i neofiti, spaventano solo le persone.E' proprio celodurismo, scusate, non so se si può dire durante questa cosa.Cioè l'idea di "ah, io ho capito una cosa molto difficile", perché comunque sono cose difficili di nuovo, semplici, nel senso che sono pochi concetti ma difficili, nel senso che richiede una grande energia nella cerca di capirlo, ma non aiuta la comunità a cercare di andare avanti del fatto di averle capite mentre le altre persone non le hanno capite.Se possibile aiuta invece a cercare di approcciare vari modi, quello che hai detto te, delle scatole e cose così, per cercare di spiegarlo.Quello secondo me aiuta di più.Cercare di far capire che questi concetti sono alla portata di tutti, anche quelli che iniziano da zero, veramente.Secondo me è importante.Un po' sai c'è questa cosa di violenza, nel senso che l'ho vista per esempio per tutti quelli che per sbaglio rappresentano una promise come una monada.E là succede il finimondo, l'aggressione, no? Che come dici tu può anche essere una modalità di protezione per uno, però capisci che spaventa."Eh un endofuntore! Cosa vuol Cos'è un indossatore? C'è tossicità in tutti i mondi lavorativi.Noi abbiamo la possibilità di essere molto analitici e molto razionali, perché il nostro lavoro ce li impone.In questo dovremmo anche riconoscere che ci sono certi comportamenti tossici che possiamo semplicemente smontare, basta che decidiamo di non seguirli più e andare così.Quindi fare scemi, fare vergognare una persona perché non ha capito un concetto complesso, cioè che è strato.L'hai detto all'inizio Teo, è astretto, quindi non è un concetto normale, non è una cosa che ti posso spiegare davanti a una birra.Ogni tanto lo faccio perché mi trovo qualcuno che mi dice "ok Luca, questa volta mi devi spiegare cos'è una monade".L'ho fatto su un foglio di carta igienica, una conferenza davanti a una birra.Sono divertenti da farlo, però non c'è bisogno di fare di vergognarsi se uno non lo capisce.Io stesso ci ho messo mesi, mesi proprio che mi faceva male la testa, non ci capivo niente.Quando ho iniziato a lavorare, lavoravo in C#, avevo questo libro bellissimo di Haskell, che adesso purtroppo non è più utilizzabile perché è cambiato così tanto Haskell che non è utilizzabile.Un libro piccolino si chiama "Haskell School of Expression" e vi giuro io lo leggevo e non ci capivo niente.Non capivo neanche dove volevo arrivare.Ci ho messo mesi.A me piace questa sensazione, è una sensazione che viene dalla matematica, quella sensazione di avere un problema e non lo capisci, poi improvvisamente lo capisci e ti senti… Sì, quando si spanna la nebbia, è una sensazione particolarissima.Esatto, a me piace, però mi rendo conto che può non piacere a tutti e può generare frustrazione nelle persone e quindi dobbiamo metterci, dobbiamo essere empatici, metterci anche nella posizione delle altre persone e cercare di trovare i vari modi.Sì, verissimo, verissimo.Ultima domanda, così ti lascio e ti ho rubato un sacco di tempo.Scusami, adesso siamo stati… beh, adesso avevamo in programma di fare delle cose, di raccontare delle cose, magari andando un po' più nel dettaglio di Ask, non l'abbiamo fatto, magari puoi decidere te, magari si viene fuori un certo commitment da parte della comunità, magari possiamo anche ricontrarli.Vi siamo.Io do la mia massima disponibilità per andare più sul concreto, diciamo.Sì, no ma credo che da questo punto di vista sia stato un confronto, un confronto in parì, nel senso che...Ma che in parì? In senso che tu sei più preparato di me, scusami.No vabbè, però serve il mio obiettivo fondamentalmente con questa chiacchierata, era quello di dire ok io ci sto provando questa cosa mi sta gasando un sacco forse spaventa un po meno di quello che generalmente spaventa quando ci si approccia quindi questo era il messaggio fondamentalmente.E' arrivato la rovina! Sai cosa mi piacerebbe fare invece? Provare a fare un'altra chiacchierata dove parliamo invece dei pattern.Dall'approccio funzionale e pattern perché secondo me tieni prete che il mio mondo cioè il fatto che io mi sia incuriosita la programmazione funzionale viene da quel talk che tu hai citato sui pattern con Mario.Anche tu hai il cappello rosso scusa questo.Sì sì ce lo danno tutti quando ti assumono te lo danno sì bello sono fiero.Ah io sono fiero di lavorare per Red Hat.Quello devo dire è una delle società migliori per cui lavorare, per cui ho mai lavorato.Anzi, è la società migliore per cui ho lavorato di sicuro.E secondo me è anche una delle migliori società in cui lavorare oggigiorno.Guarda, ti dico solo che ci sono alcuni membri della nostra community che ambiscono a quel posto.Mi fanno bene.Mario storicamente a livello di community è stata un po' la figura più esplicita rispetto a lavorare...perché banalmente tutti i tour che gli faceva con il cappello rosso.Io tendenzialmente ho...mi hanno assunto nel 2017 quindi sono comunque un acquisto recente, diciamo così.Però posso capire perché tanta gente vuole lavorarci.È una combinazione unica di open source, tecnologie e argomenti interessanti che è bello e innegabile.Secondo te esiste un mondo del lavoro pronto a assorbire delle persone che sperimentano questo approccio più generico, diciamo, programmazione funzionale? Perché, anzi, entrambi gli elementi… Le offerte di lavoro non sono tantissime, non sono neanche poche.Spesso girano appunto per la comunità Haskell.io vi dico che nel Comitato Askel dove c'è della gente ben più preparata di me, soprattutto su Askel, quindi ben più preparata in generale, ma soprattutto su Askel, a ordini di grandezza più preparate, c'è anche un sacco di gente che ci lavora, che proprio guadagna uno stipendio così.Ovvio che uno deve avere un po' una prospettiva globale e iniziare a pensare di poter lavorare all'estero, nel senso di trasferirsi all'estero.Tante persone hanno fatto così, sono trasferite all'estero, a Londra, a Zurigo, e invece tante persone lavorano da remoto per società estere.In realtà, a meno che uno non sia innamorato di Haskell, pensa che proprio sia la sua vita, se posso dare un consiglio agli ascoltatori, di stare un po' attenti a fare una scelta del genere.Se uno vuole fare come esperienze di vita e di reti ottimizzate, però alla fine scegliere un lavoro è sempre un insieme di fattori, la cui tecnologia è semplicemente un fattore che possiamo decidere se dare più peso o meno peso.Se uno vuole ottimizzare oggigiorno per un lavoro in Haskell, quindi voglio a tutti i costi un lavoro in Haskell, lo trova.Non è che necessariamente otterrà il lavoro...anche se si aspetti di trovare il miglior lavoro del mondo, perché ovviamente se tu attomizzi un fattore gli altri fattori vanno a farsi benedire, quindi magari perdi in post brutto, la location e così, magari lo stipendio è anche più basso, anche se questo non lo so, la verità è che non lo so quanto pagano le società che fanno ASCQ.Tendenzialmente è difficile trovare programmatori, punto, è difficile trovare programmatori ASCQ ancora di più, quindi se una società ha investito in ASCQ si trova in una situazione un po' strana, perché se uno se ne va c'è il rischio che non trovi nessun altro che lo sottituisca, che vuol dire che poi le società non investono in questa tecnologia.Ci vuole una massa critica.Paradossalmente oggi è più facile trovare un lavoro pagato bene in Java che in Haskell, anche se in Haskell c'è più richiesta, perché giustamente ci sono più società che hanno investito nella tecnologia perché sanno che se c'è qualcuno che se ne va dalle dimissioni, in tal caso è più facile da rimpiazzare con qualcuno anche di bravo, diciamo.Abbiamo citato Scala, scusate, scusa se mi prendo 5 minuti, abbiamo citato Scala.Io quando lavoravo in Scala e girovavo nella community Scala a Milano, conoscevo una società, che qui non si dice peccato ma è un peccatore, che assumeva tutti i programmatori in scala.Cioè tu scrivevi che sapevi programmare in scala e quella società ti assumeva.Era bellissimo.Un momento più unico che era, proprio un momento di popolarità di scala incredibile.Quando aveva l'hype di essere il linguaggio difficile.Sì sì sì, anche.Però non era importante.Cioè tu ti mettevi a studiare in scala, ti impegnavi un po', e fai così.D'altra parte il nostro mondo del lavoro è così, non so te, ma con un minimo di visibilità si ottengono un sacco di offerte di lavoro, proprio che si fa anche un po' fatica di stricarsi a capire cosa uno si vuole.Quindi dico, se oggi uno vuole ottimizzare per usare Askedin in produzione, ce la si fa.Ovviamente tutti gli altri fattori vanno un po' a farsi benedire.Se il tuo unico fine è quello, questo va un po' in un discorso generale, Se il tuo unico fine è guadagnare sempre più soldi, ovviamente tutti gli altri fattori vanno a farsi benedire, magari usi una tecnologia meno bella.E purtroppo...- Cobol? - Eh, banalmente.Ci parlo proprio con le casoline.A oggi, paradossalmente, credo che il lavoro più pagato sia il programmatore Cobol, che è probabilmente la tecnologia che meno programmatori vogliono usare.Ecco, ovviamente, se ottimizzi per i soldi, perdi in alte...è sempre un compromesso, no? E quindi dico, se vuoi utilizzare...Io consiglio sempre di studiare Haskell perché è appunto un freestart.Si parte da zero, impari cose nuove, cose che non hai visto, soprattutto se sei un po' annoiato e così.Ti dà una visibilità su una nicchia che non è necessariamente accessibile, cioè non la vedi, se non ti ci infili dentro non la vedi.Poi una volta che la vedi scopri che è fatta di persone bellissime, che appunto ti danno una mano, che sia tutti sulla stessa barca, perché quando il linguaggio è così difficile e richiede così tanta energia, si fa un po' come un'ella, no? Dici "ah, grande che ce la fai, dai, anch'io ieri ho capito i trasformazioni monadici".- Esatto, esatto.E quindi trovi una bella comunità.Quindi c'è tanto da ottenere e imparare questo linguaggio.Se ovvio che se veni a domani e direi "ah, devo imparare ASCAP per guadagnare più soldi" ti dico "ma guarda, fai altro".Uno lo fa per la passione, non lo fa per… - Ma probabilmente smetti anche di programmare se vuoi guadagnare più soldi ancora.- Io secondo non lo so.Io ti dico che sono Io sono, scusami se prendo un altro minuto, io che sono sessuale da questa idea della mentorship appunto, di avere una persona, mi piacerebbe tantissimo trovare qualcuno che non viene dal mondo della programmazione, quindi che non ha affatto informatico, ingegneria informatica, così, e che decide di lasciare tutto per fare programmatore.Perché c'è così tanto bisogno di programmatori, che veramente secondo me ci vorranno tre generazioni prima che saturiamo al mercato.Mi piacerebbe tantissimo che qualcuno approcciasse perché potrei far vedere comunque un mondo lavoro dove ci sono tante richieste di lavoro, dove ci sono contatti a tempo indeterminato, dove ci sono soldi.Cioè basta lamentarsi che non ci sono soldi quando ci sono dei lavori come il programmatore che non vuole fare nessuno.Ogni volta che qualcuno dice "ah non riuscirei a stare davanti al computer tutto il giorno" vieni a fare il mio lavoro, vedi che ci sono dei soldi e che la questione diventa interessantissima.Stavo cercando, poi chiudiamo, perché quello che dici tu è importantissimo ed è bellissimo quando entra nel mondo della programmazione delle figure di mondi completamente diversi.Qualche anno fa, adesso non mi ricordo se era nel 2018, c'è stato qua a Lione lo Scalaio, è la conferenza francese più importante di Scala, una roba fighissima, uno degli eventi più belli a cui ho assistito e tra l'altro uno dei talk, adesso non mi ricordo che libreria portava, ha sviluppato una libreria su Scala, era un medico.Bellissimo.Ha sviluppato questo tool anche di una certa complessità, però era un medico e il fatto di approcciare alla programmazione col suo punto di vista con la sua forma mentis perché quello che studiamo e quello che facciamo ci mutano.Certo.Cioè ragazzi noi siamo sviluppatori anche quando andiamo a fare la spesa.Si è vero.E così ed è stata un'esperienza veramente bella e quindi evidenzio e sottoscrivo quello che hai appena detto da un punto di vista.Speriamo che in futuro ci saranno più persone che approccio la programmazione e speriamo che qualcuno decida di partire dalla programmazione funzionale.Vi aspetto grande cose per il futuro, sono veramente positivo.Io continuo a giocarci.Grande.Grandissimo.Bene Luca, io...Se ci si domanda siamo sempre a disposizione veramente.No, sì, in realtà adesso che me l'hai detto provo a cercare la community Haskell e a provare a a rompere le scatole un pochino perché credo molto nel valore della community e quello che tu dici appunto del fatto che all'interno della community si possano condividere pain e gain oltre al concetto che ti può passare una persona c'è anche tutto quell'altro valore che fa da contesto e diventa catalizzatore e energia che tu metti nella macchina durante la fase dell'apprendimento, no? Assolutamente.Queste comunità con un'identità forte hanno più energia.Più difficile invece aggregare comunità come, ad esempio io sono un admin del Java User Group a Milano e certe cose è più difficile catalizzare l'energia lì perché uno sviluppatore Java ha diversissime sfaccettature, vede proprio di tutto.Lì è difficile neanche trovare gli argomenti di cui si può parlare.Invece qui che c'è un'identità più forte, anche di "newbie" li hai chiamate all'inizio, di principianti, di lettanti, perché no? Tutte parole che in italiano hanno una connotazione negativa e che non dovrebbero averlo.Infatti io uso "nubo" per quello.Sì, ma fa ridere, scusami se te lo dico perché principiante, dilettante in italiano vuol dire semplicemente che una persona che ha appena iniziato e tutti c'è qualcosa che non sappiamo fare.Come abbiamo detto prima io so fare solo questo lavoro, se mi mettessi a fare qualsiasi lavoro e sarai un principiante.Non succede niente, si parte dall'inizio per tutti.Luca è stata una chiacchierata fighissima.Ripeto mi piacerebbe davvero bissare la cosa magari prossimamente ci organizziamo.Io ti devo ringraziare infinitamente a nome mio, a nome degli ascoltatori di Gitbar.Giusto l'ultima cosina noi abbiamo un momento che si chiama "Il Paese dei Balocchi"."E conduco nel Paese dei Balocchi" "Ah, il Paese dei Balocchi" Ah, va bene, è facile, è facile, questa è già la risposta.Condivido proprio quel libro di cui ti ho citato prima, "The High School of Expression" di Paul Yudak, un professore di fisica, un professore di fisica di università americana, non mi ricordo quale università se fosse Stanford o altro, che recentemente tra l'altro se n'è andato, è stata una perdita molto molto sentita nella community.Poliudeck fa parte dei fondatori di Haskell e quel libro è una perna, anche se purtroppo gli esempi non sono più aggiornati, non sono più utilizzabili.Uno si aspetta un professore...Tanto era un professore di fisica, mi sta venendo il dubbio che lo fosse...Beh, comunque era un professore di scuola.Uno si aspetta che un professore fisica ci sia una cosa incredibile, invece il libro utilizzava delle metafore prese dal mondo dell'arte, bellissimo.Quindi aveva un capitolo sulla programmazione grafica dove disegnava dei frattali, un capitolo dove disegnava, definiva l'algebra della musica.Io vengo dall'informatica musicale e proprio per me è stata una cosa bellissima.Cercare di vedere qualcuno che con Askel invece del classico esempio, non so, il database così, provava a dire le sette note, le proprietà, gli accordi e poi con il caso del mondo reale ci facevano sintetizzatore MIDI, quindi c'era la parte di grafica, c'era la parte di musica.Il libro è relativamente corto perché è proprio...adesso qui è un podcast quindi non si vede me che lo faccio, però non è uno di quei mattoni così, è molto denso, esatto, è molto bello e purtroppo è difficile trovare online, però quella è la mia perla, quella è la mia perla rara.Paul Hudak ha scritto quel libro lì e devo dirti la verità se scrivesse un libro mai su Ask, chissà ma che lo farò, mi piacerebbe fare una cosa simile.Non troppe pagine, non troppi concetti, ma spiegare i concetti alla base e spiegarli in un modo così interessante per me è stato significativo veramente.LM: bellissimo.Questo metteremo un eventuale link, non so se lo vendono ancora.io l'ho trovato su...me l'ha regalato un mio collega, è stato gentilissimo, l'ho usato.C'è un sito che si chiama Abe Books, è scritto Abe, Abe Books, ed è un sito che ha tutti i libri usati universitari, così, anche libri usati, così, e me l'ha regalato da lì, se non sbaglio l'ha anche pagato relativamente poco.Non so quante copie ce ne siano in giro, ci stava un pdf, forse c'è una versione in tech, in latex compilabile online di qualcuno che l'ha portato, è una perla rara, bello, ovvio che se devi andare domani a lavorare in Asche non ti consiglierei di farlo.No però sono quelle passeggiate da geek che ci facciamo, no? Allora scusa dai ne approfitto e ti cito un altro libro, nel caso è questo introvabile, c'è il libro, aspetta che lo prendo perché c'è un film di Beria, sono libri di questi qua, di Matthias Fällensen e Daniel P.Friedman.Allora, questo qui è il libro loro più famoso, si chiama "Little Java, a few patterns".Bellissimo.È un libro che fa incazzare le persone online, perché si chiama "Little Java, a few patterns", quindi la gente è convinta che parli di design pattern in Java, in realtà parla di programmazione funzionale e di tipi di dati algebrici.Però non lo sai, è bellissimo questa cosa, e non lo sai finché non studi la programmazione funzionare i tipi di dati algebrici.È bellissima questa cosa, veramente.Che bellissima, è un libro, diciamo, un accendifuoco fondamentalmente.È bellissimo, è un libro che se lo leggi un programmatore Java classico, dici "ma che cazzo ve lo sta dicendo, veramente, perché programma così? Nessuno programmarebbe così".Poi in realtà scopri che questi due tizi, questi sono molto famosi, hanno scritto un libro su Java, hanno scritto due libri su l'ISP, si chiama "Little Schemer" e un altro che ha un nome simile ma non ricordo, poi c'è un libro su Prolog, sulla programmazione logica, quindi vengono anche questi un po' da quella nicchia dell'accademia così, però scrivono un libro che è totalmente diverso da ogni libro che puoi leggere, anche questo è corto e introduce i concetti della programmazione funzionale, bellissimo.Bellissimo, me li metto tutti nelle note dell'episodio.Sono stati dei gingilli fighissimi.Io ripeto, non so come ringraziarti Luca, nome mio e al nome di tutti i ragazzi.È stata una chiacchierata più che costruttiva, mi sono divertito un mondo, quindi dobbiamo assolutamente bissare.Quindi niente, grazie Grazie mille alla prossima.Spero che questo episodio vi sia piaciuto, sentite la mia voce un po' diversa dal solito perché il microfono ha smesso di funzionare.Vi prometto che adesso ci butto un'occhiata e provo a vedere qual è il problema.Se l'episodio vi è piaciuto mi raccomando aprite e cercate Gitbar con il vostro client di podcast e iscrivetevi in modo da ricevere ogni settimana le novità sui nuovi episodi, se poi vi è piaciuto veramente tanto beh a quel punto fate una recensione dentro l'iTunes, le recensioni ci aiutano a contattare, a raggiungere più persone possibile per far crescere la nostra famiglia di Gitbar.Vi ricordo rapidamente che ci siamo tutti i giorni nel nostro gruppo Telegram, lo trovate semplicemente digitando gitbar e vien fuori tra l'altro abbiamo degli sticker favolosi e nulla se invece volete contattare direttamente me potete farlo sì certo dal gruppo telegram ma anche a info@gitbar.it o a @brianrepo su twitter detto questo noi ci diamo appuntamento alla prossima settimana qua da Leon è tutto un saluto ciao GitBar, il circolo dei fullstack developer.Una volta a settimana ci troviamo davanti a due birre e con BrainRepo parliamo di linguaggi e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei fullstack dev.
