Bene e benvenuti su Gitbar, nuova settimana e nuovo episodio qua sul nostro bar degli sviluppatori.

Oggi abbiamo Luca e Carmine.

Ciao ragazzi, com'è? Ciao Mauro, ciao a tutti.

Bene bene bene, benissimo.

Era un po' che non venivate qua a sbevazzare nel nostro Gitbar.

E' vero, è vero.

Oggi esageriamo.

Birre a fiumi oggi.

Oggi un sacco di birre.

In realtà oggi abbiamo anche un ospite super speciale, ma non ve lo sveliamo, almeno prima di aver detto la solita pappardella che un po' vi stressa, ma noi la diciamo lo stesso.

Potete contattarci scrivendo un'e-mail a info-gitbar.it o nel nostro bellissimo sito nuovo, nuovo vecchio.

Potete contattarci su Twitter a etbrainrepo, vi rispondiamo sempre o quasi sempre.

Potete anche, in realtà, Luca? Beh c'è il nostro ormai famoso, se non famigerato, gruppo Telegram che potete trovare cercando il Gitbar Podcast.

Vi darà il benvenuto, un piccolo bot giusto per evitare che dei bot vengano a romperci le scatole.

E a parte quello vi verrà offerta una birra, quella non è fatta da un bot, noi baristi adarvela molto volentieri.

Quindi, Gitbar Podcast, Telegram e ci siamo.

Ottimo, ottimo, ottimo.

Allora io penso che abbiamo detto tutto.

Possiamo spegnere sta musichetta fastidiosissima.

Aiuto, iniziamo bene, mi si sta già torcigliando la lingua.

Namo, bene.

E partire.

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 per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.

Molti hanno parlato di lui in questi ultimi giorni.

In realtà è un principal software engineer a Red Hat e un Java champions, uno degli uomini Java italiani, l'uomo Java italiano posso dire, almeno quello che si vede dappertutto, e anche il project lead di Drools.

Abbiamo con noi a Gitbar, a bere una birra con noi appunto, Mario Fusco.

Ciao Mario, come stai? Ciao ragazzi, grazie mille di avermi invitato, è tutto ok.

Siamo super super felici di averti qua con noi, anche perché in realtà il topic di cui parleremo oggi è un topic che proprio personalmente mi interessa, è strettamente legato a doppio filo alla natura etica del nostro lavoro e voi sapete quanto mi gasano questi argomenti, no? E immagino anche Luca sia di quella pasta.

E quindi oggi parleremo di una cosa molto interessante con Mario, parleremo di reinventare la ruota, però ancora prima Mario io ho una domanda.

Tu lavori a Drools, Drools è un rule engine, in tutta sincerità, che cos'è un rule engine? Allora, diciamo che il rule engine è il modo per implementare il terzo paradigma di programmazione che forse viene un po' trascurato ma che invece è importante.

Voglio dire che di solito, va bene, io sono uno sviluppatore in Java, quindi da quando programmo ho sempre programmato in object orientation, ho fatto anche un po' di functional programming, ho lavorato in scala in passato e poi ovviamente da quando ci sono le lambda expression in Java si tende fortunatamente a mischiare sia la parte di object orientation che la parte di functional programming.

La terza gamba di cui ti parlavo è la programmazione dichiarativa, quella che facciamo in prolog tanto per capirci se avete mai fatto prolog, ovvero dichiarare in maniera, scusa la ripetizione, dichiarativa il risultato che si vuole ottenere ma non gli step per ottenerlo.

La cosa più vicina che mi viene in mente è una query SQL, è il tipico esempio di linguaggio dichiarativo, nel senso che tu dici al database cosa vuoi ottenere ma non dici al database come mettere in join le tabelle o come ottenere il risultato.

Quello che fai invece con un rule engine è quello di dichiarare delle regole di business in maniera, praticamente una regola di business è fatta di due parti, la parte in cui dichiari le condizioni che devono soddisfare i tuoi oggetti di dominio e nella seconda parte invece quando questi oggetti vengono trovati quale azione eseguire a fronte di quegli oggetti.

Quindi in realtà se vogliamo fare un'analogia con un metodo Java, quando il motore di regole fa pattern matching, ovvero sta trovando gli oggetti che fanno matching delle condizioni, sta trovando gli argomenti del metodo mentre il body del metodo è la seconda parte che ti dicevo, con la differenza che tu non passi esplicitamente argomenti alla regola, se li trova da solo e non invochi tu la regola ma la regola viene invocata dall'engine, prima scatolata e poi invocata dall'engine quando quegli oggetti vengono trovati.

L'altra domanda ovviamente è che cosa faccio con questo robo? Ovviamente cerco di modellare le regole di business in un modo che sia interleggibile agli esperti del business domain stesso perché tipicamente alcuni dei progetti che ho visto fallire in realtà li ho visti fallire perché c'erano delle incomprensioni tra gli sviluppatori e chi descriveva le regole del business perché i secondi dicevano una cosa, i primi le implementavano un'altra ma poi i domain expert non sanno leggere java quindi non riescono a capire se l'implementazione corrisponde alla regola di domenio o no e quindi le cose funzionano male.

Quindi l'idea è che questo linguaggio dichiarativo sia più facile per i domain expert se non scrivere regole di business o almeno validarle e queste regole di business possono spaziare davvero in tantissimi settori.

In campo medico per esempio è molto utilizzato, è una delle più grosse installazioni che abbiamo, al centro oncologico più grande del mondo che sta in Minnesota e lì c'è un'equip di esperti di quel dominio, di medici oncologisti che hanno codificato circa in 200.000 regole la loro conoscenza su quel dominio e praticamente loro danno in pasto al Rulanchin la prognosi e il Rulanchin dice ok qui c'è un tumore, dicati per tumore, utilizzando le regole che hanno dato i medici, viene usato per esempio per fraud detection, nel senso che una banca può dare delle regole di business per decidere quando c'è un comportamento che potenzialmente è fraudolento su una carta di credito, viene usato per il marketing, ho visto che le regole di business al marketing sono abbastanza fantasiose e cambiano parecchio spesso, quindi quello è un altro campo di applicazione.

In generale è anche l'altro aspetto che secondo me in maniera erronea viene trascurato un poco, dell'intelligenza artificiale, nel senso che l'altro errore che viene fatto è che si utilizzano come sinonimi i termini intelligenza artificiale e machine learning, ma non sono sinonimi nel senso che il secondo è un sottinsieme del primo, nel machine learning sono quegli algoritmi di intelligenza artificiale in cui la macchina impara da solo attraverso metodi statistici fondamentalmente, pensiamo alla rete neurale, l'artificial intelligence invece è qualcosa di più largo, è appunto l'intelligenza artificiale dove la macchina può imparare da solo, magari no.

Il problema secondo me è che si abusa troppo di machine learning e certe volte però facendo così fai a scoprire in maniera statistica il tuo dominio di business quando alcune regole di business invece le sai già e le puoi codificare tu nel tuo codice, non devi scoprirle da zero.

Se riuscissimo a far cooperare questi due mondi, a far parlare di più questi due mondi, che è uno degli sforzi che stiamo facendo ultimamente, forse ne avremmo qualche vantaggio, ti faccio un esempio, non so se hai mai provato a cercare e poi a comprare una lavatrice su Amazon, da quale momento in poi Amazon ti propone una tonnellata di lavatrici perché sono statisticamente correlate, il machine learning ha deciso così, sono statisticamente collinate fra di loro e quindi per un po' di giorni o di settimane vedrai i proposti di lavatrici che però a quel punto lì probabilmente non ti interessano a meno che non hai deciso di aprire una lavanderia.

