Bene e benvenuti su Gitbar, nuova settimana e nuovo episodio del nostro podcast.Anche oggi abbiamo un ospite speciale ma come mio solito vi lascio un po' di suspense perché, come sempre, vi devo ricordare i nostri contatti.Info@gitbar.it e @brainrepo su Twitter sono gli handle classici per contattarci.ma esiste un modo che è quello da noi preferito che è Telegram.Noi abbiamo una community Telegram più di 500 membri all'attivo ci incontriamo tutti i giorni a tutte le ore per parlare delle cose che ci piacciono di più quindi se non l'avete ancora fatto aprite il vostro client Telegram preferito cercate Gitbar e trovate il nostro gruppo e mi raccomando iscrivetevi 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.Ecco qua, oggi sono con Gabriele Petronella, co-founder e software engineer a Bildo e anche organizzatore del Scala Italy, un evento di portata nazionale che mi ricordava prima Gabriele, sarà tra qualche giorno giusto? Sì giusto ciao a tutti ciao Mauro ciao a tutti quelli che stanno ascoltando questo podcast e grazie per l'invito e si ne approfitto subito per una marchetta che è che settimana prossima sabato avremo una conferenza appunto su scala italiana virtuale è la prima volta che lo facciamo virtuale e in Italia, trattando di questa situazione pandemia strana abbiamo ci siamo un po reinventati quest'anno sperando di poter tornare a mangiare cose buone in giro per l'Italia e a bere birre le classiche birre e a bervi esattamente comunque davvero io me l'ero perso sicuramente se sarà online riuscirò a vederlo anche perché devo vedere anche se in modo digitale un meeting dei discepoli di Odeschi.Si è un po' una setta, devo ammettere siamo pochi ma buoni in Italia ma ci difendiamo.Davvero in Italia non ci sono tanti sviluppatori Scala da quello che vedo e soprattutto come ambiente è quasi tutto legato alla FinTech se non mi sbaglio.Sì, diciamo che è un po' il cavallo di battaglia.Noi siamo tra le poche aziende che lo usano per scrivere, diciamo, servizi di back-end anche per altri contesti, ma sicuramente l'ambito FinTech, l'ambito anche di data science, diciamo, è molto...è quello che l'ha fatto da padrone su scala.Ed è vero che la community è piccola, ma è comunque in grande crescita e proviamo sempre a creare occasioni di confronto tutti gli anni e quando si poteva anche con il meetup a Milano e in altre città.Quindi ci si prova.È vero, per un momento dimenticavo tutto il mondo del data science e di Spark, ecco che comunque è vero che c'è anche per Python, però tutti quelli che conosco sono scalisti.Eh ma perché Spark è storicamente molto più votato sulle API Scala, diciamo, quindi è una piccola nicchia dove effettivamente è molto diffuso.Però prima di parlare di robe tecniche, la domanda che faccio di solito ai nostri ospiti è come sei entrato nel tunnel e qual è stato il tuo percorso che ti ha portato da prima verso Scala e poi verso TypeScript? Sì, ma allora Io diciamo che mi sono approcciato al mondo Scala intorno al 2012, grossomodo.All'epoca era appena uscito il corso su Cucura di Odersky, che era un corso gratuito delle PFL, era una roba abbastanza nuova.Avevo sentito parlare di Scala all'università, all'epoca nel 2012 stavo finendo di studiare diciamo nel mio master al Politecnico e quindi ho detto "Vabbè, inizio a guardarci".Più o meno nello stesso periodo stavamo fondando Buildup con i miei soci e avevamo un primo grosso progetto dove dovevamo lavorare in un ambito tra l'altro abbastanza delicato, un ambito medico, quindi volevamo usare una tecnologia che ci desse abbastanza confidenza di scrivere codice in maniera abbastanza sicura, ma non impazzire dietro a quello che all'epoca era Java 7, che non piaceva un po' a nessuno dei partecipanti.Adesso è migliorato tanto, devo dire, il linguaggio è sempre più interessante Java.Un pochino, vado solo un po' di parto, ma un pochino sta copiando Scala, giustamente.E quindi, non so, Scala sembrava una buona scelta, l'avevamo appena finito di studiare io e altri soci.e poi da allora non ci siamo più o meno più guardati indietro.Questo per quanto riguarda Scala, nel frattempo, nello sviluppare i front-end, siamo poi partiti con sostanzialmente JavaScript, molto inizialmente con AngularJS, per chi se lo ricorda, il primissimo Angular, e grazie a Ciro ha migliorato tanto anche quello da quando l'hanno cambiato in Angular, - Direi di sì.- Troppando il JS, ma noi abbiamo ancora gli incubi del primo AngularJS, siamo migrati poi lentamente verso React e devo dire leggermente...adesso noi siamo uno shop di React, TypeScript e Scala sostanzialmente e leggermente prima che diventasse un trend mondiale, cioè direi sostanzialmente io reputo che nel gennaio 2019 il mondo si è accorto di TypeScript più o meno, credo che sia successo un po' Un po' per motivi di maturità, di adozione da parte di grosse aziende, un po' perché altre opzioni sono andate sempre più diminuendo, per esempio Flowtype, che è tuttora un linguaggio tipizzato, sviluppato da Facebook, sopra JavaScript.Era un po' stagnante, poi è stato ufficialmente marcato come un linguaggio interno a Facebook.E non po' prima, quindi fine 2017-2018, ci siamo approfittati a TypeScript perché avevamo iniziato a gestire progetti molto grandi e JavaScript su progetti molto grandi, magari avremo modo di approfondire un po' durante la chiacchierata oggi, ma inizia a star stretto.Se hai dei team che crescono, dei progetti che crescono, TypeScript inizia ad essere molto utile.Io ricordo che il vero primo endorsement importante di TypeScript è stata l'adozione proprio con Angular dove ce l'avevi out of the box e non avevi grosse alternative oltre quello nel senso che Angular veniva con TypeScript e quello ti pigliavi e infatti io così la prima volta sono arrivato a TypeScript.Però faccio una premessa, io amo TypeScript, lavoro su TypeScript il 95% del mio tempo e ne apprezzo bene tutti i vantaggi, però credo che la mia posizione è molto biased, è legata a un bias molto forte.La mia domanda è avere questo sistema, come l'ha definito un amico, evanescente sopra JavaScript, in qualche modo può inficiare su quella che è la produttività nello scrivere codice dal tuo punto di vista? Allora, è una domanda a cui si possono dare risposte semplicistiche, ma mi avventurerò in una risposta un po' più complessa.Allora, TypeScript di per sé, dal punto di vista puramente di tecnologia, è al contempo un piccolo gioiello per quello che fa, ma per quello che ti fa anche un sacco incazzare, se mi passi il termine, soprattutto se arrivi da un linguaggio che è un po' più coeso e studiato per essere fatto in quel modo, tipo Scala, ma tipo anche Java o altri linguaggi statici.TypeScript si è scelto un compito infame, che è quello di mantenere le semantiche di JavaScript ma attaccarci sopra un sistema di tipi.E le persone che lavorano su TypeScript non sono esattamente gli ultimi arrivati.il creatore di cui faccio sempre fatica a pronunciare il nome, ma è lo stesso creatore di C#, di Pascal, prima, cioè non è proprio l'ultimo arrivato.Quindi fa molto bene un compito molto difficile da fare e per questo è pieno di buchi, quindi è facile spararsi nei piedi usando Tilescript a volte, cioè devi comunque avere un minimo di disciplina perché puoi fare degli errori che in linguaggi tipo scala non puoi fare, punto.Ci devi impegnare quantomeno molto di più.Sul discorso produttività verso non produttività, dipende un po' come la misuriamo.Perché nel super short term è vero che TypeScript ti rallenta, soprattutto quando lo stai imparando, quando non sei molto familiare, e ti impedisce attivamente di fare certe cose.All'inizio può sembrare un problema che magari non riesci a scrivere la funzione che eri abituato a scrivere.Pian piano, nella mia esperienza, nell'esperienza di chi ho visto apporzare sempre più i benefici di TypeScript, questo diventa un po' un contagio, nel senso che tipicamente le cose che non riesci a fare in TypeScript forse era meglio che non le facevi.Questo è un po' quello che dico spesso, cioè se stai scrivendo una roba fortemente dinamica in JavaScript che ti permette di fare, che però non riesci a tipizzare bene in TypeScript, forse non era l'API migliore che potevi disegnare e forse non era così chiaro.E questa è un'esperienza che secondo me è diventata molto chiara nel momento in cui un sacco di progetti open source molto JavaScriptosi, se mi passi il termine, stanno convertendo la loro code base a TypeScript di recente.Adesso banalità, ogni volta che qualche componente che usiamo di React spesso noto questo trend a convertire le cose direttamente in TypeScript Sì ma lo stesso Vue.js si è svecchiato passando a TypeScript Per esempio, ma di recente anche per dire React Redux che è un componente abbastanza importante dell'ecosistema React è stato riscritto in TypeScript e questo fa sì che praticamente devi necessariamente normalizzare un sacco di magagni di magagni, di cose molto smart e clever che hai scritto in JavaScript, perché in JavaScript lo fa fare e in TypeScript inizia a litigare col Type System.Io lo vedo come un pro, per la maggior parte del tempo.Come tutte le tecnologie e tutti i livelli aggiunti crea la necessità di studiarlo, di impararlo, è una cosa in più ovviamente, e ha vantaggi.TI dà abbastanza vantaggi secondo me da essere un buon investimento mettiamola così.Sì, credo che TypeScript da una parte è un ottimo coltellino svizzero per situazioni dove la codebase diventa gigante e tu riesci a navigare facilmente la codebase utilizzando TypeScript.Dall'altra parte però presuppone come dicevi tu disciplina e consapevolezza nel senso che cadere nel tranello dell'Eni su TypeScript è molto facile per chi non usasse TypeScript Eni è un modo gioioso per dire al nostro Transpiler TypeScript "Ehi caro Transpiler da questo momento in poi questa cosa non ti preoccupare fidati di me e quel fidati di me che di solito nasconde poi le cose più atroci e imprendibili dopo, ingestibili dopo.Confermo.Però se utilizzato con disciplina ti permette davvero di tenere una code base che si spiega da sola.Sì, ti dà visibilità sulla code base, nel senso che hai evidenza normalmente quando fai un cambiamento di argomento cosa hai spaccato.Facciamo un esempio proprio terra a terra a livello di batiscopa come dico io.Tu devi capire non solo cosa fanno le funzioni ma che dati prendono in ingresso e cosa sputtano e tutto il flow della tua applicazione fa transitare delle informazioni, delle strutture di dati.Queste sono esplicite con TypeScript.In javascript molte volte si va di console log o di breakpoint per vedere cosa sta passando in questo momento perché non hai la contezza dell'informazione che passa.Se la codebase diventa grande il nostro cervello ha un limite di memorizzazione anche perché poi la chiarezza del codice che scriviamo col tempo che passa un po' di informazioni le perdiamo quindi rischiamo di perderci nel nostro stesso codice quando invece abbiamo tutto esplicito in quel modo beh dei vantaggi ci sono.Sì sono molto d'accordo, tra due cose in aggiunta a questo visto che è un tema molto caro.La prima è che usare TypeScript ti dà visibilità sulle cose che rompi, sulle dipendenze tra progetti e normalmente quando tu hai tipizzato bene una codebase, il lavoro di un refactor tipicamente parte da un dato, un tipo che cambia, aggiusti tutti gli errori e l'applicazione torna a funzionare.Quella è un'esperienza che io ho spesso quando programmo.Io entro nel browser e vedo l'applicazione che va ok, a meno che non stia lavorando su cose magari puramente visive, ma a livello di funzionalità, quando lavoravo con javascript su base abbastanza grandi, era la norma che tu entravi nel browser, ti becchiavi uno stack trace o qualcosa che non andava, piazzavi dei control log, come dicevi tu, dei breakpoint, e lavoravi in questo loop tra l'editor e il browser.Io adesso il browser, quando lavoro su Web l'application, lo vedo una, due volte l'ora magari perché sto facendo delle grosse cose, ma posso tranquillamente stare nell'editor e lavorare nell'editor e quando l'editor compila, quando il TypeScript compila, funziona.La seconda cosa che volevo dire in realtà è che questo non implica che la codebase sia buona, nel senso che TypeScript ti rende molto evidente che tu hai tante dipendenze, ma se ogni cosa che tocchi hai 400 cose che rompono forse la tua coppia è organizzata male e questo è un tema che a me piace introdurre quando introduco i concetti di functional programming perché sono quelli che invece dopo sopra il fatto di avere le basi, sapere cosa si spacca, come organizzare le cose perché siano disaccoppiate nella maniera corretta, functional programming ha un paio di cose da dire.Assolutamente sì, concordo con te.Volevo però portare all'evidenza una delle cose che io da amatore amante di typescript faccio sempre i discorsi da bar dove si parla "eh ma tu sei un fanboy quello che ti pare" però una delle obiezioni che si solleva più spesso è quella di "eh vabbè ma i tipi ti danno una rete di sicurezza" vero? Quindi la missione c'è dalla persona con cui parlo però dice anche ma questa rete di sicurezza ce l'avresti comunque se tu hai una bella suite di test o ti fai una suite di test più o meno robusta e quindi non hai bisogno di portarti questa roba sopra che devi comunque mantenere.Quale può essere la risposta a questo tipo di obiezione dal tuo punto di vista? Ma allora è un argomento molto dibattuto ovviamente è un argomento su cui secondo me è difficile, come in tutti questi dibattiti, trovare quella che è un po' la nuance, la sfumatura dell'argomento.Dal mio punto di vista dire "ma sì, basta che riempi tutto di test" è come dire "vabbè, ma in macchina non mettere la cintura, basta che riempi di polistirolo la macchina così quando vai a sbattere sei già nel polistirolo".Cioè nel senso è vero, tecnicamente chiunque abbia programmato lo sa che non è vero che la suite di test copre ogni centimetro quadrato della codebase, che scrivere test è oneroso perché è un lavoro che richiede effort e che quindi uno deve ragionare su quali sono i trade off di effort che vuole spendere per scrivere dei test o scrivere dei tipi.In più non si sovrappongono completamente, Quindi, lungi da me dire che non servono i test, i test servono.A me piace avere delle codebase dove i test sono significativi, dove aggiusto un test perché ho cambiato un behavior o ho introdotto un bug.Non ogni singola cosa che cambia e devo andare ad aggiustare tutti i test.Testare if is integer.Esatto, come regola buona, se tu ogni volta che tocchi qualcosa devi cambiare anche i test, vuol dire che tu sei fortemente accoppiato con i test e quei test non servono a granché, da questo punto di vista mio sul testing.I test buoni stanno fermi e tu muovi la tua codebase e non li spacchi, in teoria.A meno che non fai cose che si devono spaccare i test, ovviamente questo va da sé.La seconda tematica è che ci sono certi tipi di analisi statiche che tu fai sulla tua codebase usando un type system che è molto difficile da replicare coi test.Per esempio la visibilità a livello di intero sistema, se tu stai scrivendo degli unit test, fai fatica a farla.Gli input e gli output di una funzione ok, ma un type system ti dà un'abilità immediata e con un feedback loop molto veloce rispetto a un sistema molto grande per cui magari un test invece ci metterebbe banalmente molto di più anche a livello di developer experience.Tutto questo aggiungendo fatto che i test ti danno anche altri benefici riguardanti.La documentazione, perché io quando, io sarò strano io, ma io leggo un sacco di codice dal mio cellulare, faccio review sull'app di github, quando io vedo una funzione che so che cosa entra, cosa esce, non me lo devo inventare con un'Ibe o rannare un test a interpretare quello che sto leggendo, quindi leggere codice che ha dei tipi annotati è utile alla mia testa, perché non mi devo inferire delle informazioni dal contesto, e poi questo va da sé, da potere a IDE, cioè un IDE non si deve inventare, nemmeno lui, quali siano i metodi che puoi chiamare su una cosa, ma sono dati dal type system e questa cosa viene spesso citata come vantaggio di TypeScript, è effettivamente lo è, cioè scrivere tool.Io sono uno che di mestiere scrive anche un sacco di tooling, il mestiere non è vero, di notte, sono anche il maintainer di un language server di scala e quindi so cosa vuol dire lavorare con linguaggi e tipi di dati per un IDE e senza i tipi è un casino e infatti le soluzioni senza i tipi richiedono grossi sforzi per cercare di capire vagamente dal contesto quali sono le cose in scopo eccetera eccetera.Fantastico, sei arrivato proprio a uno dei punti che volevo provare a vedere con te.Una delle cose che mi dicono sempre è quella di "eh vabbè ma oggi abbiamo dei linter abbastanza intelligenti che riescono davvero a dedurre comportamenti e ci correggono in una fase di scrittura codice quando siamo sul nostro editor o sul nostro IDE".Perché? Qual è il plus che un sistema di tipi che poi a build time sparisce ci porta in più rispetto a un ESLint che è molto potente da quel punto di vista? Dipende un po' da cosa ci fai.La mia risposta è che ESLint è un bellissimo tool di cui io scrivo un sacco di plugin e mi diverte tantissimo.è estremamente limitato nell'analisi statica che puoi fare.Cioè la gente ci ha fatto cose pazzesche ma dei costi assalucinanti che in un typescript sono una banalità atroce.Quindi a un certo punto devi anche capire qual è l'investimento che tu vuoi mettere nel tool rispetto a quello che ne tiri fuori.Per fare alcune cose di typescript, tipo controllare, non lo so, mi sta venendo in mente degli utilizzi che faccio io nella mia vita di tutti i giorni, di librerie che scritto anche io eccetera, farle con ESLint non avrei neanche la più paura di vedere dove partire, non sono neanche sicuro che si possa fare.Cioè, intendiamoci, è un'esperienza di utilizzo infinitamente più...Provo a riformulare, ESLint è un tool di supporto che ti cerca di forzare delle linee guida e prevenire alcuni errori.Fortunatamente negli ultimi anni si è perso l'utilizzo di ESLint come formatter grazie a Prettier e compagnia bella e dal mio punto di vista ci sono tutta una serie di cose di ESLint che vengono così come quelle di formatting sono state delegate a Prettier vengono meglio con TypeScript.Ma ti dirò di più, scrivere con un linguaggio che ha dei tipi dovrebbe e lo diventa dopo un po' evidente, diventare uno strumento di design, non uno strumento per impedire degli errori.Tu dovresti, e io lo faccio spesso, ragionare sui tipi in input e in output per fare un design della tua applicazione e dopo ragionare un attimino su come implementare le cose.Ma se tu ragioni così ti permetti di scrivere applicazioni che sono molto disaccoppiate, molto mantenibili.È proprio una visione un po' distorta quella del "ti previene gli è un po' diverso, esprime dei vincoli e li controlla in automatico, ma i vincoli li devi scrivere te, cioè il tuo lavoro da programmatore, quindi capire cosa entra dove, dove si dividono le cose.Yes, l'Inter gioca un'altra partita, è una partita importante, che è quella di creare delle convenzioni stile, prevenire qualche errore, ok, ma è un tool complementare, non so se mi sono spiegato perché è stato chiaro, ma è quello che viene chiamato un po' type driven design, cioè così come puoi fare TDD dove scrivi il test e poi implementi la cosa, quali idee hai? Tu scrivi la firma di una funzione e dici ok a me serve una funzione che prende questa roba in input, la lavora e mi torna questo output.Questo dovrebbe essere il modo in cui scrivi codice.Cambia un po' la mentalità del modo di pensare del classico sviluppatore javascript che spesso è legato molto ai comportamenti e un po meno ai dati, proprio come forma mentis no? Adesso sto generalizzando, non me le vogliate, però solitamente il programmatore javascript o anche un po più, anche il programmatore python è concentrato molto sul comportamento, forse un pochino meno consapevole, comunque meno focalizzato sul dato che entra.Quindi l'utilizzo dei tipi in qualche modo ti obbliga a ragionare proprio in funzione di dato che entra e dato che esce? Più che ti obbliga, ti dà la possibilità di farlo in una maniera che funziona.Io spesso mi trovo a scrivere la firma della cosa senza implementare la funzione perché io vedo la mia codebase come sostanzialmente una grossa manipolazione di dati, ma quasi tutte le codebase le puoi modellare così.Però è uno shift mentale, cioè uno shift di paradigma.Io lo reputo molto efficace e anche efficiente, nel senso che ti velocizza, secondo me, il modo in cui scrivere applicazioni.Non è l'unico, ovviamente, e anche con TypeScript tu puoi tranquillamente scrivere le tue implementazioni, farti inferire i tipi e usarlo un po' come se fosse JavaScript.Secondo me in quel caso lì inizia a venire un po' meno il vantaggio che ti fa vedere il TypeScript.Quindi se lo usi come un JavaScript class dove metti il tipo di ingresso ti stai perdendo una grossa fetta dei benefici.No anche perché puoi fare una codebase JavaScript farci girare TSC sopra e lui i controlli te li fa uguale.Mi riaggancio a una cosa che dicevamo prima correttamente dal mio punto di vista, il fatto che quando è una codebase molto grande TypeScript ti aiuta.Io scrivo tante piccole utility, piccole CLI, dei piccoli tool interni, eccetera, e ogni volta io ho questo shift mentale.Parto e dico "ok, vabbè, sti cazzi, lo scrivo in JavaScript, che voglio cioè di mettermi via e configurare il trasply, lo scrivo in JavaScript, scrivo 50 righe di codice, 100 righe di codice, devo fare un refactor e dico "cazzo, adesso devo fare un refactor? Io voglio, cioè, non so, lui aveva un booleano perché come al solito si predica bene e si razzola male, ha un booleano, dico no, questo booleano deve diventare un oggetto di configurazione.Tu ti assomigliano un oggetto, cambi le tre cose che ti ricordi, non va nulla perché ti sei scordato una.Ecco io lì mi pianto giù e inizio a scrivere i tipi di tutto quanto.Piuttosto glieli scrivi, come dicevi giustamente tu, facendo un'altra infezione, senza il tooling.TypeScript ha questa modalità pazzesca dove puoi mettere i tipi nei commenti e funziona tutto out of the box in VS Code, che usa la sintesi GSDoc, quindi volendo puoi scrivere tranquillamente una codebase in TypeScript senza scrivere file TS o configurare niente.Quindi tutto questo è per dire che TypeScript è uno strumento fondamentale in generale quando devi fare un refactor, secondo me.E nella fase iniziale creativa di qualcosa, il refactor li fai costantemente, perché "Ah, cacchio, qua voglio un oggetto.No, aspetta, sta funzionando così.No, cambia l'idea, faccio cos'ha".Tilesket ti aiuta a tenerti concentrato perché ti dice "Ah, aspetta, quelle sono le tre cose che devo sistemare".Bam, bam, bam e torni in flusso.Se tu avvii l'applicazione, esci dall'editor, vedi se va, metti un console.log, metti un breakpoint, "Cosa stavo facendo?", ti perdi, ti tiene in flow.Cioè, sembra controintuitivo, ma il fatto che c'è uno che ti bastona subito sulle cose ovvie ti tiene in uno stato di flow, dal mio punto rivista.Faccio questo errore ogni volta, io sono il primo a usare JavaScript e invece no, su Google Base da 100 righe.Vero, vero, io sto rimettendo mano a un progettino che utilizza RAMDA, fatto in JavaScript senza tipi e tipo voglio morire ogni volta che ci metto le mani.Io ci pianto dentro, mi sento stupido, ci pianto dentro una quantità di errori che c'è, vien da piangere ogni volta, ma è perché inizia ad abitu...cioè è come guidare col servo sterto e poi un giorno ti danno una panda del 92.Non è che non sapevi guidare quella macchina lì, è che ti sei talmente abituato a una cosa ovvia che non sei più allenato.Quindi è proprio una questione di abitudine.Chiaro che da tutto il discorso che hai fatto emerge un po' l'animo da functional programmer Tra l'altro io ricordo il primo corso di Odeski che hai citato, tra l'altro era Functional Programming in Scala.Era un corso su Scala ma citava anche alcune cose di Functional Programming.Adesso ci sono dei corsi un po' più targettati su Functional Programming.Il primissimo che ho fatto io era praticamente una copia del libro di Scala che non era tanto orientato a Functional Programming.che c'era la T-Recursion, c'era tutta la parte di composizione...Sì, ci sono degli elementi in scala per fare functional programming, diciamo.Però poi in scala puoi farci cose, ho visto gente implementarci emulatori di Commodore 64 usando niente di immutabile, tutto immutabile con...Sì, sì, quello ne parliamo dopo perché voglio dedicare anche un angolino, ormai lo sapete il mio amore platonico verso scala anche se in realtà non mi ci sono mai messo seriamente però da quello che dicevi e da come parlavi del tuo approccio allo scrivere codice emerge un po l'anima functional no? Si ammetto.E domanda se in javascript qualcosa di functional che fa ridere come la composizione, come...queste piccole cose si possono fare.Cosa si può fare di functional programming con TypeScript grazie al Type System? Fino a dove ci si può spingere? Allora, molto lontano ma non senza sofferenze.Allora, facciamo una premessa.Java è un linguaggio che di per sé striscia già un po' l'occhio a concetti funzionali, nel senso che è un linguaggio che dal giorno zero ha avuto funzioni come First Class Citizen, poi le funzioni sono oggetti che tu puoi maneggiare, ritornare, usare.È una cosa non banale.Oggi è ovvio quasi che è un linguaggio di programmazione, ma Java non ce l'aveva fino a Java 8 e comunque anche adesso sono un po' incastrate nel linguaggio in maniera strana le lambda per intenderci.Cito anche il fatto che tu puoi fare tranquillamente functional programming per una definizione di functional programming che adesso cercherò di dare, anche senza tipi, sono linguaggi che prosperano di questa cosa, guarda Closure o guarda linguaggi che sono linguaggi senza tipi che spingono il functional programming.Detto questo, secondo me è un esercizio un po' pericoloso, è un esercizio che a me non piace particolarmente, però sono il primo che può avere torto.Con i tipi puoi andare un po' più in là.Perché? Perché quando ti spingi su certe sacche del functional programming, tipicamente tutto ciò che riguarda l'aspetto di categorie di teori, l'aspetto di modellare strutture dati complesse in functional programming, hai tanti tanti vincoli e tante leggi da rispettare per far funzionare le cose in fila e se non hai un type system che te le controlla auguri.Però questa ci tengo a precisare è una delle possibilità di functional programming perché functional programming, provo a definirlo, dal mio punto di vista vuol dire ragionare al tuo programma come se fosse un'espressione.Quindi, dopo questo si porta dietro tutta una serie di cose, ma l'aspetto principale che io trovo in functional programming è l'aspetto di poter sostituire un'espressione con la sua definizione, che è un aspetto che sembra banale, ma che ti previene pattern tipo x=x+1, che non vuol dire niente nel concetto di sostituzione.Tutti i concetti di functional programming che vengono dopo nascono da questa intuizione qua, perché se tu vuoi trattare il tuo programma come un'espressione, le espressioni che producono altre cose devono essere pure, quindi è che devo poter realizzare il "body" della funzione con la cosa a cui l'ho assegnato.E quindi che cos'è questa proprietà? Si chiama "referential transparency".Ah, ok, ma quindi facciamo le cose da "referential transparency".Ah, ma come facciamo a gestire lo stato? Allora te lo devi portare in giro, ma è scomodo.Allora ti serve una strazione tipo le monadi che ti consentono di portarti in giro del contesto in una maniera che ti nasconde un pochino la complessività di farlo.Cioè è tutto derivato da lì.Però, e dopo lo citerò se riesco, il fatto che in Infection Programming si parla di monadi e di cose anche più complicate di quelle è derivato che i paradigmi vanno lì.È come dire che siccome tu scrivi il codice imperativo, allora devi conoscere il Flyway o tutto il libro della Gang of Four, con tutti i pattern.No, ci siamo arrivati per sostanzialmente engineering perché è una roba comoda e abbiamo sfruttato nel caso di functional programming, anche che il sapere popolare di ingegneri molto bravi, alcune robe che arrivano dalla matematica.Ok? È un modo molto lungo per dire che tal da qualche strumento in più di javascript per arrivare all'anno, detto questo, per quello che è inteso la programmazione funzionale moderna, a un certo punto si ferma e si pianta molto duramente, cioè diventa un esercizio un po' complesso fare cose veramente importanti in functional programming in TypeScript, nonostante gli encomiabili sforzi di persone tipo Giulio Canti, che per chi non lo conosce è sostanzialmente la persona più attiva credo nella metodologia functional programming su TypeScript al mondo, credo, e ha prodotto librerie bellissime come FPTS che porta tanti concetti da categorie teori all'interno di un linguaggio.Noi lo usiamo per lavoro, codebase su cui lavoro giornalmente 300-400 mila righe di codice fatta tutta con FPTS, si usa, è pratico ed è utile, up to a point.Dopo un po' che lo usi devi invogliare, usare un linguaggio dove queste cose sono un po' più native, senza andare su robe esoteriche o strane, ma anche solo Scala o anche solo Swift per dire se a qualcuno piace il mondo iOS è un linguaggio molto votato, questi concetti qua.Ah sì, lo so che pensi, io non conosco Swift.Swift è un linguaggio che ha, in una maniera molto novella, ha inventato alcuni concetti, ma sostanzialmente è figlia del suo tempo.Swift è nato in un momento in cui i concetti di Fragment of Programming andavano molto forte, in cui Java stava andando già verso una direzione molto precisa di introdurre sempre di più cose.Adesso Java ha introdotto il pattern making, l'ultima versione di Java 17 o dove siamo arrivati.E Swift ha ereditato un sacco di piccoli concetti, portandosi dietro Objective C, che è un linguaggio che è stato il mio primo amore.È una sindrome di Stockholm Objective C, ma è stato il primo linguaggio che ho...Io sono ancora innamorato di Objective ma mi rendo conto che sono solo io al mondo.Io ci ho besticciato male e ha vinto lui, quindi.Io ho programmato per sei, sette anni in Objective C nella mia vita, quindi ne conosco abbastanza dentro e fuori.Swift si è portato dietro Objective C perché ha dovuto fare delle scelte per portarsi dietro quello, quindi ha delle robe che tu dici "che cos'è sta roba?" e dici "ah, aspetta, per un programmatore Objective C che deve passare a Swift questa roba ha senso".però adesso non voglio parlare solo di Swift ma è un linguaggio bellino.Tutto questo per dire che sì, si può fare per fare il documentario, perché sì, lo si fa, bisogna dargli la definizione corretta.Se vuoi spararci cose estremamente complesse, forse non è il linguaggio giusto, bisogna fermarsi.E' arrivato il momento di ringraziare i nostri donatori, gli ascoltatori che in qualche modo danno il loro contributo per aiutarci a raggiungere il nostro ambizioso obiettivo che è quello di acquistare dei nuovi microfoni per gli ammortizzanti e questa settimana devo ringraziare Smilzao che ci ha offerto 5 birre è da un po' che vi ho scoperti e sono su Telegram Smilzao è il momento di contribuire nel mio piccolo a fare un bar migliore non potendo portare sapienza vista la mia agnubagine porto una parte di microfoni ancora complimenti e prosit e noi brindiamo alla salute di Smilzau ringraziandolo nuovamente per queste birre che ci ha offerto donazione che ci aiuterà ad acquistare a brevissimo il primo microfono mi raccomando se volete essere parti di questo ambizioso obiettivo donate La mia domanda è, visto che tu dici noi facciamo functional programming nel front end, utilizziamo FPTS abbondantemente, la mia domanda è lo porteresti nel back end? Sì, fatto assolutamente.Ogni tanto scriviamo anche delle cose in Node.Sì, diciamo che sul back end viene un po' più semplice dal mio punto di vista.Perché? Perché, allora, sostanzialmente il concetto di functional programming, se tu vedi il tuo software come un'espressione, a un certo punto devi farla girare, questa espressione, se no scambi calore con l'esterno, non fai molto altro.Quindi, tipicamente, il modello che uno ha in testa di functional programming è "io costruisco un'espressione alla fine del mondo", tra virgolette, "la interpreto".Se tu hai in mente un backend, tu puoi tranquillamente dire "vabbè, quando l'app parte, costruisce tutta l'espressione e poi, magari, non so, quando serve una richiesta HTTP, la eseguo.Questo è intuitivo.Il concetto di un mondo, in alcuni linguaggi di programmazione tipo Haskell, è addirittura nascosto al programmatore.È il runtime stesso a cui viene data una struttura dati e il runtime di Haskell la esegue, quindi addirittura fuori dal controllo del programmatore, l'esecuzione.Se tu finisci in un mondo dove le fine del mondo sono mille, devi costantemente entrare e uscire dal tuo concetto di "il mio programma è un'espressione".Esempio, in React, che è un linguaggio che non è basato su stream o su concetti funzionali, ma è basato principalmente su eventi, ogni volta che un utente clicca su una cosa, la tua bella espressione la devi eseguire.Quindi ogni handler, ogni qualunque cosa che devi fare all'interno di un hook, cose così, una fine del mondo e quindi tu ti trovi per quanto sia comunque utile e comodo costruire funzioni con un concetto di function programming devi costantemente eseguirle e uscire mentre sarebbe concettualmente possibile e lo fanno alcuni framework tipo cycle.js o cose di questo tipo modellare tutto l'interazione come una grossa espressione però è un paradigma estremamente poco diffuso e poco familiare nel contesto del front end per esempio.Eppure sai io io percepivo un po' un occhiolino di React verso il mondo della programmazione funzionale con i functional components, con il fatto di in qualche modo anche un po' rozzolino di inglobare lo stato con gli effetti, con gli hook, non lo so.Allora sì, come dicevo prima, la programmazione funzionale sostanzialmente poi apprende delle derivanti con quella di Clojure molto diversa da quella di categoria, intesa come categoria di teori di Haskell o di...in scala ha preso un'altra ancora un'altra forma che a volte scimmiotta un po' quella di Ask che a volte va verso direzioni un po' più problematiche dal punto di vista di scala.Quella di React, il team di React che alla fine sono persone note, che personalmente seguo su Twitter, sono 5-6 persone, sono molto influenzate da contacti di functional programming ma vivono in un ambiente che è il front end, che è React, che è comunque fondamentalmente formato da persone che non si rofilano, che non gestiscono i contacti di functional programming, quindi si ogni tanto ci infilano nelle cose, ma in un contesto dove alla fine React è basato su 20, cioè quindi bello use effect, concettualmente carino, ho capito gli algebric effects, ma non è vero, nel senso sono influenzati da quei concetti lì, ma poi il modo in cui si materializzano sono comunque molto poco effettivamente functional programming.E come vedi i linguaggi tipo ELM o Reason? Ma allora, sono molto belli, molto interessanti, sono degli esercizi di fare veramente quelle cose.Poi li conosco abbastanza poco.Elm va molto più nella direzione che dicevo prima di creare appunto, beh, alla fine Cycle.js, Elm più o meno vanno con tutte le molle del caso in una direzione simile.Quello è un modo.Il mio parere, ma questo è un parere non da nerd, ma da "engineering manager", è che comunque hanno un'adoption abbastanza piccola, per fatica a trovare persone e comunque ti stai mettendo in un sacco di altri problemi che devi considerare molto attentamente, che sono i trade-off, che è quello dell'interno per la vita con il resto del mondo.La cosa bella di TypeScript, che è il motivo per cui l'abbiamo scelto, tra l'altro, rispetto a tipo, non so, lo facciamo in scala JS, al di là di motivi tecnici, è che è un layer abbastanza piccolo che non ti previene quasi mai l'interoperability con il resto di JavaScript.Quando inizi a andare su Reason, io ho impostato una toolchain in Reason qualche anno fa o due o tre anni fa, quando era agli inizi, e non è TypeScript dal punto di vista dell'interoperability.Quindi sì, belli, ma finché devi interoperare col mondo JavaScript, meglio stare il più vicino possibile a quell'ecosistema lì dal mio punto di vista.Anche per trovare sviluppatori, onestamente, perché già devono trovare quelli Scala.Che è un problema quanto se non più forte del problema tecnico, perché noi non dobbiamo mai dimenticare che noi siamo là e facciamo il nostro lavoro perché dobbiamo generare valore e tu da co-founder questa cosa la percepisci.Io ho questo problema esatto, che io sono sia quello che fa le assunzioni sia un nerd a cui piacciono un sacco i linguaggi di programmazione, quindi è chiaro che se fossi da solo mi farei cose più esoteriche però devi anche considerare che se stai costruendo un team, un progetto eccetera e li devi anche proporre ai clienti perché noi facciamo consulenza, non puoi andare lì e dire ti faccio le cose in crystal, che è un faggio interessantissimo sull'AJVM, ma c'è anche il mondo vero.Esatto, quando esci dalla sala giochi possiamo iniziare a parlare.Allora la mia domanda è giusto credo di chiudere qua con TypeScript.Domanda ma così abbruccio appelo Vendor Lock-in ti spaventa è un problema non è un problema? Da che punto di vista dici di Microsoft? Di Microsoft.Ma allora è sempre un tema interessante interessante.Onestamente mi spaventa meno Microsoft di qualunque altra big corp, cioè mi spaventa di più React di Microsoft, se devo essere sincero.Perché? Perché Microsoft ha una storia di developer tooling e developer, in generale developer toolchain, estremamente buona, cioè tutto ciò che gira intorno al mondo C#, nonostante sia un mondo che io non conosco benissimo, ma se ne apprezzano bene anche da fuori il fatto che i developer Microsoft sono contenti, deve attucciare Microsoft, sono contenti di C#, sono contenti di usare il VideoStudio e questa cosa va avanti da anni e anni e anni.Microsoft è un'azienda abbastanza seria a riguardo e quindi se la paura che poi ad un certo punto TypeScript viene mollato a piedi.Sì, certo, tutto può accadere, può anche succedere che ora colmolli Java, però diciamo che mi mette meno ansia dell'usare un prodotto di Google, per dire che invece è una denda nota per discontinuare ogni cosa che crea, dai prodotti consumer alle tecnologie, perché piccola nota di colore, tra l'altro Angular all'epoca doveva avere il suo linguaggio tipizzato che era ATScript che poi è andato a convergere in TypeScript.Quando hanno lanciato Angular 4 hanno deciso di usare TypeScript e non il loro linguaggio ATScript.Esistito però un totling di Google che faceva la stessa cosa di TypeScript, Competitor, che Google ha prontamente abbandonato.Cioè Google crea roba che chilla dopo un anno o due.Basaci il business su quello.Eh? Basaci il business su quello dico.Eh, cioè in un certo senso sì, sarei molto molto molto più in ansia di usare quello, per quanto riguarda React è talmente usato che non mi preoccupa troppo, però comunque il team di React credo che sia estremamente più piccolo del team di Type, per esempio, anche a livello di effort, di lavoro che ci mettono su.È comunque fondato da un'azienda che è Facebook, il cui team open source non ha una super storia di mantenabilità neanche lì, guarda Flow, un bot di progetti regato al mondo React, tipo, non so, così è Cito a memoria, Fixed Data Table, tutto ciò che riguardava la manutenzione dello stato, per cui tutti i vari, o di come si chiamano, non mi ricordo neanche più, tutto ciò che era intorno a Flux.Facebook ha buttato fuori un sacco di roba e se ne è appiccicata qualcuna reatta a una rara eccezione nel contesto.Quindi risposta, hai paura di avere un lock-in? Sì, sempre.Hai paura che Microsoft moglia di scrivere meno di altre cose di cui ho paura? No, è un po' la cosa che comunque in qualche modo tranquillizza sta nel fatto che è veramente un attimo trasformare una codebase typescript in javascript quindi c'è.E tra l'altro puoi farlo in un tool automatico quindi.Se proprio devi, beh è quello che fa il compilatore.Se tu imposti i typescript su ias next, l'unica cosa che fai è rimuovere i tp e tutto ciò che riguarda typescript senza toccare una riga del resto quindi sì si fa.Sarai triste se dovessi farlo a un momento ma...chiaro chiaro adesso però tu che sei scalista e non nascondi una certa attrazione verso il mondo typescript facciamo proprio la becera giocata del venerdì sera al bar se dovessi ragionare in termini di back end visto che mi ha detto che comunque lo useresti anche nel back end e ci ci mettiamo Scala da una parte e TypeScript dall'altro.Cosa ti spingerebbe a scegliere TypeScript? Ma allora, premesso che questa è una scelta che io ho già fatta, tutto l'azienda di cui sono socio usa Scala per backend e usiamo TypeScript per frontend, quindi è un tema.Il tema per cui si propende potenzialmente verso TypeScript e potenzialmente lo consiglierei anche, dipendentemente dalla situazione del team, è che ti permette di fare tante belle cose per il fatto che il linguaggio è lo stesso.Start from the end, back end.Per esempio, puoi condividere i modelli, puoi fare cose che noi abbiamo fatto nei progetti dove abbiamo usato Node.Edge e TypeScript, quindi autogenerare, per dire, i client e i server a partire da dei modelli dati.C'è un talk, tra l'altro molto carino, del Giovanni Gonzaga, mio socio, che parla esattamente di questa cosa, cioè fare full stack type safety tra node e React, o un frontend in generale.Quindi, quello è un aspetto molto bello, perché è una tecnologia coesa e puoi sfruttarne al 100% i benefici se sei bravo.Fine dei benefici dal mio punto di vista.Cioè, nel senso...Nel momento in cui non sei più vincolato a un browser, onestamente a me l'ecosistema JVM, che se ne dica piace di più dell'ecosistema di Node.È molto più maturo, anche a livello di performance la JVM va nettamente più forte quando è ottimizzata giusta rispetto a un server Node.Ovvio che se fai le cose bloccando ogni thread è inutile, però se tu scrivi un'applicazione moderna, anche con Java, vai forte e in più hai un ecosistema ricco, pieno di cose.Ecco l'unica cosa che non mi piace è il linguaggio Java e quindi Scala.Perché Scala e non Kotlin? Innanzitutto Kotlin è un giovincello per quello che mi riguarda, nel senso che è un linguaggio nato molto dopo, quindi io ho già scelto la mia strada su Scala.Kotlin è un linguaggio interessante in realtà, va a pescare nel punto giusto che è "ok, possiamo fare Java un pochino meglio, ma senza andare a pescare cose complesse tipo Scala.Quindi ci sta al suo posto.Fun fact, Martino Derschi ha creato un linguaggio che si chiama Pizza, di cui credo conosciamo in pochi affezionati, negli anni 2000, forse fino al 1999, che era più o meno esattamente quello che...no, non esattamente, era un tentativo come spirito di tipo Kotlin, un po' Java plus plus.Tra l'altro ricordiamo che Odersky era nel team che ha introdotto Generic Java, quindi è una delle persone che ha introdotto Generic in Java e poi ha detto "bello, possiamo fare la stessa cosa non in Java per favore" e quindi ha fatto questo pizza che poi dopo è stato un esperimento accademico da cui è nato Scala.Scala ha preso una deriva molto più estrema, ha introdotto concetti molto nuovi e ha avuto anche un bel riscontro industriale e quindi siamo qui a parlarne.Quindi sì, Kotlin ci sta, lo suggerirei se proprio non ti piace Java e vuoi comunque non andare troppo in là.Ha delle cose particolari interessanti di cui io conosco molto poco, ha anche una bella community functional programming.Sì, tra l'altro uno dei nostri host è il maintainer di MockEy che è il tool di mocking di Kotlin.E mi raccomando, Octoberfest contribuite perché Mattia desidera contributors, ma lo dico per tutte le codebase in generale.Mi ero quasi scordato che c'è l'Octoberfest, devo andare a vedere quanti pure questo andrò a girare.No, comunque Kotlin io seguo con attenzione tutta la community Arrow che è tutto l'aspetto functional programming che addirittura contribuisce molto anche al linguaggio stesso ed è una comunità molto carina, il linguaggio è nato nel contesto di JetBrains che sono molto bravi a fare tooling, quindi ha un tooling eccellente, è un linguaggio da valutare molto seriamente.Sì, sì, no, assolutamente, questo Mattia ce lo ripete praticamente tutti i giorni, quindi… Se le alternative è Java, qualsiasi cosa, no, è facile dirla dietro a Java, poverini che stanno facendo il lavoro della madonna in realtà.Sì, vero, vero, io ho visto delle evoluzioni.Adesso però voglio fare l'avvocato del diavolo, siccome ogni tanto le sento le madonne che tira mia moglie quando fa le cose, ti dico i pain point di scala invece oltre al build time, oltre al build time che ormai è un problema risaputo, che se bt tipo vai a buildare fai il pranzo e poi torni.Sì, tra l'altro, va beh, lì è un po' anche una...è vero, ho visto Codebase TypeScript e metterci tantissimo comunque in tutto questo, ma dipende un po' quante grossa...dipende un po' cosa ci fai.Ci sono stati dei trend in scala che non hanno aiutato, tutti i trend di macro più espansione implicita portavano spesso a delle situazioni patologiche che adesso un po' per come si è evoluta la community, un po' per maturità di certe visioni non si verificano veramente più così tanto, quindi è un po' migliorato anche da quel punto di vista ed era tra virgolette "colpa degli utenti", nel senso che era molto facile scrivere codici che ci metteva tanto a compilare, per intenderci.Comunque, detto questo che è assolutamente vero, altri pen point secondo me, il principale di Scala è che Scala è un linguaggio estremamente potente, ma molto potente, che è molto bello se sei molto esperto.Se non lo sei ti fucili dopo due secondi perché puoi sbagliare qualsiasi cosa e non sempre gli errori, per quanto ci sia stato un grande lavoro anche sugli errori in scala, sono molto semplici e intellegibili.Introduce dei concetti che sono nuovi nel concetto del linguaggio di programmazione.Il concetto di implicit chat timidamente in alcuni linguaggi è un concetto estremamente competitivo, potente, estremamente usato male, che infatti in scala 3 è stato molto normalizzato, è stato riportato su dei binari molto più comprensibili, molto più settoriali, quindi non è un tool che fa tutto, ma è molto più spezzettato.A chi ha provato scala 2 e scappato piangendo, suggerirei di guardare scala 3, perché c'è molto di buono da quel punto di vista.Ho fatto un bel ragionamento negli ultimi 8 anni, perché è un sacco che sviluppò e è uscito quest'anno.Diciamo che Scala lo consiglierei per un team che ha voglia di diventare esperto di Scala, non per un team che ha un alto turnover, che deve fare le cose in fretta e che lo uso su questo progetto e poi fa altro.Se dovessi creare da zero un team di 200 persone che per una grossa azienda non sono sicuro che lo userei, a meno di volerci investire veramente tanto.Detto questo ci sono grosse aziende che lo fanno, lo fanno, che è tutto presente in Disney+ e Disney+ è tutto in scala.Quindi, cioè, ci puoi fare delle cose estremamente fighe e complesse.Nelle puntate precedenti...Molto zen secondo me.E la prima è "cos'è un pacchetto?" Cioè, la derivation risponde alla domanda "cos'è un pacchetto?" È fisicamente un pacchetto.Questo pacchetto azionato! Ma che cos'è un pacchetto azionario? È fisicamente un pacchetto o no? Si spacca spacca sfuggi Chiaro, no, mi chiedo in realtà Scala in qualche modo viene accomunato alla Functional Programming però Scala è anche un linguaggio un po' ibrido nel senso che puoi fare anche programmazione oggetti te lo vieta e voglio portarti davanti a questa situazione se ti è mai capitata.E' un'esperienza che ha fatto mia moglie, io adesso metto lei a nudo, tiro via tutte le sue esperienze, però è stata particolare da vedere.Praticamente lei è arrivata in questa azienda, una azienda abbastanza grossa, una multinazionale, e ha iniziato a scrivere Scala con un approccio un po' functional.il team lead del suo team l'ha ripresa tra virgolette nel senso che comunque era figo il codice che stava scrivendo ma di riportare tutto a C4 e a IF, adesso sto banalizzando, perché c'era un grosso problema di comunicazione col team.Questa anima bivalente di Scala può essere il suo limite proprio in queste situazioni? Sì, assolutamente lo può essere.È un punto di forza così come un punto di limite ed è un po' il concetto di Scala.Scala è un linguaggio che per sua natura non è molto prescrittivo, è molto ambivalente, è così by design perché Oderski ha deciso che il mondo deve funzionare per la fusione di functional programming e object-oriented programming.Di solita ragione lui, nella storia dei linguaggi di programmazione, non è esattamente una persona a cui dare il torto molto in fretta.Però sì, certamente, il fatto che ci siano tanti tanti possibili stili diversi è uno dei motivi, cioè è praticamente il contrario di Go.Go è un linguaggio di programmazione che è stato ingegnerizzato per essere estremamente semplice, estremamente avere un modo, possibilmente uno solo, di fare una cosa, non fa un tubo, è il vero ed il difficile del linguaggio di programmazione, ed è fatto per farci dei grossi team di engineering, a Google possibilmente, però poi l'hanno usato anche fuori da Google.però è la scala dell'antitesi, è tipo proviamo a vedere se questo esperimento funziona, cacchio funziona, si possono fare un sacco di cose belle, ma il prezzo da pagare è che puoi farci veramente tante tante cose diverse, tante stile diversi.Detto questo io non è che reputo necessariamente negativo il fatto che uno usi scala produttivamente scrivendo codici non in maniera funzionale.In Java way diciamolo pure.Puoi farlo, hai i benefici, almeno hai un po' meno che se facessi altrovece, a quel punto valuteresti realmente Kotlin o Java.Ma questa è una cosa che dico sempre, non è che c'è la cosa giusta, se tutto il tuo team fa così, tu fai diverso.Se sbagliano te, cioè, a meno che non convinci il team a fare diverso, ma se tu arrivi e scrivi una pure quest che non c'entra un tubo con quell'altro, è un problema più di team leading e engineering, in quel caso lì, e di trasmettere cos'è che facciamo in questo posto.Il modo in cui è fatto.A Build si scrive codice in un certo modo e la gente arriva qua e impara a scrivere codice in un certo modo.Funziona perché per noi funziona.Quando vado a fare consulenza da altre parti io scrivo codice magari in un altro modo.È un po' il senso della cosa.Scala, sì, è una limitazione e anche punto di forza perché ho visto Tim iniziare a scrivere cose in un certo modo e poter evolvere nel contesto del linguaggio in un altro.Mentre per dire in TypeScript tu dici "io inizio a scrivere in JavaScript, mi appassiono a Functional Programming e poi mi prendo un muro in faccia perché dopo un po' non ce ne ho mai più".Scala no, scala ti accompagna volendo verso scrivere cose.Poi dopo quegli estremi dicono "eh no basta serve a altro".Infatti la mia domanda era "ma se proprio devo fare Functional Programming perché non Askel.Adesso va bene, la stiamo buttando veramente su.No, lo so, lo so.Io passo le mie conferenze a discutere di queste cose.Sostanzialmente Askel è l'estremo opposto di un linguaggio oggetti, perché è un linguaggio estremamente funzionale, estremamente...Certo, puoi assolutamente imparare a nuotare, lanciarmi in un oceano a quattro anni.A meno che non sia la prima cosa e l'unica che hai imparato nel tuo percorso di imparare a diventare un programmatore software, se tu arrivi come è più normale, non universale, ma più normale, arrivi da un paradigma più imperativo e meno funzionale, approcciare Askel è un po' faticoso da zero.Quindi Scala è un po' lì, un po' salomonico, un po' neutro, ma sì, vabbè, vuoi buttarci dentro una barra, buttaci dentro una barra.Non te lo consiglio, ma buttaci entri in una barra e fai tutta la mutabilità che vuoi.Poi dopo vuoi scrivere i codici con le monadi colorate di blu, magnifico lo puoi fare.Chiaro che essendo un po' in mezzo, non è che la sua forza sta nel mezzo.Se tu dici io voglio scrivere codice solo da ivory tower category theory, ho il cappellino con scritto "viva le monadi", allora scrivi direttamente Robin Asker, sono d'accordo con te.Però non hai più quella flessibilità lì, perché se dopo devi onboardare un collega che vuole fare un print line e non sa come si fa, aspetta che ti spiego la monada io per fare un print line e diventa un po' faticoso.C'è un post e un tempo per tutto, adesso io non voglio insultare nessuno a nessun tipo di scelta, però bisogna prendere scelte per il contasto che si prendono.Qua sta uscendo l'engineering manager, il founder che sta dentro di te, questo pragmatismo viene un po' da quel mondo no? Sì sicuramente, divertirsi con delle cose e costruire un team produttivo su una cosa sono due cose spesso diverse, l'ho citato anche prima.E voglio arrivare a quello infatti, una domanda molto intimista, nel senso come riesci a far convivere i due animi senza uscirci fuori di testa? io ho indossato entrambi i cappelli però li ho indossati in periodi diversi, io fino a un anno e mezzo fa ero CEO dell'azienda adesso sono un ingegnere quindi mi occupo solo di una cosa tecnica e ho tutto il tempo di giocare con le mie lego di programmazione chiamiamole così, però erano due periodi diversi quindi c'era una netta divisione tra i due elementi, tu come fai a far convivere invece due elementi nello stesso periodo cioè vedi la nuova feature, ti appassiona e poi ti guardi il team e il progetto.Chiaro, ma allora premesso che grazie al cielo sono in un'azienda dove il team è molto autonomo su queste cose quindi c'è un po' di senso di corresponsabilità da questo punto di vista e quindi spesso io posso anche farmi i fatti miei e provare cose e comunque scrivere codice tutto il giorno, effettivamente non è più il mio mestiere veramente, scrivo ancora codice, ma lentamente transizionando un po' lontano da quel mondo lì.Però io l'ho sempre fatto e ho sempre interpretato questo duplice ruolo in questo modo.Da un lato ho della stabilità che voglio mantenere, però voglio anche introdurre innovazione.Quindi vado, gioco, open source, progetti personali, cose, scopro mille cose nuove e poi distillo due, tre, quattro cose che secondo me in quel contesto dove io lavoro, dove voglio mantenere una stabilità ma evolverlo, possono creare un'evoluzione.Esempio, noi per anni abbiamo scritto codici usando in scala Future, che è un datatype nativo dell'Adobe Scala, che è un datatype che viene definito eager, cioè è come promise in JavaScript o in TypeScript, la crei e sta già andando.Questa cosa è necessariamente contro i concetti basi di Function Programming che tu devi prima costruire un'espressione e poi la esegui.Se tu hai una roba che ti scappa tra le mani ed esegui subito, è banalissimo scrivere un esempio in cui non puoi fare un certo tipo di refactor perché stai cambiando la semantica.Per cui magari una cosa prima eseguivo una volta, poi esegui due perché semplicemente l'hai spostata di posto.Quindi in scala, se tu parli con chiunque in scala oggi che scrive con un minimo di conoscenza di Function Programming, ti dicono "No, si usa I/O, si usa Zio, Cats, tutte le varie librerie di Function Programming che ti danno dei data types che sono lazy".Quindi tu crei la computazione e poi la fai.Bildo per anni ha scritto codice usando Future.Principalmente, credo, su spinta mia, siamo andati a esplorare l'idea di scrivere codice usando io usando altri stili tipo Douglas Fine, che sono un sacco di paroloni per dire che scrivi codici contro delle interfacce che rappresentano dei tipi lesi.Perché io mi sono messo a esplorare cose, ho partecipato a mille conferenze di scala, visto un po' come era il trend, ho fatto un po' di esperimenti, ho fatto un po' di open source, un po' di cose e poi l'abbiamo introdotto nello spec, un po' alla volta, sbagliando alcune cose, mi hanno idea mille volte, però ha un po' quel ruolo lì.Cioè tu hai il tuo battaglione e qualcuno va in avanti scoperta e prova cose.Gli spike engineer no? Sì sì sì io vivo di spike su tutto, cioè mi appassiono di una roba per due giorni e poi penso che faccio solo quella per due giorni e poi me la dimentico completamente.E questa cosa qui ogni tanto riesco anche a trasformare in qualcosa di utile.Io avevo una domanda, ti dico la verità, ma mi è scappata dalle mani.Ma è poco male.Abbiamo coperto praticamente tutto e guardando l'orologio vedo che siamo belli lunghi.Quindi è arrivato il tipico e topico momento di Geekbar chiamato "Il Paese dei Balocchi".E conduco nel Paese dei Balocchi.Ah, il Paese dei Balocchi.Ma allora, è molto on topic, non so se te lo incollo qua in chat così poi puoi avere il link.Mi è capitato sott'occhio ieri o l'altro ieri su Twitter, ed è da un tweet di Odersky tra l'altro, visto che rimaniamo in ambito scala.È una ricerca in ambito scala ed è però secondo me una cosa interessante e importante nel mondo del functional programming e della renderlo più approcciabile.Per chi ha presente un pochino functional programming sa che l'approccio tipico moderno di fare functional programming è quello che dicevo prima di rappresentare tipicamente le computazioni con queste strutture di tipo monadico.Non è importante sapere cosa sono ma sostanzialmente sono come delle dei contenitori, poi delle scatole.Si dice scatole, io sono sempre un po' reticento a dire quella cosa perché è una metafora che arriva fino a un certo punto, poi si spacca, ma vabbè, facciamo finta delle scatole.E quindi tu hai sempre un po' di frizione nell'usarlo perché tipicamente devi usare dei metodi apposta per creare queste espressioni in ASCAL, in Scala, ci sono delle sintassi apposta per fare questa cosa, c'è la Do syntax in ASCAL, c'è la For Comprehension in Scala.Però, volevamo sapere, finché vuoi, con scale e tutto quanto, alla fine della fiera un programma scritto dritto per dritto, dove ogni espressione fa una cosa, ha quel quid in più, che è il motivo per cui, per esempio, potete immaginarvelo come per dire la differenza tra scrivere una promise in JavaScript con i vari then, catch e tutto quanto, rispetto a sync/await.C'è sempre un po' quel feeling che scrivere le cose belle e dritte in ordine sia più facile o più approcciabile, più intuitivo.Io non sono un grandissimo fan di Async/Away, tra l'altro, però mi rendo conto della PIL.Ecco, questa ricerca che ho visto passare nei giorni scorsi è una ricerca che si chiama Monadic Reflection, un nome un po' interessante, come al solito un po' oscuro, che implementa i concetti esposti in una bellissima ricerca degli anni 90 addirittura, perché questa roba qui ricordiamoci è tutta roba vecchia che esiste da anni, semplicemente la stiamo applicando al mondo informatico oggi, 1994-1999, che è una ricerca che consente di trasformare il codice monadico in codice praticamente iterativo, con dei trucconi che tra l'altro si riescono a fare in scala 3, e quindi tu anziché scrivere tutti degli accrocchi per per cui scrivi Flat Map, Chain, mille cose in Stat, un po' tipo Then Catch di Promise, riesci effettivamente a scrivere gli stessi programmi in maniera imperativa, ma mantenendo la stessa semantica.Quindi mantenendo il fatto che sei in una struttura dati immutabile, che sei dentro una Promise, eccetera.Cioè, per chi conosce il contesto è un po' tipo lo stesso livello di magia tra fare mille nodi di destructuring per mantenere strutture dati immutabili in JavaScript e usare Immer, per chi lo conosce.Cioè, dove tu praticamente ti dà un proxy dove tu, boom, assegni le cose che ti sembra di stare facendo mutabili, in realtà lui te le trasforma in robe mutabili.E sostanzialmente la stessa cosa, trovo assolutamente fighissimo che sia basato su una ricerca degli anni '90, cioè che sembra che le monade le abbiamo inventate ieri, ma in realtà sono concetti molto vecchi, e trovo molto bello che si stia cercando di uscire dal concetto che per fare il functional programming devi imparare le monadi.No, quello è perché non siamo ancora stati capaci di fare una facile.È un lavoro con cui dobbiamo convivere, non è la virtù imparare quella roba lì.Invece, renderlo più approcciabile, più simile a come siamo abituati a scrivere sui programmi in maniera iterativa, lo trovo un effort fichissimo e spero prenderlo a piede nei prossimi anni.Assolutamente sì, ci mi ha incuriosito, ci butto un occhio.In realtà però, siccome io non ho un balocco per questa settimana e me mi auto-flagellerò, però ho una domanda aggiuntiva che era quella che volevo farti ma mi stava passando dalla mente Scott Slashin ha scritto, l'ho pronunciato male comunque, ha scritto un bellissimo l'unico a parlare di F# tra l'altro al mondo credo, lo usa solo lui e quattro suoi amici al bar però ha scritto un bellissimo libro che è functional domain driven design.Adesso tu che comunque per lavoro ti occupi e utilizzi la functional programming hai mai utilizzato il DDD con la functional programming? Se sì ti è stato utile è stato figo utilizzarlo ti ha aiutato o no? Hai mai scusa mi sono perso una parola.Hai mai utilizzato il domain driven design con la functional programming? Allora sì, non in senso classico, nel senso che non è che ho proprio letto il libro e l'ho applicato, ma in maniera...è un po' da far a culo dirlo, però ti viene più o meno naturale dopo un po' che lavori con functional programming, perché una bella visione di functional programming che spesso sento citata e che mi piace è quella che il functional programming è un po' frattale, cioè la gente pensa a functional programming e gli vengono in mente map e filter.Ma map e filter sono un concetto grosso così che si applica uguale quando stai facendo interagire tra di loro dei microservizi.Functional programming ti aiuta a strutturare dei sistemi che interagiscono tra di loro, dove questi sistemi possono essere indifferentemente quelle stessi identiche tecniche, due funzioni o due microservizi o due sistemi di pagamento.Quando inizi a ragionarla così è un po' tipo il martello dove tutto sembra un chiodo.E' il modo in cui è normale pensare ai sistemi, non è solo un trucchettino per scrivere il one-liner figo e vantarsi in una pull request.Scott Blasin è una delle persone che spiega meglio questa cosa, c'è la sua famosa slide dove compara i pattern della Gang of Four con Function Programming dove dice, lo so, "adapter, patter, functions".Cosa è "adapter"? Functions.Cosa è "functions"? Alla fine, una volta che hai capito che le cose entrano, escono e hanno dei tipi e non fanno cose strane in mezzo, più o meno puoi modellarci tutto.Quindi sì, è un tema molto molto molto bello, molto interessante.Ci sono altri libri del genere che mi è capitato di leggere, tipo il libro di...mi viene in te lo scrivo.È un libro sempre su domain driven design fatto con Functional Programming.Ah ok, no passamelo perché sono un po' interessato.Mi sta passando un professore indiano molto bravo nella comunità scala ma non mi interessa di veramente.E poi io lo condividerò nelle note dell'episodio senza nessun tipo di problema.Un po' quindi da come l'hai spiegata il Functional un po' la lente con il quale guardi il mondo e il contesto nel cui lavori alla fine? È un modo che trovo molto potente di modellare delle cose.Non è l'unico modo, ci sono mille altri modi, li spiegano ovunque.La cosa che a me apprezzo sempre di Function Programming è che ti permette di avere più o meno un pass per tu per tutto.Cioè una volta che ti cliccano i concetti, puoi applicare su tantissimi livelli, è molto riutilizzabile come skill, puoi passare da una co-based scritta in scala a una co-based scritta in 3D, i concetti si applicano.Una roba simile è tipo Reactive Programming, cioè quando tu impari una libreria di Reactive Programming, io l'ho imparata per la prima volta in Objective C, prendi RxJava è uguale, prendi Monix in scala è uguale, cioè sono dei concetti molto trasferibili, lo trovo una cosa efficiente, perché imparare cose è difficile, meglio imparare meno che si applicano di più.Fantastico, siamo arrivati alla fine del nostro episodio.Gabriele è stato bellissimo fare questa chiacchierata insieme.Grazie mille a te.Insomma quello che dico sempre ai nostri ospiti è che da questo momento in poi GIT BAR è un po' casa tua quindi vienici a trovare quando è qualcosa di interessante da condividere con la nostra community se ti fa piacere noi abbiamo anche un gruppo Telegram quindi se ti fa piacere puoi venirci a trovare anche là.Grazie di nuovo grazie infinitamente a nome mio e di tutta la community grazie a te Mauro è stato molto piacere è stato un super episodio con Gabriele ci ha accompagnato alla scoperta di TypeScript cercando di dargli anche un po' una forma diversa da come è visto solitamente anche insomma ci ha introdotto al mondo Scala che come sapete io guardo con distante ammirazione con un wannabe sulla spalla sempre propeso verso quel linguaggio prima o poi lo imparerò.Detto questo io vi ricordo rapidamente i nostri contatti info@gitbar.it @brainrepo su twitter il nostro gruppo telegram e vi ricordo che abbiamo appena lanciato la campagna donazioni per l'acquisto della nuova attrezzatura per gli ammutinati in modo che tutti gli speaker di GIT BAR abbiano un microfono di alta qualità per cui se potete entrate nel nostro sito e cliccate su supportaci detto questo io vi do appuntamento alla prossima settimana e niente alla prossima ciao 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 di strumenti immancabili nella cassetta degli attrezzi dei Full Stack Dev [Musica]
