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 appuntamento di GITBAR in versione estiva.questa versione estiva in realtà un periodo un po' particolare non mi sento solo anche se sono tornato in Sardegna e ho lasciato le riunioni lionesi finalmente nella buona parte delle puntate che sto registrando qua sono accompagnato da ospiti una serie di ospiti super preparati come quello di oggi abbiamo con noi Marco qualcuno lo conoscerà su...Ciao! Ciao Marco qualcuno ti conoscerà su twitter come Marco Shuttle è uno sviluppatore a Soeasy, una società che si occupa di gestire sistemi di pagamento a rate, un categorical developer, pensate è talmente difficile per me anche da dire, conosce i linguaggi come Askel che per me è abbastanza esoterico, ho provato a guardarlo ma mi sono spaventato ed è un amante del cioccolato.Ciao Marco benvenuto Ciao Mauro, grazie, ciao a tutti.Ti faccio subito la domanda che faccio a tutti, ed è come hai iniziato a sviluppare? Come sei entrato in questo tunnel senza via d'uscita? Allora, io ho iniziato relativamente molto tardi a programmare perché per lunghi anni non è assolutamente stato il mio desiderio, quello di diventare un programmatore.Io sono rimasto all'università fino a circa 28 anni, tra laurea, dottorato e una piccola borsa di studio dopo il dottorato, fino a che mi sono reso conto che non era la vita che faceva per me, quella di restare nel mondo accademico e ho deciso di tornare in Italia, ero in Polonia al tempo, per avere qualcosa di un po' più stabile e quindi sono tornato in Italia e mi sono guardato un po' in giro su che lavoro potevo fare con una laurea in matematica e conoscenze non particolarmente applicabili al complesso mondo del lavoro e i due ambiti dove mi sono messo a cercare era stato in ambito bancario e in ambito come programmatore, dall'ambito bancario non ho mai ricevuto nessuna risposta, mentre nell'ambito programmazione bastato mandare in giro rispondere a qualche annuncio online per ricevere risposte e essere praticamente assunto dall'oggi al domani, quindi c'era molta più richiesta in ambito programmazione che in ambito bancario e così ho iniziato, un po' per caso, avevo fatto un po' di corsi di programmazione all'università, ma soprattutto software legati alla matematica, simulazione, modellazione, quindi non programmazione oggetti, non programmazione funzionale.Qualcosa tipo Matlab.Esatto, Matlab e matematica avevo usato.Quindi sì, avevo le mie idee di programmazione, sapevo scrivere qualche scriptino, ma non avevo mai fatto niente di serio.e quindi mi sono trovato a 28 anni a iniziare a imparare a programmare seriamente.All'inizio ho iniziato a lavorare in un'azienda che sviluppava gestionali Microsoft e quindi mi sono trovato a sviluppare questo gestionale enorme perché ovviamente la soluzione Microsoft pensata per qualunque cosa e mi sono appunto trovato in mano questa codebase enorme, ho dovuto iniziare a imparare a gestirla un po', a mettere le mani qui e lì per farci fare un po' quello che serviva e da là più o meno dopo ho iniziato, ho iniziato a capire un po' di cose, ho iniziato a dire "ah, mi piace più questo, mi piace più quello" e a muovermi e dopo pian piano diciamo mi sono direzionato verso le cose che mi divertivano di più.Eccoci qua ed era là che vorrevo arrivare in realtà hai già messo le basi per questa domanda in parte hai anche già risposto secondo me naturalmente ma ho visto che comunque nelle tue presentazioni ritorna pesantemente la parte della programmazione funzionale con askel e via dicendo e da amici in comune so che hai approfondito pesantemente l'argomento.Quindi la mia domanda è perché hai approfondito la programmazione funzionale? Cosa ti ha spinto verso quel mondo? Oltre naturalmente alle basi accademiche? Allora anche qua direi che la risposta principale che mi viene in mente è principalmente per caso perché ovviamente quando ho iniziato a programmare anche negli anni successivi, primi anni in cui programmavo non avevo idea di che cosa fosse la programmazione funzionale, non sapevo che esistesse, cosa fosse, di cosa si trattasse e quindi diciamo andando avanti con il lavoro ho iniziato come molti di noi a diventare un programmatore ad oggetti, quindi a iniziare a studiare pattern e framework ad oggetti e tutti i concetti di questo tipo.Ad un certo punto mi sono trovato a essere curioso di che cos'era la reactive programming, quindi che non è qualcosa di strettamente collegato o necessariamente collegato alla programmazione funzionale, E mi è capitato a un certo punto, sottomano, un linguaggio che si chiama ELM, a cui mi sono interessato perché al tempo si pubblicizzava come un linguaggio per fare reactive functional programming, ma io ovviamente al tempo ero interessato alla parte reactive, non necessariamente alla parte functional.Quindi ho iniziato a imparare un po' ELM, ho letto il tutorial, ho fatto qualche piccola applicazione, giusto per giocarci un po' e imparare a usarlo, mi è piaciuto molto.E da lì ho iniziato a scoprire tutti questi piccoli concetti di programmazione funzionale e ho iniziato a ricollegare a tutto quello che avevo fatto all'università.Ho iniziato a dirmi "ah, ma nella programmazione serve un po' quello che ho studiato di molto teorico all'università, ci sono cose che si collegano molto bene".E quindi da lì poi ho iniziato un po' a tralasciare l'aspetto di programmazione reactive e avvicinarmi invece molto di più a quella che era la programmazione funzionale in sé, quindi sono passato principalmente prima da Elma e poi mi sono spostato principalmente verso Haskell, che è un po' il linguaggio che è un po' più evoluto all'interno paradigma funzionale fortemente tipato.Hai parlato di reactive programming e programmazione funzionale qualche secondo fa e hai detto che sono comunque dei concetti comunque diversi.Dove sta la differenza tra reactive programming e paradigma funzionale e cos'è la reactive e che cos'è la funzionale? giusto per mettere un pochino in ordine le idee e muoverci con delle basi.Certo, allora innanzitutto secondo me sono due concetti diversi perché principalmente si può fare uno senza fare l'altro.La programmazione reactive è qualcosa dove l'oggetto principale, oggetto non inteso strettamente come programmazione a oggetti, ma nel senso la cosa su cui si lavora principalmente è uno stream di dati, dove uno stream di dati è qualcosa che si aggiorna nel tempo, è praticamente un data type che si aggiorna nel tempo.Quindi non lo so, un tipico esempio può essere gli eventi in un browser quando si lavora front end con javascript che si sta in ascolto agli eventi.Quindi se si guarda lo stream degli eventi è qualcosa che muta nel tempo.Programmazione funzionale può trattare appunto uno stream di dati ma può anche dire ok tratto come oggetti tutt'altro.Il focus principale per come la vedo io della programmazione funzionale è da un lato il descrivere le cose con le funzioni, che diventano oggetti di primo ordine nel linguaggio, ma soprattutto, e io qui guardo soprattutto la programmazione funzionale fortemente tipata, la capacità di descrivere con tipi di dato in maniera molto precisa quello su cui si sta lavorando.Grazie per averci un po' chiarito le idee e qua mi collego con una cosa che guardavo qualche tempo fa.La settimana scorsa abbiamo avuto come ospite qua a Gitbar Massimiliano Arione, probabilmente lo conosci.Di nome sì.E con lui abbiamo provato a dare un'occhiata al mondo del domain driven design.Una cosa molto carina che ho avuto modo di vedere questo quest'ultimo periodo sono alcuni talk che provano a raccontare a portare il contesto del DDD sulla programmazione funzionale ed è una cosa che mi ha affascinato perché in realtà c'è un utilizzo dei tipi che si presta molto bene a quel tipo di paradigma.Come vedi appunto l'ingresso dei concetti di DDD sul mondo della funzionale? Io lo vedo assolutamente come una coppia se non perfetta che si avvicina molto alla perfezione.Le due cose che mi piace molto approfondire nel campo della programmazione sono proprio programmazione funzionale e domain driven design e credo che che si sposino veramente bene.Secondo me è un pochino un peccato che Domain Driven Design sia nata e cresciuta in un mondo fortemente ad oggetti e che quindi i libri famosi che si trovano in giro raccontino i pattern da un punto di vista prettamente della programmazione oggetti.Però già se si guarda, se si legge il libro di Evans su Domain Driven Design, si trovano molte idee che vengono dalla programmazione funzionale, per esempio mi viene in mente quando parla di value objects, dice esplicitamente che è molto meglio che siano immutabili e tante altre piccole cose di questo tipo, anche semplicemente ragionare ad eventi è semplicemente un modo per rendere lo stato di un'applicazione un oggetto immutabile, è un modo per reificare il cambiamento di stato.Quindi anche quello può essere facilmente visto come un'idea che viene dalla programmazione funzionale, poi magari l'idea non è effettivamente nata da lì, ma si sposa molto bene con un approccio di programmazione funzionale.Greg Young, che è praticamente l'inventore di CQRS, Common Query Responsibility Segregation, che dice che event sourcing è praticamente un fold degli eventi partendo dallo stato vuoto.In realtà è effettivamente quello, dove il fold è, pensiamo a un for each che accumula uno stato.Quindi anche quello il fold è un concetto tipico di programmazione funzionale, quindi effettivamente tra domain driven design e programmazione funzionale ci sono molti punti, se non in comune, che si sposano bene tra loro.Ultimamente stavo leggendo anch'io un libro, se non mi ricordo male, di Scott Flushing, che si chiama Functional Domain modelling o qualcosa di molto simile.Io ho visto dei talk di Scott Glash, non riesco neanche a pronunciarlo, pensa te.Non sono sicuro che la pronuncia sia quella, io ho provato come mi veniva.Lui lavora in F#, no? Si, lui lavora in F#.Raccontava l'importanza dei tipi, il sistema dei tipi, come concetto di contratto con il business, veramente veramente affascinante.Sì, è assolutamente molto bello, anche perché presa l'essenza di quello che racconta, è una cosa che mi interessa molto ultimamente, è come sia possibile modellare un dominio assolutamente solo con i tipi, ma se vai proprio all'essenza, quello che ti serve per modellare un dominio, sono funzioni, i tipi prodotto e i tipi somma, dove per essere un po' più esplicito i tipi prodotto sono praticamente dei record, quindi ti permettono di mettere il concetto di congiunzione, quindi abbiamo un record che contiene due cose diverse e e i tipi somma sono invece quelli che ti permettono di integrare il concetto di disgiunzione, quindi "o" e quindi dire una cosa può essere o questo o quello.Per fare un esempio concreto, nel senso un tipo somma può essere, non so, puoi avere hai un colore che può essere giallo rosso o verde e quindi hai dei valori che sono giallo rosso e verde e il tuo tipo che è il tipo colore.Quindi per modellare questa cosa tu dici quello che dici proprio a parole è il mio colore tipo può essere giallo oppure rosso oppure verde.Forse ne abbiamo sentito parlare di questi concetti magari quando abbiamo sentito parlare di Union Types e di elementi di questo tipo.Esatto, gli Union Types sono molto molto simili rispetto ai Sum Types, sono leggermente diversi ma non so se ha senso adesso mettersi a fare il pelo nell'uovo per spiegare la differenza.Direi proprio di no, anche perché non ho abbastanza competenze per poterlo fare quindi potremmo rimanere ad ascoltarti così a bocca aperta ma non potremo contribuire alla discussione proprio per ovvi limiti comunque è un mondo senza dubbio affascinante è un mondo anche che come stavamo vedendo adesso all'inizio spaventa un pochino no? quando sentiamo parlare di Fanktor o Mona di questi nomi quasi esoterici no? un po' che allontanano.In realtà sono dei concetti alla base proprio di tantissimi elementi anche di tipo matematico e della teoria degli insiemi.Ci puoi aiutare a capire cosa sono i functor lemonadi? Ci posso provare.Dopo immagino questa è la solita domanda tra bocchetto.C'è un modo di dire nella programmazione funzionale che dice se sai cos'è una monade allora hai perso l'abilità di spiegarlo.Quindi adesso non so se io so effettivamente che cos'è una monade, però supponendo che io lo sappia e spero che tu, immagino che tu speri che io lo sappia, vuol dire che non sarò capace di spiegarlo.Però vabbè dai, ci proviamo, vediamo cosa ne viene fuori.Allora, innanzitutto ci tengo a dire che effettivamente i termini, proprio "funtore" e "monade" sono cose che vengono strettamente dalla matematica, quindi la terminologia che arriva in questo caso alla programmazione funzionale è qualcosa che non è stata scelta dai programmatori che hanno scoperto o inventato questi concetti.Ma semplicemente erano cose che esistevano già in matematica e qualcuno si è reso conto che potevano tornare utili in programmazione e ha importato questi concetti, portandosi dietro in qualche modo tutto il bagaglio di nomenclatura e di in qualche modo complicazione che la matematica porta dietro, perché anche se volessimo definire così in breve, la matematica breve, questo è un altro tipico gioco di programmazione funzionale, dire che una monade è un endofuntore, no, dire che una monade è un monoide nella categoria degli endofuntori non vuol dire assolutamente niente per chi non ha studiato tante altre cose di teoria delle categorie.Quindi direi che cercare di spiegare queste cose a chi non le sa già praticamente una strada abbastanza in salita, molto in salita, volevo dire senza uscita, però dai, hai un po' di speranza in più.Comunque per cercare di dare un'idea di cosa sono i funtori e le monadi, innanzitutto le monadi sono anche dei funtori, quindi se vogliamo arrivare a spiegare che cosa sono le monadi, dobbiamo prima partire dal dire che cosa sono i funtori.Un funtore per me nella spiegazione più semplice, sono semplicemente un contesto all'interno del cui si lavora, cosa intendo con questo? Se lavoriamo molto con i tipi e vogliamo rappresentare una funzione, una funzione che ha tipo che prende un input di tipo A e mi restituisce un output di tipo B.Quindi dico che il suo tipo è una funzione da AB e per quello che interessa a me e interessa ai programmatori funzionali una funzione che ha questo tipo non può fare altro, dato un input può solo ed esclusivamente ritornare un output, non può scrivere in console, non può fare chiamate HTTP, non può interagire con un database, non può fare niente.Zero side effect quindi.Esatto, zero side effect.Però noi vogliamo fare anche altro, vogliamo scrivere applicazioni che abbiano un minimo di utilità concreta e quindi per fare questo un trucco che si usa è quello di andare a dire nel nostro tipo di ritorno, quindi in B, a dire guarda che io non ti ritorno solamente un B, ma ti ritorno un B in un particolare contesto.Esempio, ti ritorno un B nel contesto maybe, oppure option.Questo cosa vuol dire? Cos'è un maybe? È qualcosa che ti dice ho un valore oppure no.Quindi ti rappresenta la possibile assenza di un valore, quindi se hai un valore di tipo "maybe B" vuol dire che potresti avere un valore di tipo B oppure potresti non averlo.Però questa cosa, la possibile assenza del valore, ce l'hai rappresentata dal tipo.Quindi se adesso prendiamo una funzione da A a maybe B, stiamo dicendo che abbiamo una funzione che prende un input di tipo A e ci ritorna o un B o niente.Una sorta di scatoletta quindi che contiene il nostro valore o il numero.Noi la trattiamo come scatoletta, però in realtà quello che ci sta dentro potrebbe essere il valore o niente.Esatto, e quindi questa scatoletta, grazie per il termine di cui parli tu, è il contesto in cui racchiudiamo il nostro tipo B.In questo caso, nell'esempio di Maybe, è un contesto dove stiamo modellando la possibile assenza di valori.In questo caso, quando guardiamo le funzioni, quello che stiamo modellando è il fatto che la funzione possa fallire.Quindi se abbiamo una funzione da A a B, quella sicuramente ci ritornerà un output di tipo B.Se abbiamo qualcosa che va da A a maybe B, allora stiamo dicendo, forse otteniamo B, forse invece la funzione fallisce.Quindi andiamo a lavorare nel contesto in cui le nostre operazioni possono fallire.A questo punto questo è un particolare contesto.Ogni funtore è uno specifico contesto e quindi potremo avere altri tipi di contesto, quindi non so, il contesto dove le nostre operazioni possono fallire con un particolare errore, oppure un contesto in cui le nostre operazioni dipendono da uno stato e vanno ad aggiornare uno stato della nostra applicazione oppure un altro contesto in cui possiamo leggere dei valori dalla configurazione oppure un altro contesto in cui possiamo interagire col mondo esterno quindi non si usano solo nel caso del fallimento in opzioni dove dobbiamo mitigare gli effetti collaterali esatto, quindi diciamo quello che in programmazione procedurale o in programmazione oggetti in genere sono side effects che vengono inseriti normalmente all'interno del codice in programmazione funzionale semplicemente queste cose, questi effetti vengono rappresentati a livello di type system Quindi viene resa esplicita il fatto che la funzione ha un qualche effetto e lo si fa in genere esplicitando il contesto in cui questa funzione sta agendo.Adesso è un pochino più chiaro.Quindi semplicemente l'idea di Funtore è quella di dire ok, lavoro all'interno di un contesto dove può succedere qualcosa.il qualcosa è determinato dallo specifico funtore che si usa, però è semplicemente un modo per rendere esplicito a livello di tipi quello che può succedere.E invece nel caso la monade che dicevi è un funtore di un certo tipo, su cosa sta la differenza? Allora, alla fine l'idea della monade dopo ovviamente c'è la definizione complessa, matematica, non è roba per noi, la monade è una type class con determinate funzioni che soddisfano alcune regole, ma non è quella la cosa importante perché dopo si cade nell'implementazione, che è importante alla fine è l'idea, che cosa ti dà in più una monade rispetto a un funtore o perché dovrei usare le monadi quando scrivo codice invece che continuare a scrivere codice come ho sempre fatto fino ad oggi.Allora, dicevamo, la monade è un funtore, quindi è un contesto in cui metto dentro miei dati.Adesso, a questo punto, la domanda successiva è l'idea principale della programmazione funzionale è comporre le cose, cioè scrivere tante piccole funzioncine che fanno poche cose, ogni funzione ne fa una singola piccolina e poi comporle, metterle insieme per fare, creare cose più complesse.Solita idea di modularità che si trova un po' in tutti i paradigmi e ogni paradigma dopo lo implementa a suo modo.Il modo della programmazione funzionale è quello di scrivere tante piccole funzioni e poi comporle, dove la composizione di funzioni è proprio quella che si trova in matematica, cioè prendo una funzione f e una funzione g e diciamo che hanno l'output di f e l'input di g e la composizione di f e g è prima eseguo f e poi eseguo g ok, con tutte le proprietà che ne derivano appunto dalla composizione esatto, a questo punto, a questo funziona molto bene per le funzioni semplici, diciamo da a f da a b e g da b a c, le compongo, ottengo una funzione da a c, però se ci ricordiamo quello che dicevamo prima, quando usiamo i funtori, questi contesti, mettiamo, quello che ci interessa, è mettere l'output delle funzioni all'interno di un contesto.Quindi abbiamo una funzione da A a il nostro contesto che racchiude B e abbiamo un'altra funzione da B a C racchiuso nello stesso contesto.Il problema adesso è come facciamo a comporre queste due funzioni in maniera naturale.perché adesso l'output di A è B racchiuso in un contesto e l'input di G è B, non all'interno del contesto.Quello che noi vorremmo riuscire a ottenere è una funzione che prende l'input di F, quindi A, e ci ritorna l'output di G, quindi C racchiuso nel suo contesto.Una monade è semplicemente un particolare funtore che ci permette di fare questa operazione attraverso un'operazione che viene chiamata di solito bind.C'è un'operazione che ci permette di prendere queste due funzioni e ci permette di calcolare la composizione di queste due funzioni.Quindi quello che ci permette di fare la monade è di comporre funzioni il cui output stia in un particolare contesto.Per cui tiene conto anche del fatto che c'è questa famosa scatoletta e riesce a gestire elaborazione di queste scatolette diciamola così in modo vichingo.Ci tengo a suggerire visto che stiamo parlando di questo e credo il modo con cui io più o meno sono riuscito a capire questo concetto e dico più o meno per ovvi motivi c'è un bellissimo libro non so se lo conosce lo dico a tutti gli ascoltatori si chiama "Groking Algorithms" che è un libro illustrato che si impegna proprio a rappresentare concetti algoritmici alcuni anche molto abbastanza complessi come appunto il concetto di monad e di funtore con delle illustrazioni vi metto il link nelle note dell'episodio perché credetemi se l'ho capito io guardando queste illustrazioni può capirlo veramente veramente chiunque scusa Marco se ti ho interrotto ma ci tenevo a dare questa indicazione.Mi è venuto in mente adesso c'è c'è anche un blog post che si chiama "Functors, Applicatives and Monads in Pictures" che penso sia una cosa molto molto simile rispetto a… Ah no, è proprio quello! "Buy my book, Groking Algorithms" quindi l'autore è lo stesso, stiamo parlando esattamente della stessa cosa.Benissimo, benissimo, vuol dire che è una risorsa che effettivamente vale la pena conoscere.sì mettiamo il link nelle note dell'episodio.un altro argomento interessante che vediamo spesso che vedo spesso io quando si sente parlare di programmazione funzionale è il concetto di curring.spero di averlo detto nel modo giusto perché la mia pronuncia inglese come ripeto a ogni episodio è veramente schifosa.quindi quando si parla di, lo dico in italiano, di curring, un sardo quasi.A cosa ci si riferisce? Allora qui nel senso il concetto è abbastanza semplice dopo cerco di raccontarlo a parole mie perché stavo pensando che se c'è qualcuno di...che ho amici che probabilmente tenderebbero a bacchettarmi le dita se non se non lo dico Usa la giustificazione che dovevi farlo capire a me, anche perché non si è scordato l'idea quindi devi farlo capire a me e devi usare necessariamente, devi spiegarlo a picconate quindi sei giustificato ok allora l'idea è quella che per semplificarci le cose in programmazione funzionale vorremmo che tutte le funzioni avessero un solo input, in modo da poter dire che una funzione va sempre da A a B, ha un input A e ritorna un output B.Però, come tutti sappiamo, non ci capita esclusivamente di scrivere funzioni intese come metodi o procedure che abbiano solo input, capita spesso di scriverne che funzioni, metodi o cose che abbiano vari input, quindi il curing è semplicemente una procedura che ci permette di portare una funzione che ha tanti input a una funzione che ha un solo input.Come si fa a fare questa cosa? Semplicemente supponiamo di avere una funzione che prende come input, non so, un colore e un animale e ci ritorna una persona.Ok, quindi abbiamo i due input che sono colore e animale e ci ritorna una persona.Questa cosa noi possiamo riscriverla come una funzione che prende un unico input che che è il colore e ritorna un'altra funzione che prende come input un animale e ritorna una persona.Quindi il trucco è quello di usare higher order functions o first order functions, quindi non ritorni più un valore ma ritorni una funzione.Queste due rappresentazioni sono equivalenti, c'è un modo per andare dall'una all'altra, il currying per andare da più argomenti a un solo argomento ritornando un higher order function, e l'uncurring per andare da funzione con un solo argomento che ritorna un higher order function a funzione con più argomenti.Quindi sono assolutamente equivalenti e serve appunto per riportarsi sempre al caso in cui le funzioni hanno solo ed esclusivamente un argomento.Asckel, per fare un esempio, tutte le funzioni che scriviamo in Askel, anche se ci sembra di scrivere funzioni di più argomenti, in realtà hanno sempre solo un argomento.Quello che si può fare è, se noi abbiamo una funzione in Askel definita che sembra avere due argomenti, e noi ne passiamo solo uno, poi possiamo usare quello che abbiamo ottenuto come una funzione dell'altro argomento quindi possiamo fare quella che viene chiamata "partial application" delle funzioni torna particolarmente utile anche in contesti dove non si parla necessariamente di programmazione funzionale a noi è capitato proprio di utilizzarla in contesti dove abbiamo provato a sostituire alcuni pattern della gang of four e qua si apre un altro piccolo capitolo con la programmazione funzionale molti dei pattern molto del boilerplate code proveniente da questi pattern si va a ridurre ecco come vedi appunto e quali secondo te sono i pattern che sono più facilmente sostituibili con la programmazione funzionale Ok, ovviamente non me li ricordo tutti a memoria i pattern della Gengo4, ti racconto un attimo quelli che conosco meglio e probabilmente li conosco meglio proprio perché hanno un sapore funzionale.Il pattern che ho sempre amato di più è stato il decorator pattern, che io l'ho sempre visto, cioè adesso lo vedo, cioè il decorator pattern si tratta di usare composizione per per creare un oggetto che soddisfa la stessa interfaccia dell'oggetto che viene composto.Quindi per me questo è praticamente abbiamo una funzione da A a B, quindi io vedo l'interfaccia, la vedo come il tipo di una funzione, e vogliamo semplicemente creare un'altra funzione con la stessa interfaccia, quindi che va da A a B, utilizzando la funzione precedente.quindi per me il decoratore è questo, semplicemente vogliamo scrivere una funzione con la stessa firma di un'altra utilizzando quest'altra funzione e possiamo ridurre anche la quantità di codice in modo significativo, un altro che mi viene in mente è anche lo strategy pattern, cos'è la strategy se non una funzione? Un altro pattern, secondo me facilmente riutilizzabile in ambito funzionale, è il factory, in cui semplicemente ci serve qualcosa per andare a costruire qualcos'altro.Questo qualcosa non è semplicemente una funzione che ci ritorna a quello a cui siamo interessati.Quindi alla fine il factory ti dice solo scrivi una funzione e è una funzione diversa dalle altre solo perché la usi per un particolare scopo, però alla fine dei conti è una funzione, non è niente di diverso che dopo tu la rappresenti nel codice come una particolare classe che ci dai un'interfaccia o cose sono sono dettagli implementativi e alla fine è quello che quello che fa alla fine costruirti un oggetto quindi è una funzione che ti ritorna un qualcosa di cui hai bisogno assolutamente ci tengo a suggerire a questo punto visto che abbiamo parlato di pattern un talk di diversi anni fa di di mario fusco uno dei più importanti sviluppatori java anche un java champion che appunto racconta lo switching tra i pattern della game go 4 e gli approcci funzionali quindi prende pattern per pattern e ne spiega l'alternativa funzionale veramente interessante lo mettiamo nelle note dell'episodio perché mi è piaciuto tantissimo quel talk devo dire tantissimo.Domanda in realtà tu sei anche uno sviluppatore php.Come fai a far convivere quest'anima così funzionale in un linguaggio lavorando su un linguaggio che comunque diciamo ha dei limiti dal punto di vista funzionale o almeno si percepiscono tali? Allora questa è una gran bella domanda.Io sono cresciuto abbastanza come programmatore PHP, alla fine è il linguaggio in cui ho lavorato di più e su cui lavoro anche oggi al lavoro, però penso di scrivere un PHP abbastanza diverso dal PHP standard, perché comunque io cerco sempre di, ho sempre in mente, tornando un po' a domain driven design, si diceva prima, un modello del codice basato sulla programmazione funzionale, quindi anche se uso oggetti, metodi, interfacce, la fine quello che ho in mente sono sempre funzioni e tipi di dato.Alla fine dei conti il PHP si è un linguaggio che non è fatto, non è nato e non si è neanche evoluto necessariamente in questa direzione, però comunque è possibile farlo senza un'esigenza, è possibile fare è possibile farlo senza troppa fatica.Secondo me la cosa che manca di più per scrivere in maniera seria programmazione funzionale in PHP è un type system che aiuti veramente lo sviluppatore a tenere traccia delle cose di cui vuole parlare, però per fortuna anche anche se manca a livello di linguaggio, il fatto che ci sia adesso da PHP 7 un abstract syntax tree diciamo allo user level, ha permesso l'analisi di librerie che praticamente danno in mano allo sviluppatore un type system a livello di libreria.Sto parlando principalmente di librerie di analisi statica come PHPStan o Psalm, io le vivo queste librerie come dei compilatori, quindi così le tratto quanto riesco, io cerco, il mio modo di lavorare è a far girare queste librerie a ogni salvataggio del mio file, in modo da avere un feedback immediato dal mio compilatore che mi dice se sto rispettando i tipi che ho scritto oppure no, in modo da avere un feeling molto simile a quello di un linguaggio compilato come può essere Askel, Elm o altri linguaggi di tipo e altre linguaggi funzionali.Sempre grazie a PHPStand o Psalma si possono usare cose molto affini a quelli che sono i generics in Java, quindi è un altro step che permette di avere tipi più complicati e più espressivi e quindi in questo modo l'espressività del type system del linguaggio non è così terribile, dopo ovviamente richiede molto esercizio e sicuramente diventa anche molto verboso dal punto di vista del codice, perché in qualche modo bisogna avere la pazienza di annotare tutte le cose che si scrivono con il tipo che vuoi che quella cosa sia.Quindi la developer experience non è così magnifica in PHP, però è per dire che se uno vuole fare le cose in questo modo si può farle, non è il linguaggio, nel senso se dovessi scegliere un linguaggio per fare le cose in questo modo, non sceglierai PHP, ma lavorando in PHP, per aziende in cui PHP è un asset imprescindibile, è possibile e il risultato non è brutto, il risultato anzi è codice a mio parere è codice di ottima qualità.tra l'altro e ti permette anche di eliminare tantissimi test unitari perché il controllo sui tipi poi alla fine ti alleggerisce di una marea di check che in realtà faresti in ambito di test no? sì assolutamente perché deleghi molta conoscenza a quello che è il compilatore quindi è il io lo chiamo compilatore, poi non è effettivamente un compilatore, ma io lo vedo così.Deleghi a lui il fatto di controllare un sacco di cose, quindi se esprimi qualcosa a livello di type system, allora basta, sei tranquillo, l'hai espresso là, non c'è bisogno di scrivere un test per controllare che quella cosa faccia effettivamente quello che tu gli stai chiedendo, perché sai che hai qualcun altro che lo sta controllando per te.Ovviamente è necessario avere questo controllo in continuous integration o comunque farlo girare abbastanza spesso perché altrimenti crolla tutto.Però la cosa è decisamente fattibile.Domanda, perché non scrivo codici PHP da un pochino quindi in realtà sono un po' indietro.esiste per PSALM o PHP STAN qualcosa tipo un po' quello che si ha con Visual Studio Code e TypeScript legato più all'editor che avvia dei check per cui anche in fase di scrittura del codice che ne so c'è un sistema nell'editor che ti permette quasi in real time di evidenziarti degli elementi? Allora, credo che ci sia parzialmente, so che a phpStorm deve avere implementato recentemente, quindi non so neanche se sia già stato rilasciato o se sarà una cosa rilasciata nella prossima una versione, un'integrazione per capire i tipi di Psalm.Quindi in questo modo, quando ci sarà, che potrebbe esserci già, però io non ne sono sicuro della cosa, comunque dopo dovrebbe esserci un plugin di PHPStorm per permettere all'IDE di capire le annotazioni con i tipi.A quel punto tutte quelle cose diventano controlli che l'IDE riesce a fare in qualche modo in automatico, cioè come sei capace di integrare l'Inter nell'IDE, a questo punto puoi integrare anche i controlli di analisi statica l'idea ed è proprio l'idea a segnalarti con, non so, te li sottolinei in rosso o cose del genere con input grafici il fatto che appunto il tool di analisi statica ha trovato qualcosa da sistemare.Sì, giocando e scrivendo codice in TypeScript è una cosa che ho trovato particolarmente utile, proprio questo feedback in real time.L'idea alla fine di avere un compilatore è quella, si vede sempre di più nell'ambito della programmazione funzionale dove lo studio è proprio nel fare compilatori sempre più avanzati è proprio quella di tendere verso compilatori con cui proprio dialogare nel senso che tu scrivi del codice, il compilatore ti dice qualcosa, tu dai nuove informazioni al compilatore, il compilatore a sua volta ti ritorna una domanda, nel senso che ti dice non riesco a capire questa cosa, tu fornisci nuove informazioni e si va avanti così diciamo creando proprio un dialogo tra lo sviluppatore e il compilatore.Rimaniamo sempre per un attimo sul php e ho visto che nel tuo github, perché ho fatto i compiti a casa, sono andato un po' a spulciare in giro in modalità 007, ho visto che qualche giorno fa lavoravi a un repo che si chiama "Lamphp.da".Ci vuoi raccontare un po' di cosa si tratta? Si, volentieri, è una libreria altamente sperimentale per il momento, su cui sto lavorando un po' a tempo perso, è semplicemente una libreria PHP che si propone di implementare alcune strutture dati funzionali, tornando alle parole di prima puntori e monadi, i più più classici per renderli utilizzabili nel mondo PHP, il disclaimer è che ci sono già librerie nel mondo PHP che fanno cose del genere, il differenziatore che vorrei dare alla mia libreria è di farla in modo che sia fortemente tipata, ci sono già librerie che danno un API simile a quella che vorrei proporre io, ma secondo me il difetto è che non essendo fortemente tipate, ti permettono ancora di scrivere codice che non dovrebbe essere valido, cioè codice che fatto girare a runtime fallisce, in genere un fatal error cose del genere.L'obiettivo che avrei io è quello di scrivere codice che una volta che Salma in questo caso ti dice che non ci sono errori, poi a runtime sei tranquillo che quel codice funziona.L: anche di questo mettiamo per quelli più coraggiosi che vogliono spulciare il link note degli episodi abbiamo parlato ripetutamente di Psalm e PHP Stan dalla tua esperienza che differenze ci sono tra questi due tool? quale preferisci e perché? Allora, non so darti una risposta analitica della cosa, dicendoti "si differenziano in questo, in questo, uno è meglio in questo, uno è meglio in quello", so solo che durante l'uso, lo sviluppo di un'altra libreria su cui ho lavorato, li ho usati entrambi, perché ho detto "sono due tool separati, perché sceglierne uno o l'altro? Si possono tranquillamente usare tutti e due insieme".E quindi in questo modo è venuto naturale alla fine fare un confronto di come funzionano i due tool e al tempo mi sono trovato meglio, nell'esperienza finale, quello che la libreria riusciva a capire del mio codice, ha funzionato meglio Psalm.Per la mia esperienza mi sono trovato meglio Psalm, ma è una cosa assolutamente soggettiva, non voglio dire che Psalm è meglio di PHPStan.Altra cosa che credo è che in linea di massima PHPStan sia più integrato con i framework e con le librerie tipo Doctrine, altri strumenti.Quindi per un progetto più standard, che usa molti tool di framework e di librerie assodate nel mondo PHP, in linea di massima è più facile integrare PHPStan, mentre Psalma è più un qualcosa che quello che ho visto io è più facile usare per codice ad hoc.Una cosa che non sono sicuro, che al tempo avevo notato, che mi facilitava di molto il lavoro, è che se a un certo punto ti capita di arrivare in un punto del codice dove tu sviluppatore ne sai di più del tool e quindi vuoi dire al tool "no, questa cosa non è è sbagliata, ho ragione io, credimi".Era molto più facile dire questa cosa in PSALM semplicemente mettendo una notazione in linea, dicendo "PSALM suppress il nome dell'errore", piuttosto che in PHP STAN dove l'eccezione intesa, devi dire che non controlli quella cosa lì, andava inserita in un file XML che ti sta nella root del codice con una particolare sentarsi usando un'espressione regolare.Era un po' più complicato, non so se adesso anche PHPStand, so che volevano farlo, abbia un meccanismo simile, quindi potrebbe essere che in questa cosa adesso si equivalgano i due sistemi.Io in realtà non ho grosse esperienze in merito, quindi non ho molto da aggiungere.Però sì, se posso aggiungere per chi vuole provarli, direi installateli entrambi e fatevi un'idea per conto vostro.A un certo punto, quando vi rendete che uno dei due tool vi dà più rotture di scatole che valore, allora lo togliete.questo è assolutamente una cosa intelligente anche perché in quel caso si matura un'esperienza un po' più completa domanda da questo punto di vista quando sentiamo parlare di programmazione funzionale spesso si sente parlare anche di programmazione più utile o utilissima in contesti dove appunto si parla di calcolo parallelo e di queste cosine qua perché spesso si fa questo tipo di associazione? In linea di massima il motivo è perché in programmazione funzionale i side effects sono vietati e i side effects in programmazione parallela sono in linea di massima una cosa che tendono molto a mangiarti, a morderti nel sedere, soprattutto se sono operazioni che magari agiscono su uno stato condiviso, il fatto di lanciarle in parallelo rischia veramente di far saltare il banco, visto che in programmazione funzionale tutte queste cose sono in linea di massima vietate, dove con vietate non voglio dire che non si possono fare in programmazione funzionale, voglio dire che in programmazione funzionale uno deve renderle esplicite, renderle esplicite vuol dire dichiararle a livello di tipi e quando sono dichiarate a livello di tipi vuol dire avere l'accortezza dopo per far funzionare delle cose uno è costretto a gestire queste casistiche, quindi è possibilissimo in ASCII scrivere codice parallelo su uno stato mutabile, però esistono librerie che praticamente prendono tecniche dallo sviluppo della programmazione di database dove le operazioni transazionali sono un elemento di base e lo portano nella programmazione normale, quindi ci sono librerie che si chiamano State Transactional Management, che permettono di in programmazione parallela e concorrente rendere l'accesso allo Stato un'operazione transazionale, quindi ci si può accedere anche da più thread concorrenti, ma essere sicuri che solo uno alla volta andrà ad accedere a quello stato e quindi questo ci permette di sapere che non ci saranno conflitti, non ci saranno deadlock o comunque se queste cose possono succedere, vengono rese esplicite a livello di type system e quindi devono poi essere gestite.Quindi questo porta lo sviluppatore a essere costretto a gestire anche tutti i casi limite che poi alla fine sono quelli che ci portano a creare bug, perché l'happy path di solito lo sviluppatore riesce a svilupparlo abbastanza tranquillamente.Sono tutti i case limit e tutti gli very unhappy paths che sono quelli che spesso ci dimentichiamo di gestire, di non fare il catch delle eccezioni, di tutte queste cose che diciamo "ma sì, quando mai succederà che quel servizio non mi risponde, che non mi risponde il database.Voi marchia sempre dietro l'angolo.Esatto, poi capita e dobbiamo gestirci la cosa.La programmazione funzionale ci aiuta a pensare a queste cose a priori.Quindi side effect sì, ma se te ne prendi la responsabilità, dovendolo riassumere in modo brutale.intanto ti inizio a ringraziare per averci in qualche modo accompagnato in questo esperimento.Ti faccio le ultime due domandine che sono comunque un po' meno tecniche.Per chi dovesse iniziare la programmazione funzionale, è meglio un linguaggio di programmazione funzionale puro come può essere ASCEL che sembra davvero un pochino esoterico o un linguaggio un po' più lasco che ti permette anche di giocare con gli oggetti faccio un esempio, uno scala della situazione questa è la prima parte, lo dico perché in realtà la prima volta che io ho visto Haskell ho chiuso la finestra del browser terrorizzato perché la pendenza della curva d'apprendimento mi sembrava molto molto lipida.Tu cosa consigli dalla tua esperienza? Allora, secondo me, per imparare programmazione funzionale, io consiglierei di cercare almeno all'inizio di tagliare un po' i ponti con la programmazione oggetti.Quindi il mio consiglio personale è di non andare in linguaggi tipo scala che si permettono di fare in qualche modo un po' di confusione.Io sarei più per consigliare linguaggi funzionali semplici, tipo helm, che è un linguaggio pensato per essere un linguaggio puramente funzionale, fortemente tipato, ma senza un sacco di complicazioni che poi emergono in linguaggi più avanzati tipo Haskell e che è anche pensato per essere relativamente facilmente approcciabile, quindi anche la documentazione e i tutorial di Elma sono indirizzati ad un pubblico generalmente diverso rispetto al pubblico che ha Haskell, quindi mentre Elma è pensato per essere un linguaggio indirizzato soprattutto a programmatori JavaScript, ma a programmatori web che vogliono fare e lavorare nel web, ASCQL spesso cade molto nella vera documentazione che assume la conoscenza di concetti matematici, quindi è un po' più ostico da digerire.però la cosa che blocca di più, secondo me, per un approccio come quello che sto suggerendo, è la forte differenza nella sintassi.Perché la facilità di passare a procurazione funzionale attraverso scala, secondo me, passa dal fatto che la sintassi, alla fine, si continua a scrivere qualcosa, che sono classi, che sono oggetti, e quindi si continua ad avere questo sentore di programmazione oggetti anche se si introducono concetti tipo immutabilità, sum type, union type e cose del genere che poi aiutano quando si arriva a programmazione funzionale.Dall'altro la difficoltà di passare a linguaggi tipo ELM è appunto quella che la sintesi è completamente diversa, perché la sintassi di Elm è praticamente quella di Haskell, quindi c'è questa forte difficoltà all'inizio, però imparare una nuova sintassi non è una cosa così impegnativa.Magari è lo shifting di paradigma quello più...Però sì, seguendo il tutorial, leggendo, provando a scrivere un po', nel senso, secondo me Elma è una cosa che nel giro di una settimana, qualche oretta al giorno, uno inizia a entrare nell'ordine delle idee.Quindi se uno ha voglia di iniziare a provare programmazione funzionale, sa che a un attimo quello scoglio della syntax, se la mette via, se all'inizio il compilatore gli dà degli errori che lui non si aspettava, perché magari ha messo la parentesi nel posto sbagliato o cose del genere, però passato questo primo scoglio, dopo è abbastanza un navigare più tranquillo rispetto a secondo me appunto il paragone con Scala dove lo scoglio della sintassi non c'è, però proprio secondo me perché questa sintassi ti permette di fare molto simili a quelle che hai sempre fatto prima, fai molta più fatica a staccarti da quello che è il modo standard di fare le cose.Ovviamente a ciascuno il suo.Questa è la mia esperienza.Ognuno la può vivere in maniera completamente diversa.Noi comunque facciamo del tuo consiglio oro e ti ringraziamo per questo.Marco, io ti ringrazio a nome degli ascoltatori di Gitbar e a nome mio naturalmente.Grazie mille a voi.Ci prendiamo qualche istante per ricordare i tuoi contatti e so che sei attivo anche nel mondo delle community quindi se ti fa piacere anche dare qualche indicazione perché per noi è molto importante comunque dare delle indicazioni e spingere gli ascoltatori a partecipare attivamente al mondo delle community perché diciamo che è uno di quegli strumenti che si trasforma in un acceleratore di competenze che nella nostra professione è comunque molto importante.Assolutamente per questo ti ringrazio dello spunto, io sono un organizzatore di uno user group qui di Treviso che si chiama MAG che sta per marca user group e che è uno user group non focalizzato su una specifica tecnologia che si ritrovava, intendo perché ultimamente non era possibile farlo e quindi ci siamo trovati virtualmente, più o meno una volta al mese, qui in zona Treviso con Talk da parte di vari partecipanti, ma anche di ospiti che viaggiano un po' per venire da noi.Un'altra cosa che mi viene voglia di dire è che purtroppo non ce l'abbiamo fatta quest'anno, sempre a causa del coronavirus, ma con degli amici era venuta forte la voglia e avevamo iniziato a lavorarci per organizzare una conferenza di programmazione funzionale in Italia e quindi mi viene da dire stay tuned e speriamo che il 2021 sia l'anno buono per farla.Allora noi lasciamo i nostri microfoni aperti in modo da quando avrete modo di realizzare questo incontro regalarvi i nostri microfoni per appunto condividerlo anche con la nostra per quanto piccola comunque comunità.Per quanto riguarda invece i tuoi contatti Marco dove ti possono trovare? Allora, beh, principalmente i posti dove è più facile trovarmi, oltre che a casa mia, sono su Twitter dove sono @marcoshuttle oppure su github dove sono marcosh e direi che sì.Ah, ho un blog che è markosh.github.com dove ogni tanto senza assolutamente nessuna cadenza regolare scrivo un po' le idee che mi vengono in mente e delle cose che interessano quindi se volete darci un occhio sono molto contento di interagire se qualcuno ha domande, curiosità o critiche di qualunque tipo.Tra l'altro ci tengo ad aggiungere che proprio questo pomeriggio ho letto un bellissimo articolo sulla qualità del codice nel tuo blog e quindi tutti i tuoi contatti andranno a finire nelle note dell'episodio.io non so come ringraziarti per averci dedicato questa oretta qua su Geekbar grazie davvero grazie mille a voi è stato un grande piacere alla fine a me parlare di programmazione funzionale piace un sacco quindi averla potuto fare con voi è stato un grande piacere allora facciamo così quando capitiamo in veneto o se capiterai tu in zona Lione o Sardegna o l'Urbia d'estate forse più probabile là ti dobbiamo una pizza e una birra grazie mille Grazie di nuovo era Marco che ci ha dato una mano per esplorare il mondo della programmazione funzionale Vi ricordo i nostri contatti prima di lasciarvi visto che la settimana scorsa li ho dimenticati potete trovarci su www.gitbar.it per qualunque motivo potete scriverci un'e-mail a info@gitbar.it @brainrepo su Twitter.La chiacchierata con Marco mi ha aiutato tantissimo anche personalmente visto che ho sempre la curiosità di esplorare la programmazione funzionale quindi non ditelo a lui ma mi riservo il diritto di rirompergli le scatole magari su Twitter.Lo so che mi stai ascoltando Marco.No no tranquillo.detto questo io vi ricordo che potete iscrivervi nel podcast utilizzando il vostro client preferito e perché no se vi va lasciate pure una recensione noi ci rincontriamo la prossima settimana con un nuovo argomento nella cassetta degli attrezzi dei full stack developer GIT BAR il circolo dei full stack developer una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web, di metodologie e degli strumenti immancabili nella cassetta degli attrezzi dei Full Stack Dev.[MUSICA]