E' lì però, puoi mettere una regola di business per dire ok, se tizio ha comprato una lavatrice molto probabilmente sarà interessato a qualsiasi cosa nei prossimi giorni ma non a uno secondo lavatrice.

Sacro santa cosa Mario, tra l'altro fun fact, proprio oggi mi è arrivata l'asciugatrice perché col break friday gli sconti allora ho deciso di prendere l'asciugatrice e Amazon ha iniziato a propormi stendini.

Ok.

Ma cripio, sto comprando un'asciugatrice.

Però davvero domanda, come questi due mondi, quindi il mondo delle regole di dominio, delle regole di business e il mondo statistico di analisi si possono incontrare dal tuo punto di vista? Quali sono le azioni che in un sistema così ampio si possono fare per far sposare questi due approcci che sono antitetici, possiamo dirlo? Si, li chiamerei complementari più che antitetici ma dobbiamo trovare il modo per complementarli bene e ci vedo almeno due modi che sono bidirezionali.

In un caso una regola potrebbe invocare un pezzo di neural network per farsi dare uno score, per esempio uno score di affidabilità di un utente di una carta di credito, quello potrebbe essere valutato da un neural network ma quello score potrebbe rientrare come valore all'interno della regola e la regola di business a quel punto dice ok, al di sopra di questo score ti voglio dare delle cose, al di sotto non te le voglio dare più, però quella è una regola di business.

Oppure potrebbe succedere il contrario, nel senso che a palle della valutazione, facciamo tornando all'esempio di Amazon, a palle della valutazione con relazione statistica con machine learning, nell'esempio dell'asciugatrice e della lavatrice, si potrebbe dire ok, l'algoritmo di machine learning ha proposto questi ultimi prodotti a cui potresti essere interessato, però mettiamoci una regola di business che faccia da filtro applicando le regole di dominio prima di far arrivare quegli oggetti all'utente finale.

Quindi ci sono dei modi per complementare le due tecniche e secondo me potrebbe essere molto interessante.

Mi sento di dire che è anche il modo, dal mio punto di vista, ne parliamo in una puntata con frate Paolo Benanti che è un eticista dell'intelligenza artificiale, quindi si occupa dello studio della natura etica, dell'intelligenza artificiale, utilizzare questo tipo di sistemi, quindi i rule engine, a valle del processo permette in qualche modo di controllare neanche la natura non solo pragmaticamente fattiva della cosa, ma anche la natura di impatto di una cosa che è fuori dal controllo dell'uomo, quindi è un po' come rimpossessarsi del controllo della tecnologia e non esserne...

Questo è un altro problema enorme, l'etica, perché tipicamente questi sistemi di machine learning sono delle black box, però prendono delle decisioni che potrebbero essere anche non eticamente accettabili, l'esempio classico è decidere di concedere o meno mutui biancari, però l'algoritmo potrebbe imparare che le persone di colori sono statisticamente peggiori i pagatori dei bianchi e penalizzare persone in base alla razza, che ovviamente non è eticamente accettabile e questo neanche puoi riuscirlo a capire perché tipicamente questi oggetti funzionano come delle black box, quindi lui agisce in quel modo ma non sa neanche meno perché...

L'altro aspetto in questo esempio è che ancora una volta ti serve una spiegazione comprensibile dagli esseri umani quando rifiuti il mutuo, perché pure lì colore della pelle a parte, probabilmente non è etico dire il mutuo non te lo do perché la neural network ha detto di no, magari ci vuole una spiegazione un po' più intelligibile per un essere umano.

E poi anche il risultato secondo me di una neural network come abbiamo detto prima è figlio di una serie di pattern che magari ai nostri occhi non si vedono ma che in qualche modo vengono riconosciuti, ma se noi vogliamo rompere i pattern a livello fattivo proprio di azione, beh a quel punto dobbiamo forzare una serie di regole al di là del risultato statistico che ci arriva da un percorso più o meno complesso, più o meno nascosto.

Voglio ritornare per un attimo al rule engine perché qualche tempo fa ho letto un libro molto interessante, era un libro su functional domain driven design dove si diceva che l'interfaccia, la definizione dei tipi poteva essere un linguaggio franco tra il business, è fatto in un certo modo, tra il business e la parte più ingegneristica della comunicazione.

Ecco, quanto un rule engine utilizza, quanto i due mondi, il functional DDD e l'utilizzo di rule engine si differenziano? Allora, sì, col functional DDD o col DDD in generale, perché poi il functional è solo una possibile implementazione, stai esprimendo le regole ma le stai comunque esprimendo nel linguaggio, a meno che non ti sei fatto il tuo DSL esterno che però tipicamente richiede un bello sforzo, lo stai comunque esprimendo nel linguaggio di programmazione, magari ti sei fatto un DSL interno carino, però pure lì è abbastanza poco probabile che un esperto di dominio che non conosce quel linguaggio di programmazione sia in grado di leggere e validare la regola di business che hai messo dentro usando quel dominio.

Questo è un aspetto.

L'altro aspetto è anche che con il DDD stai comunque codificando le regole di business insieme a tutto il resto del tuo software, quindi in quel software, in quell'applicativo ci stanno sia concern architetturali e concern di business mischiati insieme.

Se tu invece codifichi le regole con il rule engine, le regole di business stanno in un altro posto, codificate in un altro linguaggio, sono nettamente separate dalla parte architetturale del software e questo è vantaggioso perché tipicamente se ci pensi queste due cose hanno anche dei cicli di vita molto diversi, nel senso che se scrivi la parte architetturale del tuo software probabilmente ci farai piccole modifiche o resterà quasi una volta stabilizzata, resterà quasi invariata per anni, mentre le regole di business variano potenzialmente ogni giorno.

Un'altra applicazione del mio rule engine è quella di un'agenzia di viaggi di cui non faccio il nome, che nessuno conosce, ma che in realtà controlla il prezzo del 90% dei bigliettieri che vengono venduti e se vedete la follia di come cambiano i prezzi vi rendete conto che ci sono delle regole di marketing dietro e quelle regole di marketing sono implementate con Drulls e cambiano letteralmente ogni giorno, ma sono totalmente separate dalla loro parte architetturale di software.

Ti faccio l'ultima domanda su Drulls perché sono super curioso, devi avere pazienza e sopportarmi.

Hai detto che Drulls è un tool, possiamo definirlo tool? Sì, sì.

È uno strumento che permette la definizione di una serie di regole di dominio per domeni diversi, hai parlato di campo medico, hai parlato di agenze di viaggi.

Adesso la mia domanda è se chi scrive le regole è un esperto del dominio, il Rule Engine espone una lingua franca su tutti i domini o c'è un modo per farlo? C'è un linguaggio di programmazione che è molto più semplice da ragionare su per chi non è un programmatore.

C'è un match uno a uno tra le regole che ti possono venire in mente e come le scrivi, mentre quelle regole se ci pensi le scrivi in programmazione procedurale, sarebbero un mischione di branch e inferse.

Ti faccio un altro esempio, c'è un'azienda di Torino, loro fanno sentiment analysis, quindi quello che fanno è raccogliere, quando viene lanciato un prodotto per esempio, raccolgono tutti i tweet, i post su Facebook, sui social network che vengono fatti relativi a quel prodotto e c'è un software basato su Druze che fa natural language processing che cerca di capire il sentiment nei confronti di quel prodotto dai post rapporti.

