Bene e benvenuti su Geekbar, nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori Sono stanco, si vede? Ah non mi vedete è vero, scusatemi, ma sono veramente stanco Anche se per questo tipo di episodi l'energia la trovo sempre, anche perché, ripetuto due volte, ci sta benissimo abbiamo un super ospite oggi ma prima di introdurlo è il momento di salutare i miei compari di viaggio Carmine e Luca ciao ragazzi ciao a tutti ciao a tutti ciao ma questa settimana bellissimo viaggio insieme anch'io vedo voi freschissimi proprio mamma che freschezza ragazzi sembrava fresco e è super eccitato di star qui era da tanto che non stavo no? No un paio di puntate? Un paio di puntate, un paio di puntate.Freschezza nel senso di freddo perché effettivamente adesso ho freddo e sono pigro per prendere una felpa un'ero freddo di caldo.De fatti stavo dicendo sta in mani che corpe.Ho un freddo cane ma non fa niente.Sono troppo pigro per alzarmi.Vabbè rimani con noi ti scalderemo con gli argomenti interessanti di oggi e anche provocanti quindi sono sicuro che appena parte il flame gli animi si scaldano e possiamo iniziare.Detto questo il mio compito un po' noioso come sempre quello di ricordarvi i nostri contatti info@gitbar.it e @brainrepo su Twitter sono i modi canonici ma anche che non usa nessuno per contattarci.In realtà l'unico vero punto cardine del nostro podcast è il gruppo Telegram quindi se non vi siete...potete cercarlo, cerca bit.ly su vostro client di telegram preferito e mi raccomando iscrivetevi perché non è come tutti gli altri gruppi, questo lo diciamo sempre che è a stesco a stesco, Italia dove si discute animatamente, ma è un gruppo dove si discute animatamente lo stesso ma ha un logo più quello degli altri vi aspettiamo questo è bellissimo, pensavo dicessi ma non si parla di RAL No, non si parla mai di RAL, si parla di retribuzione annuale orda.Non ho smesso di utilizzare l'appreviazione perché potrebbe risondere.Ora schiaccio per intero, per esteso.Benvenuti su Gitbar, il podcast dedicato al mondo dei fullstack developer.I mezzo artigiani, i mezzo artisti, che ogni giorno infilano le mani nel fango nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.Detto questo io credo che sia arrivato il momento di presentare l'ospite.Abbiamo con noi Michele Riva, speaker, autore di testi tecnici.Devre...cosa tutto sei, Michele? Ciao a tutti.Cosa sono? Un mischione? Un calderone? Non lo so.Diciamo che sono uno che si annoia facilmente.Diciamolo così.È facile annoiarsi.Benissimo, allora ho già subito la prima domanda.In un mondo come il nostro, che si evolve rapidamente, però che allo stesso tempo ha bisogno di costanza nel poter raggiungere gli obiettivi, come fai a stabilire il trade-off di "studio qualcosa e scendo fino in fondo e mi annoio in fretta"? Il fatto è che soprattutto quando scopri qualcosa di nuovo tutto il resto inizia ad annoiarti per cui non esiste un vero e proprio trade off, ovvero scopro la cosa nuova che voglio studiare, tutto il resto inizia ad annoiarmi e mi dedico a quella, poi scopro la cosa dopo ed è un circolo vizioso.Quindi grandi vantaggi da una parte e svantaggi enormi dall'altra perché approfondisci poco sostanzialmente o approfondisci abbastanza per poi magari fare qualche conferenza, scrivere qualche articolo o fare quello che ti piace.Sì, io ho sempre trovato difficile tenere il focus su un'unica cosa, non so se è comune questa cosa, nel senso che inizio il mio deep dive e poi cerco per un certo periodo di tenere alla larga tutti gli altri stimoli che bussano alla porta, ce ne sono veramente tanti, e Per far questo utilizzo una serie di tecniche, un esempio è quando approfondisco io svuoto completamente Feedly e seguo solo una serie di feed limitati solo su quel topic in modo da non avere altri tipi di conferenze.Hai delle tecniche tu per tenere il focus? Mi piacerebbe dirti di sì, la realtà è che faccio veramente fatica.Ho la fortuna quantomeno in orario lavorativo di riuscire a tenere il focus con le mie otto ore al giorno, ma finite quelle otto ore dove la motivazione è diversa da quella lavorativa.Dal punto di vista lavorativo dici "ok, otto ore in cui devo avere questo focus, punto, non esiste nient'altro" e la motivazione è "sennò mi licenziano", giustamente anche voglio dire, qui devo farlo, ma quando le cose le fai per piacere allora diciamo che non senti neanche più quell'obbligo e ti perdi via e quindi non ho purtroppo proprio nessuna risposta in questo momento per quanto riguarda il tempo libero ecco.Giro la domanda anche a Carmine e a Luca se hanno delle tecniche strategie? No, io vivo in un perenne stato d'ansia dove voglio fare tutto e non faccio niente, quindi sostanzialmente non ho nessuna tecnica.Diciamo che io in realtà faccio il contrario, nel senso che prima di andare di deep dive ci giro intorno la cosa, come se fosse una specie di vortice, quindi magari non so, se voglio approfondire una tecnologia, una libreria, qualunque cosa, comincio ad utilizzarla in maniera anche abbastanza scimmisca senza conoscere niente.Quindi comincio effettivamente a fare cose, fare cose, fare cose e man mano che incontro un ostacolo poi approfondisco.Quindi una specie di spirale che va sempre più in giù.Insomma, diciamo, non ho mai avuto la costanza di dire "voglio andare deep dive in una cosa e vederla bottom up".Non ho mai avuto quella costanza lì.L'ho sempre visto delle cose top down, probabilmente anche sbagliando.Infatti ci metto molto più più tempo, però non riesco a fare questo deep dive per poi risalire su, è sempre una spirale insomma.In realtà sì, secondo me la differenza è che durante le ottore lavorative sai cosa fare o perlomeno c'è scritto in un posto qualcuno ti dice cosa fare, quindi probabilmente ti responsabilizza anche dal dover cercare di rimanere concentrato.Qua bisogna anche definire un po' quanto in fondo, cioè qual è la definizione di andare in fondo.Per me una settimana in fondo è già troppo.Tendenzialmente anch'io come Carmine vado lì, faccio la classica PPT, cioè la programmazione per tentativi, faccio attacco brut force a quello che voglio studiare finché non fa forse qualcosa che mi prefissavo di fare e poi se proprio la cosa mi piace vedo anche perché funziona.In questo modo sono appagato dal fatto che ho fatto qualcosa che funziona, forse, e poi appagato dal fatto di aver capito perché funziona, dopodiché basta.Però devo dire che quando una cosa mi prende non ho bisogno di aiuti perché ho i miei paraocchi naturali.Io solitamente sono per il learn by doing come come voi però devo dire che ho avuto un'esperienza particolare con React.Con React invece ho utilizzato la tecnica inversa.Io venivo da angular da view quindi un po di background di come funziona un framework front-end ce l'avevo di cosa fosse la reattività alcune cosine le conoscevo però sappiamo che un po react si allontana da quelli che sono i paradigmi che vedevamo parlo di diversi anni fa quindi vedevamo su view e vedevamo su angular per cui con react invece mi son letto prima tutta la documentazione ancora prima di scrivere la prima riga.Ragazzi io secondo me ho ottimizzato il tempo a livelli assurdi però devo dire che avevo uno stimolo importante nel farlo nel senso che dovevo preparare un corso quindi dovevo tenere un corso su qualcosa che non conoscevo che è una cosa comune per molti di noi nel senso che devi preparare un corso ti studi l'argomento per poi insegnarlo scendi in profondità per farlo io così ho fatto e devo dire che poi quando mi sono messo diversi anni fa a programmare in react ho trovato tutto molto più fluido tutto senza attrito.Questa è stata la sensazione.Però su React penso che se non segui delle linee guida a un certo punto ti vai a schiantare proprio di faccia contro un muro.Per cui probabilmente anche questo.Ci sono certe cose in generale su cui fai molta fatica a dire "vado a caso che prima o poi qualcosa funziona e React secondo me ci sono dei motivi per cui ti pone questo problema ed è magari il motivo per cui personalmente ad esempio ho seguito lo stesso identico approccio di cui hai parlato tu giustamente magari con ASCAL o con ReasonML, con quei tipi di linguaggi dove non esiste il provo finché non funziona, cioè lì devi sapere esattamente cosa devi scrivere perché sennò non è come fare matematica, cioè non è che puoi dire trovo un brute per trovare tutti i numeri che più uno fanno cinque.No, uno, due, tre, quattro.Nel senso, è matematica, devi saperla e basta, non vai di tentativi.Ecco, il React, secondo me, da un certo punto di vista, porta con sé questo tipo di approccio, ti forza ad adottare questo tipo di approccio in molti casi.Sì, io mi scusate, mi ero dimenticato la postilla "don't tra i disatomi perché quello che faccio io è assolutamente sbagliato, però appunto è un metodo per mantenere viva l'attenzione, ovviamente in alcuni contesti, in alcuni ambiti, non puoi farlo con la matematica, però con la fisica la puoi fare.Allora è il metodo che uso io, adesso non voglio dire di non usarlo mai, dico solo che ci sono dei casi in cui diventa estremamente complesso giungere a conclusioni.Poi, se devo studiarmi Kotlin, per dire, ad esempio, in quel caso magari un po' a casaccio posso anche permettermi di andare, prima o poi qualcosa funziona.Però se lo devo fare in Agda, in Haskell, no, lì non compila.In Rust, no.Allora è un pochino diverso, chiaramente.Poi, ripeto, sono il primo a fare brute force finché le cose non funzionano, è chiaro.Secondo me dipende anche tanto dalla cosa a cui ti vuoi approcciare e se conosci già l'ambito.Ad esempio, se una persona fa Vue e vuole imparare React, ci sono alcuni concetti basi che comunque conosce.Nel senso che si tratta di cambiare un po' il paradigma della programmazione con quello però ci sono comunque cose che restano lì.Insomma, i fondamenti non hai bisogno di andare a riprenderti.La stessa cosa magari faccio Java e voglio fare Kotlin, oppure magari ho sempre utilizzato Express, voglio utilizzare Fastify.Comunque, quando si cambia di tecnologia o di linguaggio nello stesso ambito, probabilmente è più semplice.Insomma, concordo con te che con Rison non si può fare.Io avevo, insomma, qui nella mia mente, dell'infarinatura di O'Camello dall'università, ma quando ho fatto un po' di Reason, avevo totalmente dimenticato tutto.Ho dovuto ricominciare da zero, insomma, non si poteva fare a tentativi.Però, secondo me, è importante riuscirsi a porsi degli obiettivi realistici.Almeno a me è quella la cosa che mi fa continuare.non riesco a dirgli "io voglio imparare questa cosa qui bene".Immagino che ognuno di noi ha magari quei pet project che ripete con ogni tecnologia nuova perché non deve riflettere sul dominio, sulla funzionalità, ma sa che quella cosa lì la fa con x strumenti diversi così può concentrarsi sullo strumento.Quali sono i costi? Io ho l'herp per il frigo, che è un fetish molto molto particolare.C'è questo progetto open che si chiama Grozi che è l'herp gestionale per il frigo.È un fetish veramente molto astrango, tipo rifaccio quella cosa in tecnologie diverse.Io ho usato con Golang il Condition Builder che è una cosa proprio semplice e semplice una cosa proprio semplice, semplice, semplice che con catena stringhe, quindi più semplice di così non si può.In realtà ne ho anche un altro più complicato, però qua è perché per tanti anni ho lavorato nel turismo e allora faccio quello.Faccio un client per Alpenbiz, che è uno standard, un protocollo che abbiamo inventato qui in Alto Adige per mandare in giro informazioni.Siccome quello è tanto tanto tanto semplice ma anche tanto tanto tanto bastardo su alcune cose, mi permette di esplorare gli anfratti dei vari framework, dei vari linguaggi che stavo sperimentando.Siccome per quel protocollo lo so a memoria perché lo standard l'abbiamo fatto noi, è una cosa abbastanza complicata ma alla fine non devo pensare a niente, mi posso concentrare soltanto sul linguaggio e su come viene implementato eventualmente protocolli HTTP e quant'altro.Questi sono i miei due.Io invece ho una serie di tool per la gestione del podcast, dalla scrittura dei capitoli nell'MP3 al boilerplate che mi serve per lanciare i servizi AWS per il test to speech, alla creazione delle copertine che ho fatto con Python poi l'ho fatta con JavaScript con un pezzettino di Python poi ho sostituito un pezzettino di Python con un modulino in WebAssembly che faceva delle robe sulle...quello è un po' il dominio dove giocare.Sulla generazione delle immagini tieni la mente perché dopo ti dico una cosa però prima rispondo un attimo anche alla domanda sul mio toy, diciamo il mio giocattolino per imparare.Nel mio caso è una roba, concordo con Luca, semplicissima ma molto bastarda su certe cose ed è un piccolo motore di ricerca full text in memory perché ti obbliga a studiare una serie di algoritmi fondamentali chiaramente, a capire come gestire la memoria e se vuoi iniziare a pensare la distribuzione anche, chiaramente, come distribuire il carico su più nodi, come sincronizzare, per cui come implementare i cap theorem o altre serie di, so, anche banalmente protocolli per comunicare, eccetera.Ed è semplicissimo, perché alla base è veramente semplice, poi se il linguaggio non lo conosci diventa estremamente bastardo, perché magari in quel linguaggio in particolare non è così facile fare questo tipo di applicazioni.Mi ricorda la scrittura sui metadati dell'mp3.In javascript c'è una libreria che è una cosa semplicissima, in php già devi lacrimare sangue.A prescindere.Un altro! Lasciate stare il php.Però volevo dirti, per la generazione delle immagini, se vuoi divertirti e aprirmi qualche issue, c'è un bellissimo repository chiamato GoGen che ti permette di creare immagini a runtime.L'avevo fatto per le, come si chiama, gli open graph image degli articoli su internet, no? E a runtime generi delle immagini utilizzando React, Vue o HTML, decidi tu.Ed è scritto in Go e sostanzialmente ti renderizza l'HTML o il React eccetera e ti ritorna proprio l'immagine in formato JPEG.Domanda, questa è una curiosità perché ho fatto una cosa simile per le copertine del podcast.Cosa utilizzi per renderizzare? C'hai un webkit magico che ti fa il lavoro sporco? Sì, uso Chrome DP che è Chrome Developer Protocol.Si chiama proprio Chrome DP la libreria Go che si occupa di fare lo screenshot sostanzialmente.Per cui io ho del look, posso stare in ascolto, capire quando il virtual DOM è pronto, in quel momento faccio lo screenshot e ti permetto comunque di settare...c'è un file, uno Yaml di configurazione in cui dice ok, per questo template, perché alla fine poi comunque devi usare un template, imposta questo caching header in modo che non ogni volta devi colpire il server ma utilizzi la cache ovviamente.certo interessante generare immagini con react è una cosa che ormai sta diventando sempre più comune io non ci credevo invece l'ho vista in tante in tante realtà sarà un po che ci siamo rotti le scatole delle classiche librerie di generazione immagini che forse devono un po svecchiarsi c'è dello spazio per rinnovare.Secondo me c'è anche gente che disegna su figma c'è il plugin che ti esporta react e ce l'hai lì non devi pensarci più di tanto metti dei placeholder se tranquillo basta guarda io ti posso dire sullo script delle copertine vabbè non so se hai avuto modo di vederle c'è una cosa intanto le copertine sono tipo responsive avrei voluto farlo con figma qual era il problema che le copertine sono responsive ma l'angolo arrotondato deve essere calcolato in funzione della dimensione.Quindi c'è una maschera svg sull'immagine che disegna quella specie di parallelepipedo con gli angoli arrotondati calcolandosi la stondatura.È stato un viaggio che non vi dico ragazzi, tipo tre giorni per cercare di capire come fare.In realtà secondo me questa cosa è anche per immagini ma anche per i PDF, nel senso che mi sta capitando in questi giorni che devo girare dei PDF e non mi è saltato in mente di utilizzare PDF kit similari, ma nemmeno per il momento.Ho fatto una pagina web CSS print e pappeteo, ma non esiste, cioè se devo pensare a fare il PDF a mano con la libreria, il margine, il pixel, impazzisco.Secondo me usare questo approccio qui è infinitamente più semplice insomma.E magari ti viene anche più creativo, credo, cioè quello che puoi fare con HTML, CSS, JavaScript, sicuramente farlo con una libreria, fare il pdf a mano, insomma, è abbastanza arcordo.Ha stato il mio lavoro di un anno, per fare una libreria che però è di proprietà dell'azienda, quindi non l'ho potuta rilasciare, però è stato un bagno di sangue, perché si vuole il pixel, si vuole il punto nel pdf esattamente lì.Quella precisione non riuscivo ad ottenerla con i vari pdf kit, webkit, cose varie, la dovevo generare a mano.Fine parentesi triste.No, io voglio aggiungere una cosa che in realtà questo mondo si sta comunque evolvendo.Per il podcast stavo guardando una serie di tool e ho scoperto che c'è un'applicazione, non so non saprei neanche come chiamarla, che utilizza React, ma la cosa figa è che utilizza Spring che è una libreria di animazioni per react.Madonna hai detto spring mi è venuto in mente spring boot? No no no.Avrei detto Vadin.No dicevo c'è Spring Animation adesso non ricordo precisamente so che c'è Spring come nome e cosa fa questa questa questa questa applicazione che tra l'altro è open source molto interessante da guardare il sorgente ti permette di fare dei componenti react che puoi animare in modo utilizzando appunto questa libreria e cosa fa poi un tool node che gira quando gli dici renderizza ti crea il video è la cosa è molto molto figa io diciamo che avevo dei tentativi abortiti perché devi gestire il frame rate devi devi tenere in conto tante cose però alla fine è veramente veramente bella.Tanto per dire che secondo me in qualche modo la butto grossa però React sta diventando quasi una lingua franca al di là del framework.Non lo so, ho questa sensazione.Sta diventando una lingua franca poi ne possiamo discutere ma proprio perché non è un framework forse.E questa è la grande differenza tra Vue e Angular nel senso che ricollegandoci a quello che dicevate prima perché con Angular magari posso permettermi di andare un pochino a caso perché sono a minima conoscenza di come funzionano i framework.Angular non è un gran problema, c'è la parte di reactivity che per carità non è semplice ma una volta superato quello scoglio è facile.React invece ha la composizione dei componenti, la gestione dello stato, insomma adesso i function component con e lì se non capisci cos'è la function composition, diventa molto difficile capire com'è che un context che sta così in alto riesce a raggiungere un componente così in basso.E senza capire appunto function composition, il carrying degli arguments, senza capire una serie di topic che ci stanno dietro, andare a tentativi diventa molto, molto, molto difficile.Cosa che in Vue e in Angular non è un problema, che lo ostrai per te.Sì, in Angular sì.In Vue, secondo me, puoi utilizzarlo come UI library alla React, insomma.Nel senso, ora io utilizzo entrambi.Quello che trovo molto molto guidato, invece, è effettivamente Angular.Nel senso, io non ho mai visto un caso tutorial in cui Angular è la UI library.Angular è il framework per la single page application.che per carità nel 90% dei casi va comunque bene.Io non lo userei, ma c'è il suo perché, nel senso ho un team di persone che fanno back-end, li voglio far fare front-end, Angular ha il control, il service, la dependency injection, e finita la festa.Invece comunque, Vue 2 è molto più vicino ad Angular.Vue 3 vuole fare un po' React con la composition API, invece far entrare una persona nel mondo React è veramente difficile.Nel senso, a me, quello che di solito mi piace, dicono "come flame", che non ho capito nulla, è che non puoi utilizzare React se non sai bene JavaScript, che è una cosa che ti puoi permettere se vuoi fare Angular.Non puoi fare React se non conosci bene JavaScript.un po' come quella diatriba tra chi conosce Ruby e chi conosce Rails, o magari tra chi conosce Python e chi conosce Django.Insomma, puoi permetterti di non conoscere bene il linguaggio, almeno per il caso d'uso medio, e di utilizzare direttamente il framework.Sono assolutamente d'accordo e non dirò che questo la dice lunga sulla qualità delle applicazioni angular, delle applicazioni rails, a parte le grandi applicazioni rails naturalmente.Github sta ancora in piedi per cui non parlerò di Github ma non dirò che la qualità media poi delle applicazioni angular o delle...cioè è esattamente quello che dici tu a un certo punto.Io ho un team di gente che frontend non lo vuole fare, gli do in mano, questi qua magari fanno java da vent'anni, gli do in mano angular, è ovvio il passo è molto più semplice, sono d'accordissimo, ma non aspettarti la qualità che puoi avere da uno che invece arriva in Angular e ti dice cavolo, no, io invece JavaScript lo conosco molto bene, conosco molto bene il front end e ti fa una roba spettacolare, sempre in Angular.Però è un problema che vedo soprattutto quando da consulente adesso non parlo di NearForm che è l'azienda dove lavoro adesso, ma in passato spesso mi è capitato di prendere in mano progetti iniziati proprio nella modalità in cui di cui parlavi e c'è si vede subito che non funziona.C'è da dire.Faccio una premessa giusto per evidenziare la cosa e insomma mettere le mani davanti prima di sparare la grossa.Sono completamente d'accordo con voi.E' uno dei motivi per cui adoro react e proprio per quello.C'è un però nel mio ultimo progetto come la community sa ahimè per me ho dovuto usare view.view3 con la composition api e adesso la mia domanda è questa cosa vale anche poi calata nel pragmatico con view3 perché vi faccio questa domanda perché con la composition api tutta la reattività di view3 te la devi gestire ci sono i ref tutta quella bella roba e quindi view 3 è ancora quel framework che ti guida nello sviluppo quindi che è perfetto per il team di avventurieri che non ha energie per coordinarsi o ha fatto il salto verso React con Vue 3? Io Vue ho smesso di usarlo purtroppo invece a me piaceva però ho smesso quattro anni fa quindi sai che ho paura di essere rimasto su Vue 2 e ti devo dire la verità quando Vue 2 era il top in quel momento, cioè, come dire, era il massimo dello sviluppo di Vue, perché poi hanno iniziato a sviluppare Vue 3 e è rimasto in maintenance mode.Però nel momento di picco di Vue 2, in quel momento che c'erano ancora i class components, in React, Vue era nettamente superiore, secondo me, come framework.Nel senso che è vero che ti guidava, è vero che non era una libreria e quindi si portava dietro una serie di cose in più, ma la velocità di sviluppo in Vue e la qualità che ti portava era una roba eccezionale.Poi, sinceramente, non posso confermarti che sia rimasto così perché non lo so.Però io ti dico che, secondo me, cinque anni fa, sei anni fa, era nettamente superiore a tutti.Però, ripeto, è la mia opinione, no? Che in quel momento lavoravo principalmente su quello.- Son d'accordo.- Vue 2 e Vue 3 tutti quanti i giorni.Vue 3 non è per lo sviluppatore Vue 2 medio.Vue 3 è molto più vicino a React.Vue 3 è molto più vicino a JavaScript.Diciamo così, ecco, rispetto a Vue 2.Vue 2 non dico che ti guida, però nel senso...per chi ha provato ad utilizzare il Vue 2 con TypeScript e i class component di Vue 2 è come scrivere Java, proprio con i decorator eccetera eccetera quindi quella cosa lì è molto vicina a quello che stiamo dicendo prima nonostante Vue 2 abbia un supporto per TypeScript che è penoso se non usare quella roba lì è veramente assurdo perché quello di Vue 3 è eccezionale Quello di Vue 3 è comunque, diciamo, secondo me un po' limitato rispetto a quello che ha, insomma, React che ha soprattutto Angular.Però è un grande passo in avanti rispetto a Vue 2.Cioè, Vue 2 ci sono tanti progetti in cui mi sono rifiutato di utilizzare TypeScript perché scrivere i componenti in quel modo che poi hai comunque Betur che per avere quell'aiuto nel leader devi comunque configurare diversamente, capiva bene TypeScript, eccetera, era uno scoglio in più.Però Vue 3 non è proprio sviluppatore Vue 2 medio.E secondo me, ecco la dico grossa, se devo utilizzare Vue 3, utilizzo React.Perché mai dovrei prendere un team nuovo e utilizzare Vue 3? Utilizza comunque React.Io vedo che la curva di apprendimento di Vue 3 e di React from scratch sia abbastanza simile, Ci sono alcuni concetti che sono veramente simili.Se ho bisogno che il team va veloce e deve martellare veloce, vai su Vue 2, che comunque ci sono tantissime librerie anche molto utilizzate che non sono passate a Vue 3 e non ci passeranno nel breve, perché cambiano tante cose.Nel senso, se dovessi avere il team che va veloce, e martella e vuole fare front-end con Eclipse, assolutamente, di due.Vuole fare front-end con Eclipse, è bellissimo.Però siamo tornati a parlare della grande guerra tra framework.No, no, no, no, no.Asiuso, Gekueri per riconoscenza.Assolutamente.Ma che poi in realtà alla fine, secondo me sono sempre corsi storici.Io mi ricordo che quando facevo Rails, qualche anno fa, e ci si mandava con la chiamata asincrona ai pezzi di HTML e di JavaScript che sostituivi con jQuery, e ti sentivi a metà tra il martello e il drago della programmazione, sono passati anni, HTML o Verwire in Rails fa una cosa molto simile, LiveView la fa simile ma non troppo, al senso alla fine sono comunque cose che riciclano fuori ogni X anni, quindi alla fine prima o poi ti ci tocca comunque metterle in mano.Sì, perché credo che tutto dipenda dal trade-off tecnologie innovative e produttività.Sì.specie in quel tessuto imprenditoriale medio piccolo.Un esempio di framework che certe volte viene difficile definire una cosa framework tool.Vabbè comunque un esempio di coso che secondo me si è posizionato bene da questo punto di vista è stato Next che in qualche modo ha cavalcato un po' quest'onda di nostalgia del full stack framework, però innovandola.Abbiamo colto bene il passaggio, anche perché tu Michele sei tipo il leader di Next.js dopo il tuo ultimo libro.Allora più che Next secondo questa roba la sta raccogliendo molto bene Blitz, se lo conosci, che è appunto un framework stile Rails che si basa su Next.Poi, giusto per citare l'ultima volta Rails, Rails è il framework più bello mai inventato, ha le sue magagne, ma è il primo grande amore che non si dimentica.Io non so cosa dire, mi si sta sciogliendo il cuore.E aggiungo che Ruby è il linguaggio più ergonomico e devero preferibile che ci sia.Eh, su questo poi ne possiamo parlare.Ne parleremo sicuramente perché...Allora, parli con uno che Ruby l'ha adorato, veramente.Veramente lo adoro da morire.Ha le sue...anche lì, le sue pecche.Però, tornando a Blitz, Next sicuramente è riuscito a capitalizzare sulla necessità del server-side rendering, che poi anche qua ne possiamo parlare quanto ne vogliamo, che secondo me è una roba completamente inutile, che bisogna evitare fino alla morte, e se volete approfondiamo.Dopodiché Blitz a sua volta dice, ok, sai che c'è la gente nostalgica di Rails, e ha ragione ad essere nostalgica, perché era un gran framework, Era tutto più semplice, era un bel monolite come piace a noi.Allora uso Blitz e basta.E uso comunque Next che invece mi risolve tutti i problemi che React mi ha causato.Ci sono tanti che stanno facendo delle belle scommesse su Blitz.Ma personalmente mi auguro anche che abbia un buon futuro, un buon seguito.Perché secondo me è interessante, poi non l'ho mai usato a dire la verità.Troppo.Con un po' di feedback in giro perché avendo scritto un libro su Next, A un certo punto, durante la scrittura, ho pensato "ma io devo continuare a scrivere di Next o devo buttarmi su Remix o su Blitz?" Per cui comunque un occhio su tutto quanto lo dovevo tenere in quel momento.Però sì, diciamo che Next secondo me sarà più Blitz, se se la gioca bene, se gioca bene le sue carte, da qui a qualche anno ha delle buone possibilità per me.Perché rispetto a Next dici Blitz? Perché Next ti porta a una serie di complessità che in qualche modo comunque devi smarcare.Nel senso, devo connettermi al database, cosa faccio? Uso l'API di Next? No, non è bellissimo per una serie di motivi, anche qui.Allora voglio crearmi i miei microservices.Anzi, no, scusa.Facciamo, se parliamo in ottica MVC, i microservices non esistono.Per cui, ok, mi creo il mio gateway REST da una parte che fa solo l'API.Poi voglio usare GraphQL perché ho tutti gli ottimi motivi di volerlo usare.Next può espormi API GraphQL, ma lasciamo stare.Allora devo prendermi Fastify con Mercurius e fare la roba di là, che va bene.Anzi, soluzione migliore in assoluto, per carità.Però te la devi fare.Next, qua la sparogrossa, va molto bene per quanto mi riguarda se vuoi fare dei siti istituzionali, siti vetrina, dei blog.se inizi ad avere delle applicazioni vere, se devi iscriverti a GitHub, lo fai in Rails, ancora oggi, non lo fai in Next, oppure te lo fai custom con il tuo Fastify, con React per il frontend, o meglio ancora, ti fai dei bei micro frontend per scalare bene a livello di team, ma non usi Next.Cioè se vuoi farti la vera applicazione complessa, e lo dico contro il mio interesse, nel senso se volete comprare il mio libro, spiego perché, ecco, fatemi ribaltare la frittata.Però non raggiungi grandissimi livelli di complessità con Next, anzi moltiplichi la complessità a un certo punto.Sì perché Next fa...una cosa comune è quella di vedere Next come full stack framework.In realtà lo mima, ma non lo è.Esatto, bravo.io nell'ultimo progetto che sto portando avanti ho avuto bisogno di un full stack framework react based devo ammetterlo non mi sono fidato di remix non ancora perché lo trovo ancora molto acerbo in tante cose per cui ho dovuto utilizzare next ma da là si è aperto un mondo perché prima cosa le routes di next te le devi fare custom e quindi mettici un bel fastify che ti serve next e ma caspita stai facendo girare fastify dove le faccio girare le api dentro lo stesso fastify che mi fa girare next va bene e next chiama quell'api per hanno forse ok forse devo disaccopiare la logica dell'API e chiamarle con get server side props ma...un livello di complessità...Hai ragionissima ma poi ti dico fare server side rendering di react costa troppo in termini di tempo di esecuzione proprio cioè scusa tempo di esecuzione potenza di calcolo richiesta quando inizia a scalare richiede troppo per come è fatto JSX non è un problema di next è il problema di di React, fare server side rendering, di JSX in particolare, è troppo costoso.E allora, anche lì, conviene fare server side rendering.Cosa faccio? Prendo dei server super corazzati perché sopra una certa soglia non riesco più a servire il mio traffico, allora vado serverless.Ogni richiesta è una lambda.Ok, vai a vedere quanto ti costa a fine mese fare una roba del genere.E allora torni sul server, però non riesci a scalarlo allora va ancora cane che si morde la coda.Però c'è da dire che il driver principale sono stati i template engine.Guardati con l'occhio di oggi, Nunjack e Ajs hanno la experience di un letto chiodato.Però dipende allora qua potremmo discuterne nel senso che per la metà delle applicazioni che facciamo oggi in genere ti basta i ERB ad esempio se parliamo di Ruby ti basta e come poi perché te lo dico perché se hai una parte davvero dinamica non ti serve la la SEO.Per cui quella parte piccolina dinamica della tua pagina te la fai in React.Tu fai il mounting del componente solo per quella parte lì.Se è dinamica usa React perché vuol dire che a Google non interessa niente la SEO di quella parte lì.Se è statica usa un template engine va benissimo.Guarda che io te lo assicuro per esperienza diretta ci stiamo complicando la vita solo per il piacere di usare React.Sempre sempre.Ogni volta che usiamo next e react diciamo dobbiamo pensare ma ne ho bisogno ma anche per il mio sito personale cioè dico ogni volta che devo fare un update dico ma cazzo ma adesso mi devo scaricare next devo farlo girare perché a me bastava jackie per quella roba li andava benissimo e no ho voluto farlo con next e già stiamo parlando di next carmine ha scritto nella chat privata che è scritto che next comincia quando quando vedi che gas mi fa schifo.No, soprattutto che Gatsby non copierà più.Allora, sono d'accordo con quello che dice Michele e sono d'accordo che secondo me le soluzioni più che fittano, quanto più casi uso io ho lavorato in contesti dove la SEO era importantissima, quindi non puoi non andare con il template secco e con il pet engine secco per le parti che ti interessano ad essere indicizzate.È vero pure che secondo me utilizzare delle soluzioni ipride, come ai miei tempi, diciamo, c'era React on Rails, oppure delle soluzioni un po' più moderne come Inertia, che sostanzialmente non sono diventato che delle facility per farti inertare in una pagina che builde lo tuo template engine preferito sul server dei componenti, insomma React, Vue, quello che ti pare.Insomma, questa è un'ottima scelta, perché hai un timing to first byte che è sensato, se ti interessa quel tipo di performance, e hai un componente dinamico come ti piace, come vuoi, ma che non ti interessa e sia indicizzato, che poi, insomma, è responsabilità del client.Io ho utilizzato e utilizzo tanto Next, ho trovato l'unico utilizzo sensato delle API Routes o in generale di tutta l'edge runtime di Next utilizzando l'Sdk di Kratos, che è sostanzialmente questo sistema per fare i denti di server, per delegare la tua comunicazione all'esterno, ma che non ha front-end, ma un'API specifica che ti permette di costruire il tuo front-end sostanzialmente interando su questi nodi, che non sono nient'altro che i campi del tuo form.Insomma, se lo vogliamo descrivere così, hanno un SDK per Next che va sostanzialmente a creare, la spiegiamo malissimo, delle API routes che ti servono per interagire con l'autentication server.Quindi è un po', secondo me, un concetto simile al di engine di Rails.Avere delle cose che arricchiscono la tua applicazione e creano una parte che sembra full stack, ma non lo è.io non farei mai un'operazione full stack con Next utilizzando le API routes anche perché a livello di architettura è una cosa bruttissima.Stiamo veramente parlando che io devo generare la ruta di un API con la directory structure.Poi ci si lamenta della magia di Rails ma quella cosa lì secondo me è veramente ingestibile.Amico mio, le cose brutte brutte su Next, questa la devo dire perché è bellissimo, vengono da un mio vecchio progetto, sono tipo gli alieni no? Mi sembra di averlo già detto con il podcast ma mi fa sempre piacere ripeterlo in modo da esorcizzare gli spiriti cattivi, è quando hai uno stato con Redux saga che gira sul sul client che poi si deve riconciliare.Quelli sono gli alieni veramente.Quello è, volevo utilizzare CouchDB e PouchDB ma non sapevo che cosa fossero.Perché nel senso è il caso d'uso che mi stai riscrivendo.Però io apprezzo React perché è una UI library e poi puoi fare quello che vuoi, ma soprattutto perché puoi inserirla un po' alla volta in un progetto che c'è già.Che secondo me è una cosa che con Vue, specialmente con Angular, non puoi fare.Se io ho un mio vecchio monolite e lo voglio svecchiare perché voglio separare il frontend, il backend, eccetera, eccetera, utilizzare una soluzione come React che mi permette, con tutti i trade-off iniziali del caso, di cominciare a fare delle piccole sezioni e di rifattorizzarle piano piano, è veramente un valore aggiunto che tutti i framework hanno.Io non so se l'avete mai utilizzato, ma qua sta facendo questa pubblicità ad DHH pazzesca, un framework JavaScript che mi è piaciuto molto è stato Steamworks, che secondo me è quella via di stimulus, praticamente diciamo che è la Rails way di fare la parte JavaScript delle nuove applicazioni Rails.È sostanzialmente una sorta di live wire, eh sì, di live wire, di blade component, insomma, una roba mistica tra HTML e JavaScript, però è una cosa che ti permette di fare un'adoption incrementale dello strumento, che secondo me è una cosa importante.Non tutti hanno la possibilità di dire "ok, lo butto giù e lo rifaccio da cavo", perché spesso effettivamente costa troppo.Non so se vi siete mai posti questo problema.una roba che...boh, non lo so.Sì, allora il problema me lo sto sempre posto e io ti dico la verità.Tante volte costa davvero o meno buttar giù e rifar tutto.Anche perché a un certo punto se il progetto è abbastanza grande o vai a micro front-end o vai a micro applicazioni, le monti insieme, in React, micro progetti, librerie, le monti insieme, quindi tendenzialmente quando il progetto cresce vuoi andare su soluzioni diverse dall'app React monolitica per cui o, perdonami, o al contrario HTML, jQuery nel senso a quel punto sì che fai prima rifare da capo tante volte.Ci siamo scaldati abbastanza parlando di framework, di UI library e di quant'altro - Tant'altro, allora sempre passando per Next, voglio arrivare però a un altro linguaggio, a un altro argomento.Oggi devo dire che mi sono preso a cazzotti con SWR, penso si chiami così ok? - Sì - Quella cosa mistica e super veloce che serve per compilare Next, lo dico io sempre con la zappa, no? Per compilare, per traspilare, fare il bundling di tutte le robe di Next, che però non è che funziona benissimo con i container, è con le pipeline di Azure lo stesso, dobbiamo dirlo.Qualche minuto l'ho perso e qualche santo dal cielo è sceso a ammaledirmi.Quindi parliamo di traspilazione.Che cos'è la traspilazione? Ok, bene che hai usato il termine traspilazione innanzitutto, perché spesso si parla di compilazione.In realtà compilazione è da codice sorgente a codice binario, bytecode.Traspilazione è da linguaggio a linguaggio.Quindi ho il mio source code scritto magari in scala e e lo compilo in JavaScript tramite Scala.js, che è il compiler.La mia applicazione scritta è in Rayscript e la compilo in JavaScript usando il Backhole Script, che è il compiler di Rayscript.Per cui, bene che iniziamo subito con i termini fighi, perché transpilazione o transcompilazione è proprio questo.Quindi la capacità di leggere un source code in un linguaggio e trasformarlo in un altro linguaggio, che è quello che avviene in TypeScript, o nel linguaggio stesso con Babel, per cui io scrivo "optional chaining" in JavaScript e mi viene tradotto in una gigante "and and" sempre in JavaScript ma specifiche, che ricorda Go.Sai perché ricorda Go? Perché con la traspilazione spesso vengono cambiati i nomi delle variabili e spesso le variabili vengono messe a una lettera sola e sti stronzi che scrivono in Go, che usano una lettera sola senza nessuno.E allora è per quello che ti ricorda Go, perché per qualche motivo, per convenzione, se io devo fare una chiamata al database mi ritorna D, virgola R.Cos'è D? Perché? >> MAURO: No, no, no.Quella roba usate, io faccio Go che sono sei anni, io non so Rob Pike in che Autogrill della diatrica, della diatrica si è fermato e ha detto che le cose ma basta utilizzate dei nomi parlanti, non è possibile che vedo le variabili "v", "r".Il bello è che quando sono composte divento delle sigle "rrr", io lo giusto oggi, per esempio, "resus", "reseci", che scrivi, nel senso...>> MALEZZA È l'opposto esatto di Java, no? In Java sai che se non ha almeno cinque parole il nome della variabile non ha senso.>> MANTEZZA L'articolo è avverbio.Esatto, è proprio una descrizione dell'attuazione "I'm drinking a coffee and taking variable" quello è il nome della variabile per, che ne so, connetterti al DB, che cazzo ne so.In Java succede sta roba, in Go no.Mi connetto al database? C.Scrivimi "connect" o "connection", non C.Cazzo è C? Sì, esatto.Io guardando del codice Go, è come quello pseudocodice che il tuo professor d'un'università ti scriveva per dare un senso a quello che stai scrivendo.Il professor dice "ma che ci..." è un esercizio per il lettore.No è vero, questa è una cosa molto interessante che secondo me ci può portare a parlare delle community che è un altro discorso abbastanza interessante secondo me, nel senso che questo è proprio un problema di convenzione.Cioè nessuno ti obbliga a scrivere variabili di una lettera perché no però per convenzione la community adotta questo.Piacerebbe così.Io ho un'idea.Vai.Siccome Uncle Bob non è molto simpatico a dispetto hanno preso questa decisione.In che modo gli fa che dispetto è non lo capisco.Uno dei paradigmi più importanti di Uncle Bob erano i nomi parlanti.Ah oddio ma tu parlavi di Clean Code scusami.Exactly.Ma io ho pensato ad Uncle Bob quello di cartellone dell'America.Infatti dicevo ma scusa cosa c'entra? Ok.No io guarda sapi che cerco il momento perfetto per parlare male di Go, come ti avevo già accennato a suo tempo, e parlare male di Uncle Bob.Anche Io ho dovuto silenziare il Twitter di Uncle Bob in questi giorni, come veramente quando vai a casa per le feste e c'è quel tuo zio, un po' all'antica, no? Dice "no, fa con la ma", dici "vabbè zio, non ti preoccupare, sopra la roba del genere".Però sì, è vero, in voce c'è questo problema Ed è una cosa che ho visto anche tanto in JavaScript.E spesso questa cosa credo che dipenda anche da framework a framework.Nel senso io ho visto dei sorgenti di applicazioni Angular e di applicazioni Nest, che vi invito a dirmi che cosa ne pensate, perché se non è...è brutto, diciamo così, che erano effettivamente Java.nel senso non sono riuscito a trovare altra parola insomma per fare questa cosa qui.Insomma io ho visto anche persone in azienda che si scrivono delle regole di ESLint per i non parlanti.- Bello però, questo ci sta.- No, questo sì, ci sta, perché quando ti trovi con la parabola che si chiama form, Io su Nest non dirò nulla, per cui se vogliamo cambiare argomento...Cioè, poche idee sono state così brutte e mal realizzate e Nest è una di queste, insieme a...no, non lo dico, insieme a tante altre cose.Vabbè ma NEST dalla mia sensazione è il classico strumento...adesso un'altra antipatia! Vai Mauro! È lo strumento fatto per venderti la consulenza.È perfetto! È Java! È letteralmente Java! È perfetto per quello! È letteralmente il motivo per cui è nato.Cioè, mai mai visto? Prova a cercare su Google, scusa su YouTube, Java 1995 commercial.C'è uno spot pubblicitario di James Bond che si tira fuori un manuale Java dal taschino, quello tascabile, e va a combattere un nemico che ha scritto C++ sulla schiena, letteralmente.Java, perché non mi piace sotto tanti punti di vista? Perché, per quanto mi riguarda, ha proprio delle caratteristiche che ti portano a dover richiedere una mano a un certo punto.Non so neanche come esprimermi sotto questo punto di vista.Non ho una grande simpatia per il runtime e per il linguaggio.Mi sembra di vedere proprio quel tipico linguaggio che arriva il consulente con la valigetta in giacca e cravatta, apre la valigetta e ti vende il prodotto in più, il pezzo in più che ti mancava.A me dà proprio quell'impressione lì.La stessa cosa è Nest.Lo uso, poi a un certo punto mi schianto perché non ha al minimo senso e c'è qualcuno che quel senso fa finta di trovarlo e ti vende la consulenza.Io pensavo di aver visto il male, già scritto con loopback, che è una cosa, quello di IBM, pensavo di aver visto il male con quella cosa lì, Nest lo ha superato ampiamente, insomma.Nel senso là, io sono grande fan della dependence injection, io ci contene come vuoi, ma nel nel senso Nest o Inversify, insomma, per il prezzo così di per sé non l'ho mai capito.Però ecco, alla fine, non so, io credo che il bello di tutto l'ecosistema già scritto sia anche questo, che hai diversi flavor per tutto e puoi effettivamente scegliere tra le varie cose, che non è una cosa scontata in tanti altri ecosistemi.E' bello perché è vario e ci sono anche queste cose qui.Ci sono più framework da insultare.Abbiamo preso una tangente, ci siamo allungati tantissimo.Volevo però ritornare al concetto di traspilazione, Michele, scusa se abbiamo un po' male.Alla fine si va sempre a parlare.Ma siamo siamo in un bar, ci sta...Gitbar è un po' così fondamentalmente.Ah va bene, va bene.Dicevamo, riguardo alla traspilazione, quello che noi vediamo è che entra una roba ed esce qualcos'altro da questa macchinetta magica, ma cosa succede all'interno? Succede, diciamo così, quello che succede tipicamente con un compilatore, ovvero un compilatore esegue una serie di fasi, parte dallo scanning della codebase, poi al tokenizing per cui ogni singola lettera effettivamente fa parte di un token, non so const è un token, il nome della variabile è un token, for dei loop è un altro token e così via.Si passa all'analisi sintattica del codice che ho scritto, quindi si crea prima un concrete syntax tree, poi un abstract syntax tree per capire se ha senso quello che ho scritto, determinare l'ordine di esecuzione e eventualmente ottimizzare.Magari faceva il closure compiler di Google un tempo, leggeva l'abstract syntax tree e diceva "ma sai che c'è? Io ho l'esecuzione, te la sposto un po' così che effettivamente ti migliorerà a runtime i tempi di esecuzione".Per cui fai una serie di analisi statica sul codice e lo puoi utilizzare, puoi fare quello che vuoi.Eventualmente a un certo punto puoi decidere di dire ok, ho analizzato il codice, per cui faccio due cose.Uno, faccio un reporting come in ESLint.Ti tiro fuori una serie di regole che non hai rispettato perché leggendo la syntax tree capisco che non hai rispettato certe regole.Ad esempio, ho usato i doppi apici, devi usare gli apici singoli, per esempio.Oppure genero altro codice.Qui si passa alla fase di transformation del codice, ovvero io magari ho var e lo sostituisco con let, se possibile, ovviamente.Non è sempre possibile.E una volta che ho fatto questo, avviene l'ultima fase, che è la fase di code gen, quindi code generation.E quindi vado a generare nuovo codice, che basandomi sulle regole che vado a stabilire con i miei plug-in, poi sostanzialmente se parliamo di Babel, o col mio compiler se me lo scrivo a mano, cosa che non vi consiglio, a quel punto genero del codice che è compatibile con il run time su cui deve girare.Domanda.Un sistema di traspilazione Babel per dirne una e invece il compilatore, adesso La butto facile ma comunque può sembrare stupida questa domanda.Come un compilatore invece per un linguaggio, un vero compilatore, in cosa differiscono alla fine? Solo nella parte di generation? E quindi tutta la parte on top alla catena rimane identica? Esattamente così.Allora, ammesso che io poi so quanto basta.Per cui, nel senso, non entriamo troppo nei dettagli perché poi non sarei neanche in grado di proseguire, naturalmente.Ci sono persone estremamente specializzate che sanno risponderti meglio, ma quello che ti posso dire è, è a tutti gli effetti un compilatore che come output ti dà un altro linguaggio.Poi, da lì, se sei skillato abbastanza, puoi anche decidere magari di compilare binario.per ora non l'ha ancora fatto nessuno, però la possibilità c'è, nel senso che tu ti crei un...mettiamola così, il linguaggio è sempre agnostico dal run time.Se tu apri un libro bellissimo che si chiama "Programming Haskell" di Graham Hutton, lui ti dice, per i primi cinque capitoli, lui ti dice "Haskell così, Haskell cosa", al quinto capitolo ti dice "poi sai che c'è, esiste anche un compiler".Tu dici "ok, sì, ma finora è come dovevo eseguirlo, questo codice.Perché in realtà lui ti parla del linguaggio, non del runtime, non di dove vai a eseguirlo.Perché banalmente le CPU che usiamo noi non sono ottimizzate per la Lazy Evaluation di Haskell.Per cui non ci interessa il runtime se parliamo del linguaggio, no? Poi, se vuoi far girare JavaScript nativo, devi compilarlo in codice binario nativo o bytecode LLVM per, sempre per, poi andare, che è un framework per compilare a tua volta codice nativo, puoi compilare bytecode Java, puoi compilare bytecode Erlang, che è quello che fanno Elisir, Gleam, mi riviene l'altro che è un Lisp per la Beam.Per cui, quando parliamo di queste cose dobbiamo capirci, cioè stiamo parlando di runtime o di linguaggio? Perché il linguaggio è completamente indipendente dal runtime, a parte Erlang, due o tre eccezioni.sì sì ma era bellina la battuta che i programmatori ASCQL scrivono il codice sulla carta e non l'eseguono proprio per evitare i side effects.Esatto.E' vero.Però questo per dire che sì alla fine comunque per rispondere alla tua domanda la differenza è che Babel rispetto magari a GNU Common Compiler adesso non so dire la sigla in italiano chiamiamo GCC.Non ho mai pronunciato ad alta voce.La differenza è che quello ti compila codice nativo Babel compila già la scritta sostanzialmente.Cambia il target ma è un compiler.Chiarissimo.E siccome abbiamo introdotto Askel.Ok.Siccome molti sanno che Askel è tipo il...l'elico? No, è il sogno...e prende la Beatrice per Dante, no? Che praticamente se la sognava non gliela darà mai.Ecco per me Askel è quello.Mi son dovuto accontentare dell'amica un po' più brutta che è la Scala e mi son studiato quello.No però ti chiedo intanto Qual è stato il tuo percorso di apprendimento nel mondo Haskell? Quindi come hai approcciato? Quanto ti stai portando di quell'esperienza poi nel mondo JavaScript? Bello ok allora parto al contrario se per te va bene.Nel senso che con ES6 effettivamente sono state introdotte una serie di feature che derivano da Haskell che ci piacciono.Perché il metodo map si chiama map? Perché in Haskell si chiama map? Perché in Haskell si chiama map? Perché nella teoria delle categorie quando tu devi collegare due categorie usi un funtore che esegue un'azione di mapping da una categoria all'altra.Per cui ovvio non ci serve saperlo per scrivere java script, però se scavi un pochino il perché quel il metodo si chiama map.Non ho idea del perché, ok, ho un'immensa idea del perché si chiama reduce, che però viene anche quello da Haskell, no? Haskell è il folding, è il fold.Anche il filter arriva tutto da lì, no? I metodi sugli array generalmente arrivano da linguaggi ML.Perché? Perché linguaggi ML, se tu togli, ad esempio lisp, con tutte le sue belle parentesi, lisp significa list processor, ok? Lavora sulle liste, tendenzialmente.Se tu togli le parentesi a Lisp, ti vengono fuori linguaggi ML.Abbastanza semplice.Per cui tutti i metodi di esecuzione sugli array nascono tipicamente in Lisp, vengono trasportati in...Oddio, nascono in Lisp.Qualcosa è nato in Lisp e poi vengono portati avanti molto da ML, da OCaml, da tutti i linguaggi ML in generale, tra cui anche Haskell, che pur essendo una nicchia, ha influenzato qualunque altro linguaggio che usiamo oggi.Cioè PHP che adotta le lambda function, perché? Oppure Java che implementa i parallel maps, perché? Come implementi il mapping parallelo in Java? Usi regole o i generics addirittura, i generics in Java da dov'è che arrivano? Arrivano da F#, F# perché è stato scritto? scritto F# è stato scritto perché volevano portare ASCAL su...scusa ho detto una cazzata enorme stavo parlando di .NET e i generics in C# arrivano da F#.F# è stato scritto perché volevano portare ASCAL su .NET non ce l'han fatta, han portato OCaml.Però i principi che ti arrivano da OCaml che appunto è un linguaggio ML poi te li sei trasportati anche in F#, poi in C#, eccetera.La stessa cosa poi con Java, Scala, Kotlin, eccetera.Tutti i linguaggi che attingono quotidianamente da Haskell.Per cui, per rispondere alla tua domanda, l'ho presa larghissima, quanto mi porto dietro? Beh, è chiaro che se conosci Haskell oggi un minimo, perché io lo conosco veramente un minimo, però ti permette di usare pattern comuni ormai in qualunque altro linguaggio.E l'influenza che tu vedi in Haskell in altri linguaggi non è vero il contrario, cioè non c'è linguaggio che abbia influenzato così tanto a Aska la sua volta.Per cui è proprio un percorso parallelo che però ha delle grandi influenze ed è per questo che consiglio di guardarci un po'.Sai io, vabbè molti lo sanno già, ho una moglie che lavora con Scala, quindi Cats tutto quel mondo.E con lei ci facevamo una domanda.Ci chiedevamo perché la radice di quel tipo di linguaggi è europea? Ah bellissima questa domanda.Perché ML...allora l'ISP è nato nel 1957 in America, ma ML è nato all'INRIA, che è l'Istituto Nazionale di Ricerca Informatica, credo, che è in Francia.Per cui ML, che è stato un linguaggio ancora usato, tra l'altro, standard ML oggi è abbastanza usato, però i linguaggi derivanti da ML sono stati principalmente poi portati avanti in Europa, quindi principalmente in Francia, quindi OCaml, OCaml stesso, ML, sono tutti linguaggi portati avanti in Francia, tendenzialmente.Per cui l'origine europea per questo motivo.Poi l'Università di Edimburgo, ad esempio, ha dato dei grandissimi contributi ad Haskell, ma anche Haskell, ad esempio, come linguaggi ML, sono frutto di un collettivo, non di un singolo.Cioè, se abbiamo James Gosling per Java, Guido Varrossum per Python, abbiamo la persona di riferimento lì, no? Mentre per le linguaggi ML no.Perché? Perché sono ricerche accademiche soprattutto, sono nate da ricerche accademiche, quindi c'è un collettivo di studenti, di studiosi, di professori che nella loro tesi del dottorato portano un pezzettino in più a tutti questi linguaggi.Sai cosa cosa mi viene da pensare? pensare magari una speculazione e sto solo facendomi del segamento alle più di quanti dovrei però è una cosa che ho detto tante volte qua al podcast e ci tengo a ripeterlo spesso le lingue e parlo delle lingue che parliamo anzi senza spesso è risaputo che le lingue forgino il modo in cui pensiamo ok In realtà le lingue europee hanno una varietà e una vastità rispetto al classico inglese di tutto il mondo anglofono.Quindi non vorrei, ripeto è una speculazione, che come diceva appunto la mia amica Vittoria le lingue formano il pensiero, la parola forma il pensiero, che fossero in qualche modo anche guidati da questo approccio.È un po' un'idea romantica.In realtà cito Galimberti, Umberto Galimberti, che magari conoscete, filosofo e psicanalista italiano, quindi nel senso non l'ultimo degli stronzi, insomma è una persona abbastanza competente e dice che chiaramente, e secondo me ha ragione, non possiamo pensare se non conosciamo le parole, cioè non possiamo pensare a qualcosa che non ha una parola.Per cui, ad esempio, perché la filosofia si sviluppa in Austria, in Germania, la grande filosofia del Novecento nasce, se pensiamo agli autori, nascono tendenzialmente all'Ottonovecento, in Austria, in Germania, perché la lingua tedesca, ad esempio, è estremamente ricca di vocaboli, non esiste, è molto raro avere un fraintendimento sul termine, no? Io parlo, Io ti dico, il verbo tirare vuol dire tirare la porta o tirare un bastone.Sono due cose completamente opposte, no? Quindi capisci quanto fraintendimento ci può essere.Con questa roba in tedesco non potrebbe mai accadere.E le lingue, pur essendo una lingua anglosassone, no? Perché invece altre lingue anglosassone come l'inglese vivono di ambiguità.E quindi, non so dirti poi, lo sviluppo dei linguaggi di programmazione, quanto siano influenzati dal modo, passami il termine latino, perché poi alla fine, essendo nati in Francia, chiaramente portano delle influenze neolatine, potrebbero portare, no? Non so quanto portino con sé questo tipo di influenza.Sicuramente a livello di pensiero le persone che ci hanno lavorato hanno una forma mente diversa.Non dico migliore, non dico peggiore, dico diversa.Questo per me è abbastanza certo.Chiaro.Tra l'altro mi hai fatto venire in mente un'idea, quindi sentiti padre di questo e quindi sarai invitato.Sarebbe bello fare un esperimento, una puntata di Gitbar dove prendiamo un po' di linguaggi e chiamiamo un linguista.Ah va bene, è bello sì.Partiamo da Kobol, super incasinato.E vai con le divisioni.Finiamo con Cadregalisp, che è un dialetto lisp che ho scritto io con mia nonna in dialetto brianzolo.Per cui se devi assegnare una variabile a X devi fare X chapache 10.Per cui devi scrivere tutto in dialetto brianzolo.e arriviamo, quella è la conclusione.Era bellissimo, ho visto il tuo toic a Code Emotion, simpaticissimo.È vero, sì.Io ho guardato l'orologio, non me ne sono accorto, in un battito di ciglia siamo già arrivati a più di un'ora e quindi come solito su Gitbar in conclusione c'è il nostro momento tipico e topico chiamato il Paese dei Balocchi, il momento in cui i nostri host e i nostri ospiti condividono con noi un libro, un talk, un articolo, un tool, un linguaggio che può essere carino da approfondire per cui valga veramente la pena investire qualche ora o qualche minuto da esplorare.Ecco tu Michele hai qualcosa per noi che vuoi condividere ecco la nostra community.E conduco nel paese dei balocchi.Ah, il paese dei balocchi.Burca, non mi ero preparato per questa domanda.Era una domanda sorpresa in realtà.Esatto.No, perché in realtà c'è un libro e che non mi ricordo esattamente il titolo.Dovrebbe essere "Codeless Data Structures and Algorithms" e parla di algoritmi e strutture dati ma senza usare il codice.il codice.Quindi con esempi che vanno al di fuori dell'esperienza dell'informatica, tante volte.Ma tipo "Groking algorithms", no? Quello era quello di...No, no, no, si chiama proprio...dovrebbe chiamarsi proprio "Codeless Data Structures and Algorithms".E ad esempio ti spiega Binary Search dicendo "Sei un bibliotecario, devi trovare il libro che inizia con la lettera F.Come fai?" e ti spiega il Binary Search funziona per chiaramente farlo nel minore numero di passaggi possibili.Personalmente mi ha aiutato tanto perché io ho bisogno di esempi molto concreti e questo libro ne propone.Bello, me lo recupero al volo.Luca, Carmine avete qualcosa? Io ho un balocco che tra l'altro mi ha consigliato Carmine qualche settimana fa, dovuto, sì non fare quella faccia, sì sì, dovuto a alcuni dolori di tendinite che avevo a causa del tastiere mouse, allora lui mi ha consigliato nella nostra chat, ecco ce l'ha anche lui, una Logitech ergonomica K860 che sto usando, vabbè l'ho presa wireless, sto usando attualmente, allora mi è passata tutta la tendinite e tutto, però quando digito mi sembro un vecchio di 80 anni davanti a una macchina da scrivere.Ma sto acquisendo più velocemente del previsto, perché comunque una split keyboard non ero abituato a questo, però insomma per lo scopo per quale l'avevo comprato, insomma, ha fatto il suo il suo lavoro.Posso riprendere a suonare, posso riprendere a digitare, posso riprendere anche a fare il cubo di Rubik.Anche questo se avete dei bambini di 8-10 anni e volete un'idea regalo, il cubo di Rubik è un ottimo regalo.In realtà l'ho regalato a mio figlio già tanti anni fa, però soltanto adesso ha cominciato a prenderlo, ha 10 anni.La cosa divertente è che l'ha portato a scuola e in tempo due settimane stavano tutti i bambini di tutta la scuola con un cubo di rubik in mano, cercare di risolverlo e quindi niente, volevo darvi questa esperienza potrebbe essere una cosa carina.Tanto ormai adesso con insieme alla se comprate anche gli speedcube che costano una quarantina di euro però ne vale la pena, ti danno anche il foglio con tutti gli algoritmi per la risoluzione sia quelli a strati quindi quelli più semplici sia quelli più avanzati.Io il mio record è di 50 secondi, sto cercando di migliorare ma soprattutto di migliorare per evitare che mio figlio mi batta, perché è arrivato il minuto anche lui, sarebbe un duro colpo.A fine.LM: allora, sì, concordo con la tastiera di Luca, ci sto abituando anch'io, anche io sempre ci sono quelle volte che faccio quei movimenti delle dita così strani, proprio che si intreccia, però è tutta una questione di abitudine.Vi consiglio anche il mouse che è il fratello della tastiera, che è l'Mx Vertica, che è un mouse verticale.Ma in realtà il mio balocco è un libro, che ho preso qualche giorno fa, che si chiama "Racket Programming the Fun Way".Per chi non conoscesse Racket, è sostanzialmente...come definirlo? È un linguaggio per fare linguaggi, Ecco, diciamo così, che si infia tutto e non si infia niente, in realtà.In realtà è un linguaggio di programmazione veramente divertente e che potete usare per farci qualunque cosa, ma tipicamente è utile per fare dei DSL.Io ho scoperto Racket qualche anno fa al Lambda Award e me ne sono veramente innamorato.L'app in particolarità è che se utilizzate il suo IDE, che è Dr.Racket, potete scrivere del codice Racket per aggiungere delle funzionalità all'idee mentre state scrivendo codice.È una roba bellissima.E questo libro è sostanzialmente un'introduzione al Racket e alla programmazione in generale, in realtà.Secondo me è utile per chi non ha mai visto la programmazione per chi magari vuole un ripasso di quelle cose veramente di base, ma con un flavor più divertente.Sicuramente sul prossimo annuncio di lavoro non troverete Racket, se lo trovate inviatemelo, perché sono anche io curioso, però è sicuramente qualcosa con cui vi potete divertire.[A] Tra l'altro, perdonami, aggiungo solo che il Cadregalisp di cui ho parlato prima è una traduzione letterale di racket, nel senso che viene tradotto il racket da eseguito poi da Askel dietro le quinte, ma racket è veramente spettacolare, lo consiglio davvero a tutti quanti perché è veramente, veramente bello, io non ho nient'altro da dire, è veramente bello.No, no, è bello e super interessante.è difficile se andate sul sito ufficiale del Getting Started questo linguaggio per fare linguaggio, si ok basta, pensando che è una cosa estremamente complessa in realtà il bello di Racket è che secondo me è semplice, è veramente semplice e vi ci può poter divertire allora io mi sono praticamente già bruciato le mie vacanze estive con questo perché ho contato i libri che ci sono in pila sul comodino e gli altri che ci sono nella wishlist di Amazon e sia quello di Michele che il tuo sono andati in wishlist mentre parlavate quindi alla fine se non farò vacanze al mare sappiatelo e colpa vostra.Detto questo anch'io un piccolo balocco ve l'ho accennato all'inizio dell'episodio si tratta di una sorta di applicazione che serve per creare video con react si chiama ReMotion lo trovate nel loro sito anche nel github è open source però mi sa che per la parte commerciale ci vuole una licenza comunque il codice è tutto open e buttateci un occhio perché è comunque interessante vedere come in qualche modo si possono fare i video anche con quella roba che utilizziamo tutti i giorni [Musica] detto questo è ormai quasi arrivati a un'ora e mezza io devo ringraziare e Michele per esserci venuta a trovare, grazie di cuore.Grazie a voi per l'invito, è stato un piacere.Sapi che quando porteremo il linguista sarai invitato.Mala grande, no guarda davvero è una cosa che mi interesserebbe tantissimo e vorrei portare una serie di codici tipici, proprio magari programmazione dichiarativa, imperativa, un attimo come cosa può venire fuori.Sì secondo me bisogna trovare il linguista giusto.Nel senso che molti sono seduti sui classici paradigmi accademici e quindi questa roba shifta un po' dalle loro visioni comuni.Però secondo me può essere un bel esercizio, quantomeno un esercizio che ci spinge a guardare, ampliare gli orizzonti e uscire anche da quelli che sono i nostri classici ambienti di studio e capire che fondamentalmente l'impatto del codice, cioè non solo il codice che facciamo, le applicazioni che facciamo, i tool che realizziamo, ma anche il mondo in qualche modo influenza ciò che facciamo in modo nascosto o comunque implicito.detto questo quindi Michele grazie, grazie di nuovo ti seguiremo nelle tue prossime conferenze che insomma hai veramente una tournée più ricca di un Vasco Rossi dei tempi d'oro magari e nulla allora saluto e ringrazio anche Luca e Carmine grazie per avermi dato una mano a versare queste birre nel nostro circolo degli sviluppatori e vi ricordo rapidamente scusa ti ho parlato sopra ma tanto quella parte avendo due tracce quella parte la taglio di più.Va bene ne approfitto per dire che mancano un po' di birre.Qui infatti ragazzi se donate, donate il catamarano di Gitbar è ancora fermo al cantiere, nel senso vorremmo farlo andare in mare il prima possibile.L'hackathon sul catamarano potrebbe essere una bella roba.In realtà potremmo noleggiare un Bali per fare l'hackathon.Oh, giusto un amico che ce l'ha.Detto questo io vi ringrazio nuovamente, vi ricordo i nostri contatti infochiocelagitbar.it @brainrepo su twitter tanto la non ci scrive nessuno quindi gruppo telegram se non l'avete fatto alla prossima ciao ciao Gitbar 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 ed strumenti immancabili nella cassetta degli attrezzi dei Full Stack Dev.