Questo set di regole che fanno questa analisi di natural language processing è stato scritto da un linguista, da un esperto della lingua italiana, quindi non da un programmatore, che ha scritto le regole di base per tokenizzare la lingua italiana, per dire questo è un verbo, perché se ci pensi pure quello non è banale, quando una parola è un verbo, quando è una parola, soprattutto l'italiano che è bello complicato, quando è un aggettivo è se quell'aggettivo ha un'accezione positiva o negativa e quindi questa è la base dell'analisi linguistica.

E poi on top di questa analisi linguistica ci stanno altri insieme di regole, credo che ne abbiano una sessantinete adesso, divisi per categoria merceologica, che fanno un'analisi relativa a quella categoria merceologica.

Quindi ci stanno questi due insieme di regole, uno generico che fa l'analisi della frase in italiano, che genera dei token, questi token vengono passati all'analizzatore relativo alla specifica categoria merceologica e da lì riesce a dedurre il sentiment analysis, a fare sentiment analysis sul prodotto da analizzare oppure per esempio viene utilizzato, adesso su Twitter vengono un sacco commentati i programmi televisivi mentre vanno in onda, ecco la RAI è un cliente di questa azienda per cui mentre va in onda il programma televisivo loro cercano di capire qual è il giudizio del pubblico su quel programma.

Ripeto, quella parte di natural language processing è stata scritta da un linguista, non è stata scritta da un programmatore.

Chiarissimo, ho una domanda per Carmine e Luca, avete qualche domanda, curiosità? Pensavo più che altro che, insomma, mentre parlava di tool assolutamente interessanti, ci volevo dare anche un'occhiata, è bello che la cosa principale che risolve, risolve se vogliamo anche la comunicazione che c'è tra le varie parti di un'azienda, riguarda sempre le persone, insomma noi siamo il problema, adesso non voglio dire, ma noi persone siamo il problema ed è veramente interessante solverlo, il modo in cui viene risolto e sono anche assolutamente d'accordo sulla questione della black box, di mettere l'intelligenza artificiale, il machine learning lì dove in teoria non dovrebbe esserci, non che se ne potrebbe fare meno, proprio non dovrebbe esserci, perché molte cose, molte scelte magari sono appunto deterministiche.

No, ci voglio dare sicuramente un'occhiata, è scritto in Java? Scritto in Java, certo sì.

Però, ripeto, il modo in cui scrivi le regole poi non è Java, c'è un linguaggio di programmazione dichiarativo che dovrebbe essere relativamente semplice da imparare.

È bello ricco, quindi poi, insomma, se vuoi andare più nel dettaglio di tutte le funzionalità c'è tanto da imparare, però per iniziare dovrebbe essere relativamente eccessivo.

No, esatto, lo faccio volentieri anche perché stiamo proprio anche già definendo un dizionario comune nell'azienda dove lavoro e mi sembra proprio anche un bel momento dove darci un'occhiata.

Perfetto, grazie.

Ci sta.

Però Mario, tu qualche tempo fa hai fatto, a Zurigo se ricordo bene, hai fatto un intervento dove parlavi di reinventare la ruota e devi sapere che nel nostro gruppo Telegram questo topic è tipo uno dei più caldi in assoluto perché, come ben sai, ormai facendo parte del mondo delle community da ormai tanto tempo sai che è uno di quegli argomenti che un po' riscalda gli animi, no? Il tuo talk era abbastanza chiaro sul reinventare la ruota, quindi quello che io voglio chiederti è proprio come primo passo proviamo a definire cosa intendiamo reinventare la ruota perché sentendo più campane spesso il reinventare la ruota è diverso a seconda della persona che lo definisce, quindi proviamo insieme tutti e quattro a definire una versione, non necessariamente quella giusta o la verità infusa dall'alto, no? Però la nostra versione comune oggi del reinventare la ruota.

Per te, Mario, che cosa è il reinventare la ruota? Allora sì, come dicevi tu, probabilmente ognuno gli dà una definizione diversa e quella che io portavo nel talk di cui parlavi è la mia definizione che ovviamente, e ne facevo alcuni esempi, che ovviamente è basata sulla mia esperienza personale, sulle cose che ho notato lavorando nell'ultimo quarto di secolo, quindi 25 anni di programmazione, si iniziano a sentire e si iniziano anche a, facendo un po' di analisi retrospettiva, a vedere dei cicli che si ripetono.

Quindi il mio reinventare la ruota è questo, ogni tanto mi capita che viene lanciata la nuova buzzword, perché poi purtroppo il nostro mondo lavorativo è tanto basato su seguire alcune mode e sul reinventarsi cose che esistevano prima, semplicemente con un nome diverso, che abbiamo provato a fare e poi non funzionavano e le abbiamo abbandonate e poi abbiamo deciso che dopo dieci anni ce le siamo scordate, gli diamo un altro nome e ci riproviamo.

Questo è quello che intendevo io, non so se posso fare uno dei primi esempi che facevo nel mio talk, è che più di venti anni fa ormai lavoravo per un'azienda tedesca che si chiamava Software Agai, non so se ne avete mai sentito parlare, ma Software Agai è l'azienda che tra la fine degli anni settanta e l'inizio degli anni ottanta combatte la battaglia dei database, tipicamente contro Oracle all'epoca la battaglia dei database non era un brand piuttosto che un altro, ma un paradigma piuttosto che un altro, nel senso che c'era il paradigma relazionale di cui ora con l'Epoca e anche adesso era il proponente più importante, poi c'era il paradigma gerarchico che era quello invece proposto da Software Agai, sappiamo tutti com'è andata, i database relazionali hanno vinto per un buon motivo.

Poi quello che è successo però è che nell'inizio degli anni duemila andò tanto di moda l'XML, non so chi è vecchio come me se lo ricorda, e quindi i database XML, e indovino un po' un XML è un albero quindi è una gerarchia e quindi loro pensarono ok, allora facciamo un database gerarchico riutilizzando il nostro engine di storage di dati gerarchico per stavolta ficcarci dentro un XML.

Non aveva funzionato all'inizio degli anni ottanta, vent'anni dopo non ha funzionato comunque.

Quindi quando una cattiva idea, e quando un'idea è cattiva resta cattiva pure dopo che l'hai riflettizzata.

Ti faccio una domanda, o almeno mi piacerebbe provare a inserire questo elemento nella riflessione.

Posto che questi cicli storici di fai, ritorna, fai, ritorna sono chiari, io mi chiedo, quest'ultimo periodo, mi sto chiedendo se in realtà il concetto di ciclo, o come l'hai definito tu nel bellissimo talk che metto nelle note degli episodi di Pendolo, non sia condizionato dal modo nel quale osserviamo l'evoluzione della tecnologia.

Ripeto, non è la verità, è una domanda alla quale non ho risposta.

Contestualizzo, quando noi osserviamo il mondo della tecnologia e proviamo a interpretare una certa evoluzione di un tool, di un paradigma, noi questa interpretazione la facciamo analizzando una serie di attributi, per esempio come hai appena detto, un sistema di archiviazione gerarchico o un sistema relazionale.

Stiamo valutando quel ciclo storico guardando un attributo, ma di attributi all'interno di quel processo evolutivo ce ne sono degli altri.

Quindi mi chiedo, quanto, e non ho una risposta, quindi proprio una mega domanda aperta, la giro anche alla community, quanto invece questo ciclo dei corsi e ricorsi storici sia legato al modo in cui guardiamo le cose più che alle cose stesse? Allora, io come te non ho proprio una risposta, o meglio, ce l'ho, è simile a quello che ti ho raccontato prima e la risposta dipende esclusivamente sulla mia esperienza.

Quindi, come dicono gli inglesi, your miliage may vary.

Voglio dire, ognuno può aver fatto diverse esperienze e aver visto ricorsi storici diversi nel proprio settore di expertise e aver tratto conclusioni anche diverse.

Non saprei come risponderti meglio di così.

Guarda, puoi dirlo che sono un maledetto relativista, mia moglie me lo dice tutti i giorni, quindi forse è un modo ponziopilatesco per lavarmi le mani di una discussione scottante.

Non lo so, però è comunque una domanda che mi faccio e che in qualche modo mi porta anche a guardare l'interpretazione di questa cosa.

Però vero è che comunque il nostro mercato è drogato, no? È drogato di stimoli autindotti, è drogato di una serie di elementi.

Quindi, in realtà, secondo te quanto il reinventare la ruota è legato a quello concetto che io chiamo hype driven development? Ah sì, tantissimo.

Tantissimo.

Guarda per esempio i microservices adesso, prima si chiamavano SOA e non ci piacevano, chissà perché, adesso invece i microservices mi piacciono e io non capisco qual è la differenza onestamente.

Però adesso ne abbiamo dato un altro e mi so più bene.

Tantissimo, sì, è basato su queste ondate di hype.

Per me, alle volte, è difficile da giustificare.

Diciamoci la verità, non è vero che non si fa innovazione.

A ognuna di queste ondate qualche cosina di nuovo si cerca di portare o di capire dove si è sbagliato e di rifarlo meglio.

Questo va benissimo, però venderlo come una cosa totalmente nuova che mai nessuno si era sognato prima, ecco, quella è la cosa che mi, se posso dire, che mi fastidisce un po', insomma, mi fa un po' saltare sulla sede.

Perché poi con un po' di anni di esperienza ti guardi indietro e c'è quell'effetto spiacevole di déjà vu, non so se riesco a spiegarmi, e dici cavolo, questa cosa non funzionava prima.

Boh, magari adesso abbiamo capito, imparato dei nostri errori, riusciamo a farla funzionare, però andiamoci copiti di più.

Beh, ma a livello di marketing però uno può anche capire che non venga sul mercato dicendo ho un nuovo prodotto, sì è vecchio di vent'anni, però questo è l'anno giusto, quindi diciamo che ci sta.

Poi del resto io ho dei dubbi sul fatto che se una cosa vent'anni fa non andava bene, oggi continuerà a non andare bene.

Il contesto cambia, cambiano anche soprattutto le persone, cioè magari le persone rispetto a vent'anni fa hanno un nuovo approccio, hanno delle nuove teste, un modo nuovo.

No, pure magari, semplicemente come dicevo, non funzionava perché non si era capito come usarlo, adesso invece si sono fatti dei progressi in quella direzione, va bene così.

Poi l'altra cosa che mi piace poco è l'estremizzazione di certi concetti, nel senso che siamo passati, c'è questo effetto pendolo tra il serverone e poi siamo tornati al monolite, poi adesso invece facciamo i microservizi, e però non solo facciamo questo pendolo avanti e indietro, ma quando lo facciamo il pendolo ha un'elongazione molto più lunga di quello che dovrebbe avere, nel senso che ci andiamo dentro all'in, prima era un monolite enorme, adesso il microservizio fa l'addizione e abbiamo 250 microservizi, uno per fare l'addizione, un altro per fare la sottrazione, un altro per fare la divisione.

Ecco, si passa da un eccessivo estremo ad un altro e si fa fatica a trovare la giusta misura, questo è un altro aspetto che mi sembra abbastanza ricorrente.

Però credo che, non lo so, correggetemi se sbaglio, questo è un pensiero a ruota libera, ma questo tipo d'approccio sia in qualche modo correlato in realtà con il mondo sempre più polarizzato che stiamo vivendo.

Nella tecnologia stiamo ormai sviluppando, c'era già da prima, però stiamo sviluppando in modo più forte il concetto di polarizzazione, io lo chiamo il concetto del tifo calcistico, mi sentite? Sì, sì, sì, di sentire ho messo una calcolata, sì.

In realtà, io ho provato a darmi una risposta a questa cosa, credo che in realtà la nostra industria ha avuto montagne di soldi sopra la testa negli ultimi vent'anni e dobbiamo ammetterlo, ok? Questa montagna di soldi ha drogato, sto sparando la bomba, quindi fermatemi, ha drogato un'industria che non era ancora matura, che ha sviluppato una dinamica autoreferenziale di creazione della complessità.

Sto facendo un giro gigante per arrivare a dire abbiamo creato talmente tanta complessità che oggi come uomini e come industrie non possiamo più controllarla.

Questo fa sì che ci sia una polarizzazione estrema come gesto di protezione.

Di protezione vuoi dire di protezione del job securing? Anche di protezione individuale dal carico cognitivo, oltre che di protezione economica, di protezione della propria carriera.

Appunto, sì, quella che io chiamo job securing, sì.

Sì, è sicuramente una lettura, sì.

Questa è la cosa che più mi convince e quindi da una parte tu devi entrare in questa dinamica.

Dall'altra abbiamo una cosa che voglio provare a interpretare con voi, specie perché comunque sia tu Mario che Carmine hai lavorato in un mondo dove c'è tanto open source e quindi mi chiedo qual è il ruolo delle dinamiche open source e dell'evoluzione di come interpretiamo l'open source oggi che è cambiato drasticamente negli ultimi vent'anni? Mi potrete confermare.

Diciamo con l'open source quantomeno è un po' più di possibilità di fare peer review perché è quella la cosa che mi piace di più di quel modo di lavorare e quindi c'è una discussione un po' più aperta e può venire chiunque a dirti che questa roba ti stai rimettendo alla ruota o non funziona perché l'ho già provato io e lo so che non funziona o sì sei sulla strada giusta ma magari ti do un consiglio per migliorare perché ho fatto gli stessi errori che stai facendo tu e ti posso aiutare a risolverli.

L'open source mitica secondo me un po' tanto questo problema.

Io stesso mi trovo quotidianamente in meeting of you dove si discute di tutto e del contrario di tutto e è difficile trovare l'accordo, trovare la quadra.

Siamo tutti quanti strongly opinionated e io non mi salvo assolutamente da questo.

Ho le mie opinioni forti su certe cose e le difendo anche al di là del ragionevole quindi non mi chiamo fuori da questa situazione.

Io la verso esattamente come Mario e credo che l'open source abbia anche un altro effetto che nel 99.9% è meraviglioso.

C'è quell'1% che spesso porta a drogare ancora di più tutto che è il concetto dell'alternativa.

Avete presente l'alternativa? Io lo sto vedendo credo nell'ultimo anno e mezzo sul mondo front end.

Esce una cosa nuova ogni x settimana.

Noi stiamo parlando ora.

C'è questa persona.

C'è un framework javascript che sta nascendo mentre parliamo.

C'è uno che sta morendo e c'è una start up che sta facendo lay off di persone che lavoravano con quella cosa lì.

Ecco, il concetto di alternativa secondo me spesso si incrocia tanto con quello di reinventare la ruota.

Perché spesso nascono delle...

è giusto che ci sia l'alternativa con quello che cosa.

Sono per il pluralismo di qualunque cosa.

Figuriamoci il front end.

Spesso però il fatto di sforzarsi di creare queste alternative anche quando non ce n'è effettivamente bisogno è quella proprio la miccia su live driven development.

Nel senso Dio è nata questa nuova cosa, concentriamoci qui, facciamo qui, eccetera, eccetera.

Spesso sono quelle tecnologie che sono anche supportate da un'ottima campagna di marketing nelle community come le stesse.

Io credo che...

anche noi abbiamo fatto la stessa cosa.

Il sito prima di Gitbar era fatto con Gatsby.

Anche noi ci siamo lasciati...

io per primo ho provato Gatsby che mi sembrava la soluzione a tutti i miei problemi e poi mi sono ritrovato con il sito che non compitava più.

Che è strano, ora stiamo parlando tra quattro persone che fanno questo lavoro e io dico il sito non compita più.

Che non significa niente.

Però siamo sostanzialmente arrivati a questa situazione in cui la build di produzione del sito, io su diversi clienti, ho visto questo, si rompeva.

Quindi che cos'è? Quindi non va più bene Gatsby, allora si va su Next, però Next poi diventa tutto il contaio di tutto, ci facciamo il frontend, ci facciamo il backend, perché no? Tanto ci si fa tutto.

Poi viene Astro.

Astro effettivamente qualche concetto nuovo lo porta, proprio architetturale.

Anche noi di Gitbar ci siamo cascati dentro Astro.

Ora vediamo per quanti altri mesi dura prima che si spacchi e si ritorni a farlo insomma con Jekyll.

Però ecco, apro una parentesi e la chiudo coi c***i, io non rifaccio più quel sito.

Ok.

Il fatto è che spesso vengono proposte delle alternative che sono sacrosante.

Il più delle volte però le vedo come delle cose senza una precisa razza dietro.

O è Blazing Fast, però non si sa su quale benchmark, o è più...

io ho letto delle cose e non ho capito che cosa significano.

È più community oriented, stessa licenza, stessa cosa, dell'alternativa insomma.

Quindi, come posso dire, ci sono tante cose che non ho capito e credo che questa mentalità di voler necessariamente trovare l'alternativa, e ci sono aziende che foraggiano marketing per far spazzare queste alternative, poi ci toglie veramente, o meglio diciamo che lascia l'onere e l'onore a pochi di fare reale innovazione, anche in quei campi di innovazione, di cose nuove, ne avrebbe effettivamente bisogno.

Ho fatto questo discorso come tipo il vecchio che grida verso il cielo, che fa tutto schifo, però in realtà ecco, è una cosa che stavo effettivamente notando.

Tantissime community, ma anche se vi fate un giro su Reddit, in diversi subreddit, ci sono aziende che sponsorizzano con fiori e fiori di euro, dollari o quello che sia, una tecnologia emergente piuttosto che un'altra.

Ovviamente si può dire, ma lo fa e lo faceva anche ora con Microsoft Red Hat, Suse, lo facendo, nel senso è giusto promuovere un proprio prodotto, quello che non capisco è il voler promuovere a tutti i costi un'alternativa a qualcosa che non ne aveva reale bisogno di questa alternativa.

Scusa vai Luca.

No, volevo dire una cosa su questo, perché comunque noi siamo sviluppatori o quel che siamo, se aspettiamo di avere l'idea che nessun altro ha avuto, stiamo freschi, cioè non dovremmo fare niente davanti al computer, se no drag and drop di elementi già fatti da altri.

Ma a parte questo, e quindi diciamo magari un po' anche per roba personale, per spasso personale, ogni tanto ci sta pure un reinventare, questo nel singolo, poi ovviamente dipende da chi ti paga, se ci sta qualcuno che ti sta pagando per fare quello che stai facendo magari non è proprio il massimo reinventare la ruota senza motivazioni plausibili.

Invece per quanto riguarda tutto il discorso dei microservizi o cose che esistevano e che magari non funzionano, mi chiedo quanto sbaglia chi fa e quanto chi decide di usare la ruota reinventata, perché nella maggior parte dei casi si accusa quello che sta facendo, ma io faccio quello che voglio, poi se tu mi vuoi usare usami, altrimenti non ti costringo mica ad usarmi, cerca di avere la testa, di capire se è il caso di usarmi oppure no.

Certo se io sono la mega company che spinge un prodotto, l'hai già un po' più difficile credo per tutta una serie di ragioni che sempre riguardano le persone e la voglia delle persone di non avere responsabilità delle scelte che fanno.

Poi c'è un altro aspetto che mi chiedo, se chi accusa di reinventare la ruota sta capendo quale ruota sto reinventando? È successo più di una volta, io sono un fan del reinventare la ruota, ovviamente nel piccolo per motivi di learning, per tante altre cose, è un sacco di volte che propongo una libreria o un qualcosa e mi dicono ma c'è già, mi dici ok fammi vedere cosa c'è già, c'è questo, sì ma non è questo quello che sto facendo, ma perché sei così prevenuto, cioè sto facendo un'altra cosa, sto risolvendo un altro problema di quello che tu pensi, è un po' smorsa l'entusiasmo e magari sta lì, rimane lì, questo va beh ho spaziato un po' tra il personale, le big company.

No no ma in realtà non è un discorso personale per tutti quanti, come dicevo è tutto basato sull'esperienza personale, ognuno ne ha una diversa.

Sì, secondo me hai tirato fuori un buon punto che io sento molto vicino, nel senso per citare due miei colleghi, è una cosa che penso anche io, io voglio programmare in ciabatte, al mare, comodo pensando solo a quello che effettivamente mi serve e pensando solo a scrivere e a pensare a quello che mi porta realmente valore, io sono dall'altra proprio sponda, nel senso che a me non piace reinventare la ruota, a me piace prendere quello che c'è già, se non c'è lo faccio e lo metto a disposizione degli altri.

Sono sempre stato un po' contrario a questo reinventare la ruota, spesso però mi sono ritrovato a parlare con persone che erano convinte di star reinventando la ruota, in realtà stiamo facendo una cosa completamente diversa, il fatto che tu abbia delle esigenze di performance, di dominio, di compliance, di qualunque cosa che ti porta a scrivere qualcosa da zero invece di usare come foundation qualcosa che c'è già, non significa stare inventando la ruota.

Per me in questo caso di cui stiamo parlando, reinventare la ruota significa, e l'ho visto, stiamo facendo l'ennesimo microservizio Crudingo, non utilizziamo chi è un'altra libreria per fare rooting, ce lo facciamo a mano con la libreria standard e le RedExperts.

Per me questo è reinventare la ruota, rifarsi il sistema di… Si, quello è il not invented here, più che reinventare la ruota, insomma.

Si, nel senso ci sono opposti e ci sono anche diverse comunità che spingono verso una cosa e verso un'altra cosa.

Insomma, questa ovviamente è una cosa personale che non c'entra niente, ma poi è inevitabile che ritornando al discorso di prima, il mercato si droghi inevitabilmente.

Se la nuova tecnologia che sta prendendo piede, tutti ci vanno dietro e vogliono imparare quella tecnologia, è più o meno ovvio che l'azienda cerchi personale specializzato in quella cosa lì perché ora va, perché può prendere fondi, perché può sentirsi di nuovo.

Ci sono tante cose che vanno in mezzo, insomma.

E alla fine parliamo, parliamo, sta ancora di mezzo Java, sta ancora di mezzo Erlang in una definizione diversa, è comunque quello, e sono ancora diciamo pochi i veri pilastri che poi si usano in certi ambienti.

Non me ne vogliono più puristi di linguaggio più nuovi.

Io ragionavo su una cosa, proviamo a vederla così.

La tecnologia si evolve sotto forma di piccoli salti quantici, quindi non c'è una graduale evoluzione, ma ci sono degli step.

Io non ho ancora individuato il momento preciso in cui c'è il salto, però mi immagino che se noi dovessimo analizzare localmente, provare a visualizzare localmente questi step, si ha una crescita quasi logaritmica, quindi che tende a stabilizzarsi, parlo di evoluzione, e poi c'è lo step successivo che fa l'altro jump.

E quando tende a stabilizzarsi c'è un continuo reiterare.

Quindi questo è più o meno come potrei visualizzarla.

Però allo stesso tempo mi chiedo, se cerchiamo di limitare questi sforzi, perché spesso sono alimentati da marketing, spesso sono alimentati da focus, e qua lancio un'altra bomba autocritica, focus sulla developer experience.

Oggi noi siamo degli sviluppatori, noi siamo degli ingegneri, abbiamo un impatto fondamentale, e parlo da sviluppatore che opera anche in ambito pensoso, abbiamo un impatto fondamentale nel mondo che ci circonda, e quello di cui parliamo ai tavoli è come miglioriamo la dev experience del tool che stiamo facendo.

Ma siamo sicuri che il focus è quello fondamentale, perché molto del reinventare la ruota, che vedo tutti i giorni, ha proprio questo focus.

Va bene che voglio un cavolo di sedile nella macchina in pelle super comodo, ma se non ho le ruote io quel sedile me lo giro in el collo, scusate il rant, però secondo me questo è un elemento importante da prendere in considerazione dal punto di vista autocritico.

Che ne dite di questa visione? Io non ho una risposta, insomma vedo il punto, vedo… il problema sono le motivazioni, cosa veramente vuoi ottenere, se vuoi vendere il prodotto devi fare delle cose che probabilmente ti sembrano un po' balzane, ma forse nel senso ce l'hanno.

Io cerco di essere… capisco il tuo punto di vista, insomma, cerco di essere un po' messo nel termine equilibrato, nel senso che tante cose si fanno perché si devono fare.

Chiaro, chiarissimo.

In realtà, e con questo io vorrei provare a passare a un altro argomento, però talvolta spesso si prova a reinventare la ruota super autocritica, personale, perché non si è capita la ruota? C'è un principio che si chiama il Chester Tom Fence, che cosa dice? C'è un cancello in mezzo alla strada e un riformatore, un innovatore dice togliamo sto cancello, non ne vedo l'utilità, eliminiamolo.

Poi arriva il riformatore, l'innovatore intelligente che dice non vedi l'utilità? Ok, allora tu quel cancello da là non lo togli, te ne torni a casa, quando ne vedi l'utilità tu torna e ne discutiamo e possiamo anche toglierlo se vedi l'utilità.

Se non vedi l'utilità quel cancello sta là, probabilmente dovremmo essere o dovrei essere, lo butto su me stesso, un innovatore, un riformatore più intelligente piuttosto che un cambiamo tutto perché non mi sembra utile.

Tieni presente però che se il cancello davvero non ha un'utilità rimane lì.

Se qualcuno l'ha messo ha avuto un'utilità in un qualche tempo, quindi devi capirla e poi a quel punto puoi decidere di eliminarlo, puoi decidere di innovarlo.

Cioè il fatto di essere ritornati con l'XML, come dice Mario, probabilmente viene da quel punto, cioè non si è capito dell'impatto importante del relazionale, di quell'utilità, non si è capito a fine in fondo e si è provato a eliminarlo.

Chiudo qua.

Sì, tutte le decisioni dovrebbero avere una data di scadenza, quella è la verità, perché quando io scrivo un to do nel mio codice ci metto pure la data di quando ce l'ho messo, perché poi se no se non faccio così trovo to do che stanno là da otto anni e se per otto anni non l'ho fatto vuol dire che forse quello allora non lo posso togliere perché effettivamente non genera davvero il bisogno di tenerlo lì.

Io lo stesso vale per i ticket sull'issotracking, se il ticket sta aperto lì da sei anni e nessuno ci ha messo le mani c'è qualcosa che non va, per il cancello quel cancello lì si può togliere.

Darsi delle scadenze ragionevole e rivedere le proprie decisioni.

Secondo me l'unica domanda è una, questo cancello è fatto in Rust o no? E' stato fatto in Rust? Alla ruggine o no? Mi ricordo qualche anno fa il trend era lo rifacciamo in Go, ora è lo fatto in Go lo rifaccio in Rust.

Sì, hai ragione.

Tra due o tre anni sarà lo rifaccio in Zigg, tra tre o quattro anni lo rifaccio in Java, cioè non lo so, ormai è cifrica come economia.

Ricordo veramente che due o tre anni fa se andavo su GitHub e scrivo il nome di qualunque tool tra Tino Go usciva, ho rivisto AVK, SED, Datamesh, le cose veramente sto riscritto in Go senza nessun problema, era veramente divertente e lo sto rivedendo anche in Rust.

E poi trovi le cose che sono state fatte, che lo stanno facendo e che continueranno a farne in PHP e stanno lì, eterni, costanti.

Mi voglio però portare a questo punto visto che il tempo vola, la discussione su un altro elemento.

Abbiamo un po' tutti visto il post di Mario di ieri, quando è avanti? Credo che oltre a ieri, sì.

Sui pattern.

Ed è una critica che ha le sue radici e ci piacerebbe approfondirla un attimo con te e soprattutto ti chiedo come si lega quella critica al concetto o meno di reinventare la ruota? Beh, allora, credo che reinventare la ruota lì centri poco, anzi tu vuoi definire dei design pattern proprio per evitare quello, hai un problema, hai una soluzione codificata e non ti inventi da zero la soluzione e ce l'hai lì.

Il motivo per cui ho fatto quella critica al Gang of Four è semplicemente che ho scritto che è invecchiato male, ma nel senso che il problema di quel libro, e ho cercato di spiegarlo, è che ha un solo unico punto di vista che è quello dell'object orientation e quindi praticamente partendo da lì tutto diventa un oggetto e quindi invece di fare una funzione, di passare in giro una funzione, devo fare uno strategy pattern, invece di usare il pattern matching devo usare il visitor e invece di usare la function composition devo fare un decorator e invece di usare ancora la function composition devo fare una chain of responsibility.

Insomma, quello che volevo dire è che il difetto di quel libro è che c'è solo il punto di vista degli oggetti e quindi tutto diventa un oggetto, una funzione deve diventare un oggetto, tipo un command per esempio, ma quella in effetti è solo una funzione, gli stai mettendo attorno una infrastruttura d'oggetto, stai trasformando un verbo in un nome solo per motivi di paradigma di programmazione, ma non per motivi veri e quello che poteva essere ragionevole quando quel libro è stato scritto oppure qualche anno dopo quando Java è nato e è iniziato a diffondersi o altri programmi che erano pure object oriented, che avevano senso all'epoca, quei oggetti là non ce l'hanno proprio più, perché adesso un libro di design pattern non è che non dovrebbe esserci, ma dovrebbe tener conto del contesto nuovo, ma neanche tanto nuovo, visto che la Lambda in Java, per dirne una, è stato introdotta 8 anni e mezzo fa, non ieri, del contesto nuovo che c'è, quindi il problema di quel libro è che non è un libro rivolto a nessun programmatore che usa un linguaggio di programmazione moderna, nessun linguaggio di programmazione moderna è puramente oggetto, grazie a Dio.

Quindi non era contro il concetto di design pattern, ma contro il concetto di design pattern esclusivamente orientati al mondo degli oggetti, come viene proposto in quel libro lì.

L'altro aspetto che ho accennato e che ho visto qualche anno fa, adesso per fortuna non è più così, ma forse più che altro per quel libro non è più tanto così mainstream o forse online, quello che vedevo è che la gente buttava dentro questi pattern, dentro il proprio codice, in maniera convulsiva, senza un vero motivo, giusto per metterci il check box su lo strategia lo usate, il visitor lo usate, il command lo usate, il template lo usate.

Usandolo ti sto dimostrando che lo so usare.

Però ho visto, diciamo che nella mia vita lavorativa ho visto più danni che vantaggi fatti in nome di quei pattern.

Quello che è positivo che ci ha dato quel libro, e l'ho scritto, l'ho messo, è che ci ha dato un vocabolario comune.

Quando una persona, un programmatore dice qua ho usato uno strategy, ti sta dicendo una cosa che dovresti sapere, che c'ha un nome.

Il merito è stato quello di dare nomi a quei modi di implementare una soluzione.

Il punto è che quelle soluzioni avevano senso in un mondo puramente oggetti e adesso non è più il caso.

L'altra cosa che ho fatto, ma ripeto, è un discorso che va avanti da diversi anni, almeno da quando è stato introdotto la Lambda Expression in Java, quindi 8 anni fa.

6 anni fa fece un progettino in cui riscrivevo, prendevo degli esempi così come erano scritti nel libro del Gang of Four di Object Orientation e li scrivevo con quei progetti di programmazione funzionale che vi dicevo.

Andate sul mio GitHub e sicuramente lo ritrovate, quel progettino che si chiama FromGonFo to Lambda.

C'è anche linkato il video di un talk in cui facevo quelle trasformazioni in una sessione di programmazione funzionale, credo che fosse DevOx, non mi ricordo se quella è in bel gioco di NewGator, in fatti ne entrambi i posti.

Poi pure da lì è nato un trend, nel senso che qualcuno ha fatto lo stesso esercizio in altre linguaggi di programmazione tipo Swift e Godlin, ho cercato di linkare anche quegli altri esperimenti nel ritmo del mio progetto.

Questa è la motivazione da cui è partita la discussione, in realtà è partita per caso, perché domenica sera l'amico di un amico ha scritto io mi leggo il Goff, ce l'ho sul comodino, è il mio libro di programmazione preferito, mi ha fatto saltare un po' dalla sedia e da lì è partita la discussione.

Poi per come è stata presa, devo dire la verità, ho ricevuto delle critiche ovviamente, ma mi sembra che la maggior parte siano più commenti, diciamo che i commenti di consenso hanno allargamento sovrastato le critiche, quindi evidentemente non sono solo a pensarla così.

Questo ragionamento che ho avuto qui è un ragionamento, quello che si ha su Twitter e specialmente negli ultimi giorni è terribile, nel senso io ho letto alcuni commenti critici poi anche su altri account legati a QTT ed erano terribili.

Guarda, io a un certo punto l'ho mollato perché per me l'impossibile sarà presso tutti i commenti, insomma nemmeno me l'aspettavo, è vero che ho scritto un piccolo thread per cercare di chiarire la mia posizione, raccontare in maniera succinta quello che ho cercato di spiegarvi adesso in maniera un po' più estesa, però poi l'ho mollato voglio dire, se no la mia giornata lavorativa basta rispondere ai tweet, non mi pare in caso.

Io però quando ho visto la risposta del vecchietto scappato dalla casa di riposo che dice cose deliranti e continua a farlo… Stai parlando di Uncle Bob? Come hai fatto a capire che… Aspetta, però, perché secondo me quella cosa mi ha fatto capire un elemento importantissimo che fa parte del nostro approccio.

Noi trattiamo i testi, io in primis, come il libro, come se fosse il Vangelo secondo Uncle Bob, il Vangelo secondo Goff ed è sbagliato.

Ma quel libro in particolare è stato il Vangelo, e me lo ricordo benissimo, spero che non sia più così, ripeto, o spero che il mio tweet sia un piccolissimo contributo ad evitare che sia così in futuro, ma quel libro è stato il Vangelo per generazione di programmatori ed è stato anche il motivo per cui quando si è iniziato a parlare di programmazione funzionale, per esempio Java è arrivato dopo degli altri, ma anche in altri linguaggi, la gente ha fatto una fatica bestiale, ripeto, soprattutto in Java, perché in Java poi era diventato davvero avambibbio, come dici tu quel libro lì, la gente ha fatto una fatica bestiale a iniziare a usare bene le funzioni, proprio perché venendo da quella prospettiva lì non ci si ritrova più.

A semplificare il codice tra l'altro.

E tra l'altro c'è un altro elemento che voglio aggiungere alla discussione, perché in realtà veramente proprio quella risposta, della qualità che vi faccio vedere, andatevela a vedere e lo capite da soli, però quella risposta poi in questa riflessione personale mi ha fatto pensare a un'altra cosa e io c'ero cascato in pieno.

Abbiamo considerato la conoscenza dei pattern della Gang of Four come la discriminante per dire io sono un senior e so programmare e tu no.

Sì, per solo quella roba lì è stata usata, ripeto, pure questo spero non succeda più, ma è stata usata per fare un casino di interviste di lavoro.

Credo che migliaia di sviluppatori nel mondo, se non milioni, sono stati assunti o non assunti in base alla conoscenza dei pattern di quelli che fanno.

E' ancora così nelle università, è ancora così.

C'è qualcosa che non vale.

E i professori che insegnano la parte Java, insomma, programmazione ad oggetti così, lo considerano ancora come la Bibbia e osteggiano la programmazione funzionale nello stesso modo in cui tu stai raccontando.

Ma sai, io come ti dicevo, non è che osteggio niente, non è che osteggio l'object orientation, ti ripeto, ci sono diversi paradigmi di programmazione.

Io te ne parlavo di un terzo quando parlavamo del mio rule engine, c'è l'object oriented, c'è la functional programming, c'è la programmazione dichiarativa.

Un'altra cosa che ho cercato di dire nei miei tweet è questo, che vedo un sacco di persone che si vantano di conoscere dieci linguaggi di programmazione diversa, ma li usano tutte e dieci nello stesso identico modo.

E allora perché ne devi usare dieci? Perché devi fare Java, Scala, Kotlin e usarli tutti e dieci, tutti quanti nello stesso modo, non in maniera idiomatica.

Voglio dire, quello che invece è meglio è magari usare uno solo, ma usalo in maniera, io dico non deve essere poliglot necessariamente, ma deve essere poliparadigmatico, devi conoscere più paradigmi di programmazione, quanto più è possibile, perché quella è la tua cassettina degli attrezzi.

E poi molto probabilmente tutti quei paradigmi di programmazione, se usi un linguaggio di programmazione moderno, li puoi usare con lo stesso singolo linguaggio di programmazione.

E questa è l'altra cosa importante.

Vi ripeto, ho visto scrivere Scala come se fosse Java vecchio prima delle Lambda, però ho scritto Scala e allora che cavolo di senso ha? Mi sa che io ho visto Scala, Kotlin e Sprint scrivere come se fosse Java.

Però vi faccio una domanda e con questa chiudiamo perché ho visto l'orologio e siamo super oltre.

Se mettiamo sul tavolo i pattern, siano essi funzionali o a oggetti, e gli algoritmi, possiamo fare una distinzione in termini di impatto e di entità? Per algoritmi intendi strutture dati? Esatto, algoritmi e strutture dati.

Diciamo che siamo su due livelli di astrazioni un po' diverse, secondo me, due livelli di complessità pure diversi.

Alla fine quel libro, il Game of Four tra l'altro, è molto verboso, nel senso che è un concetto tutto sommato banale, tipo uno strategy, ci mette 25 pagine di testa per spiegarli col codice, con diagrammi OML, con i sequence diagram e che cavolo altro ne so.

Però se ci pensi quello è un concetto banale, se devi spiegare una struttura dati, che ne so, BlackTree, che è tutto sommato semplice, ma siamo su un livello di complessità che non ha paragono.

Penso che stiamo parlando di due cose su due piani un po' troppo diverse.

Ho visto l'orologio e ahimè io rimarrei, non so Scarmine e Luca, ma io rimarrei ore a parlare con Mario, ma dobbiamo lasciarlo andare a cena.

Quindi lanciamo rapidamente il nostro momento tipico e topico che è il Paese dei Balocchi.

Allora Mario, la mia domanda è, hai qualcosa da condividere con la nostra community? Allora sì, mi hai detto di questo format subito prima della nostra call, un po' mi ha divertito, devo ammettere, un po' mi ha spiazzato perché stavo ripensando a cosa, tra virgolette, portarvi in regalo.

Credo che vorrei portarvi in regalo il mio libro preferito, io ce l'ho lì, è un libro vecchio, ce l'ho lì da quando avevo forse meno di 18 anni e ogni 10 me lo rileggo, non è il Gang of Four, il libro si chiama in italiano Un'eterna Ghirlanda Brillante, non so se ne avete mai sentito parlare, l'autore si chiama Douglas Hopstadter, è un pensatone, filosofo americano, credo morto proprio da pochissimo, il libro è degli anni, fine anni 80, inizi anni 90 e parla di logica, del teorema di Gödel, di Escher, di come Bach componeva la musica e di come queste cose si sono influenzate fra di loro e in che correlazione stanno, quindi il titolo completo è Gödel e Escher, Bach, Un'eterna Ghirlanda Brillante.

Vi consiglio davvero davvero di leggerlo, io ce l'ho lì, ogni 10 anni lo rileggo, mi faccio più vecchio di 10 anni e scopro cose che alla lettura precedente non avevo capito e scoperto bene, quindi regalatemi l'alternata.

Bellissimo, hai aggiunto l'ennesimo libro alla pila di libri che io dovrò leggere, tenendo presente che ho solo pochi giorni per le ferie di Natale, ahimè, dovrò trovare il tempo per farlo.

Carmine, Luca? Vado io? Sì, io ho un consiglio e un libro per cambiare, il libro si chiama Design Pattern, no scusate, era un altro, no, un libro è un testo narrativo, un romanzo che anche io stavo cercando qualcosa da balloccare ormai, credo di aver balloccato quasi tutto.

Il libro l'ho letto, forse 15-18 anni fa, si chiama Improbable, di Adam Fowler, mi sono reso conto che tante cose che so di statistica lo devo a questo romanzo e credo anche gli devo un 29 in calcolo di probabilità e statistica dell'università e quindi, niente, ce l'avevo in mente e ve lo consiglio.

Credo che è lì che ho imparato il paradosso del compleanno, credevo di averlo fatto all'università, invece l'ho imparato proprio questo libro.

Il secondo ballocco è un consiglio, io da qualche mese sto dando ripetizione di matematica a una mia vicina di casa che fa la terza media, non so perché è una cosa che mi piace e soprattutto mi piace il fatto che, insomma, sto contribuendo a, diciamo, non voglio dire rendere migliore una persona, però ci siamo, quindi magari invece di stare la sera a casa a reinventarvi la solita ruota potete uscire e fare del bene.

Fare un po' di mentoring, il mentoring è importante perché è anche bidirezionale, si impara a mentire, impara ovviamente, ma anche a metterlo, c'è una comunicazione bidirezionale.

Esatto, impari tanto, impari anche a comunicare, impari a far capire, perché tu dici, ma io te l'ho spiegato, perché non stai capendo? Evidentemente non hai spiegato bene e se non hai spiegato bene forse non l'hai capita bene la cosa e sto parlando di matematica di terza media.

Quindi questo è quanto, vai Carmine.

Allora, io in realtà ho due libri, uno tecchio che ho finito di leggere un po' di tempo fa, che probabilmente non fregherà a nessuno, ma si chiama Testing Elixir, insomma diciamo per chi stesse cominciando con Elixir, insomma con chi si volesse affacciare in questo mondo qui, non è assolutamente, non mi viene da dire in italiano, direi straightforward, ma non so come dirlo in italiano, non è proprio semplice approcciarsi al testing quando, insomma, si fa nel mondo dei processi della concorrenza di Erlang con OTP, insomma, e le robe così, è un bel libro fatto bene e vi dà effettivamente un insight utile e pratico su come testare il vostro codice in questo caso e l'altro invece il libro che ho finito di leggere qualche giorno fa, ho finito di rileggere, mi è piaciuto come la prima volta ed è su Stile per Eira, di Tabuk, insomma, se vi capita di vederlo in libreria è un bel libro.

Io, è difficile perché in realtà li ho finiti tutti, però guardando qua a fianco al mio computer ho un libro che ho già portato, ma siccome è veramente figo ve lo porto per la seconda volta, è un libro che è dedicato ed è indirizzato ai manager, quindi ai tech lead piuttosto che agli engineering manager, ma secondo me da sviluppatore assume una lettura completamente diversa che va fatta.

Il libro è The Manager's Path e secondo me per ciò che riguarda le soft skill può essere un punto di riferimento che però mi piacerebbe mettere in discussione tra dieci anni per vedere se è ancora attuale e se i contenuti sono invecchiati bene o male.

Detto questo, io direi che il momento della sigletta è dei saluti.

Bene Mario, io sono super super super felice di averti avuto qua con noi.

Grazie a voi.

La chiacchierata è stata veramente figa, io non posso aggiungere altro.

È così che ci divertiamo.

Come diciamo di solito, da oggi Gitbar è un po' il tuo bar sotto l'angolo, nel senso che quando è qualcosa di bello che ti fa piacere condividere con noi, noi abbiamo sempre una birra fresca da invitarti per farci una chiacchierata e passare del tempo insieme.

Detto questo, io ti ringrazio nuovamente Mario, vi ricordo rapidamente i nostri contatti, info.gitbar.it, atbrainrepo su Twitter e il gruppo Telegram di Gitbar.

Prego prego che siamo più di...

Vai vai lo diciamo insieme, uno, due, tre, gruppo Telegram di Gitbar.

Siamo lì.

Siamo più di 1300, una varietà di attività.

Siamo 1138 Carmine.

Hai invertito il tre.

Sì, scusate.

Scusate.

Vabbè ma Carmine è avanti.

A parte che non so quando esce questa città, quindi va bene, vediamo, 1300, si parla di tanti argomenti diversi e se vi volete licenziare trovate anche io.

Detto questo io ringrazio nuovamente Mario e alla prossima.

Ciao! Ciao! Ciao, grazie! Gitbar, il circolo dei full stack developer.

Una volta a settimana ci troviamo davanti a due birre e con brainrepo parliamo di linguaggi e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei full stack dev..