Bene e benvenuti su Geekbar, questa puntata vedremo di portarla a casa ma non so in che condizioni Sono due settimane che non dormo e quindi potrei fare degli strafalcioni assurdi e non pago di questo Ho tirato fuori un argomento che di per sé ha un suo bel livello di complessità Ma per aiutarmi ad aprire questo vaso di Pandora, non pensavo ci fosse co tanta roba dentro ho due super super amici che mi accompagneranno in questa passeggiata verso un mondo magico e misterioso.Infatti ho con me Luca e Carmine.Ciao ragazzi E insieme oggi andremo a parlare di metà programmazione, ma lo faremo subito dopo avervi ricordato i nostri contatti info@gitbar.it per mandare l'email o @brainrepo su Twitter Ma soprattutto il nostro gruppo telegram abbiamo un gruppo telegram E benissimo, ma questa cosa non la diciamo mai Assolutamente tabù ormai è tabù no abbiamo un gruppo telegram un gruppo telegram che vedo fa lampeggiare proprio in questo momento il telefono vedo una marea di messaggi che arrivano siamo ormai davvero tantissimi più di 260 se ho visto bene no e all'interno del gruppo tantissime conversazioni interessanti quindi se non l'avete ancora fatto mi raccomando iscrivetevi ma detto questo io direi che abbiamo messo tutte le carte in tavola e possiamo iniziare Benvenuti su github il podcast dedicato al mondo dei full stack developer i mezzo artigiani, i mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo Bene, oggi parliamo di metà programmazione ma la prima cosa che ci viene in mente con la metà programmazione è che non sappiamo cos'è.Questo è stato il mio primo vero approccio alla metà programmazione.La metà programmazione, a parola, metà programmazione è una di quelle etichette che attacchiamo su qualcosa ma che riconosciamo solo quando abbiamo attaccato quell'etichetta, cioè una roba che utilizziamo tutti i giorni probabilmente ma non sappiamo che si chiama metà programmazione e quindi ci spaventa.Per cui che cos'è la metà programmazione.Intanto partiamo dal dire che la metà programmazione è una tecnica di sviluppo che ha un presupposto fondamentale.Il presupposto sta nel fatto che questa tecnica tratta pezzi di codice come se fossero dati e il suo obiettivo è quello di leggere generare analizzare e trasformare dei pezzi di codice dei software per farlo o a build time o in fase di esecuzione.La prima volta che abbiamo incontrato la metà programmazione, io sono sicuro che ognuno di voi l'ha incontrata, è la prima volta che abbiamo visto un Eval Eval o Evil, dipende un po' dalla prospettiva con il quale lo si guarda E lo troviamo già dalla note dei tempi nei linguaggi Molto prima di altre funzionalità, come per esempio in JavaScript, Eval era presente prima del try e catch quindi veramente diciamo è uno dei basamenti del linguaggio, delle fondamenta del linguaggio.Ma quello che voglio chiedere ai nostri compagni di viaggio oggi è avete mai usato eval nel vostro linguaggio preferito e se sì quando? Vado io come prima cosa.No è curioso il fatto che l'eval ce l'hanno un po' tutti i linguaggi almeno tutti i linguaggi con cui ho avuto a che fare, però la cosa bella è che nella documentazione ti dicono come prima cosa non usarla.Ma allora che cavolo me lo dai a fare? Sono anni che questo tarlo mi tormenta.Come le sigarette con la scritta "non fumare".Esatto, prima me lo dai e poi mi dici "mi raccomando non usare".Ma come? Poi bello te lo documentano anche e ti dicono.In realtà però effettivamente ci sono dei casi in cui un eval ti salva la vita, probabilmente poi per ucciderti subito dopo, perché altrimenti non sarebbe l'eval, però sono molto pochi e molto specifici.Ultimamente, me l'hai ricordato tu, poco fa l'ho fatto in Node.js, in realtà non proprio l'eval, ma era una funzione che prendeva sostanzialmente una stringa di cui poi faceva level e in quel caso ha salvato praticamente tutta una serie di situazioni, ha ridotto la complessità del programma in buona parte, un buon 20-30% e contemporaneamente aveva risolto un problema che quel programma si portava dietro.Era un progetto di un amico, lo possiamo dire, era un progetto di un amico e ero quasi timoroso, dicevo "ma si può fare? Oddio, adesso sto usando Level, questo minimo mi spara, perché già faccio la prima pull request, non mi conosce, non sa come programmo la prima cosa pull request che faccio c'è di mezzo un eval, non mi parla più.Però poi invece alla fine la cosa buffa è che ha accettato la pull request, alla fine sì, era la soluzione giusta al problema giusto.Unica volta che mi è capitato nella vita mia per l'eval in javascript.In PHP l'ho usato una volta e lo uso ancora tuttora nella nostra codebase in azienda per il templating, per velocizzare, per evitare di avere un file...Insomma, manco mi ricordo sinceramente qual era il problema, però avevo visto che usando level incrementavano le performance del 300% poi sono andato a vedere Twig in PHP e usava lo stesso identico meccanismo.Quindi ho detto ok, allora l'Eval in questo caso può andar bene.Poi magari domani mi bucano tutto, ma intanto le cose stanno andando.Quindi l'Eval a volte, finora due casi in 18 anni credo che programmo.Mi sembra una buona idea.Giusto, giusto un inciso.Twig, che cos'è Twig? è una libreria di template creata dalla Sensiolabs e della libreria di template di default che utilizza o utilizzava adesso sono un po fuori dal mondo Symfony giusto per avere un pelino di contesto.In realtà è un componente separato quindi lo si può usare in progetti diversi e non strettamente legati a Symfony e tu mi dici appunto che anche là dentro ci hai visto delle eval.Ci ho visto un eval per esattamente lo stesso problema che cercavo di risolvere io nel mio template engine che stavo facendo, perché sai che le cose io me le faccio in casa, perché queste diavolerie moderne non mi interessano e niente, questa cosa mi ha rincuorato perché sai, mettere un eval in una tua libreria, tu non ci dormi la notte, almeno io non ci dormivo, non ci avrei dormito la notte per una cosa del genere, specie se sei pagato per farlo.Per mettere eval.Se sei pagato per fare codice e poi ti beccano a mettere eval e codice, è una cosa abbastanza pericolosa.Però appunto il problema era quello giusto in questo caso.Ma in realtà io qui dico una cosa e poi subito scappo, l'ho usato diverse volte, l'ho usato diverse volte specialmente nella roba con cui purtroppo ho dovuto lavorare che era Super Super Legacy.Super Super Legacy stiamo parlando ad esempio c'era questo back-end monolitico che sostanzialmente su alcune chiamate Ajax, restituiva del JavaScript non con il content type giusto e quindi sostanzialmente era questa stringa di testo con dentro del codice con dentro delle istruzioni di jQuery che doveva essere eseguito per far aprire e chiudere cose.quindi mi sono trovato ad utilizzarlo e secondo me una cosa magari che ci si dimentica è che noi spesso usiamo delle astrazioni, dei framework, delle librerie che non ci fanno fare Eval, ma che loro invece lo fanno.Quindi alla fine spesso e volentieri al cuore di tanti progetti, di tante librerie che si usa, c'è comunque un eval.Perché in alcuni casi d'uso sono anche abbastanza spinti.Dove c'è metà programmazione c'è l'eval.E non sto parlando solo di JavaScript in questo momento, sto parlando di qualunque linguaggio.Quindi che può essere JavaScript, che può essere Ruby, che può essere, non lo so, Python, Comunque, qualunque cosa, ce l'ha l'EvalPython, probabilmente sì.Ma qualunque cosa, diciamo qualunque linguaggio, secondo me in alcuni casi d'uso ha il suo senso di...esiste l'Eval, anzi, ritornando al discorso templating di prima, secondo me in quasi ogni framework più o meno moderno web, la combo templating + eval è imprescindibile.Da qualche parte sì, sicuramente c'è.L'eval diciamo che è la porta d'ingresso per la metaprogrammazione.Perché? Perché ci permette di trattare il nostro codice come una stringa e poi di eseguirlo.Ma quando si parla di metaprogrammazione, diciamo, la prospettiva che ci si apre davanti è abbastanza ampia e profonda.La prima distinzione che ha senso fare quando si parla di metà programmazione è quella di metà programmazione a build time e metà programmazione a run time.Per preparare questa puntata ho letto per esempio che TypeScript in quanto tale può essere interpretato come un metalinguaggio perché di per sé insieme al linguaggio abbiamo tutta una serie di costrutti per elaborare lo stesso linguaggio che poi naturalmente viene viene trasformato in javascript.Questo potrebbe, alcuni lo definiscono come metaprogrammazione a build time.In realtà è un po' controversa la cosa, ho visto che ci sono parecchie discussioni però se volessimo parlare di metà programmazione a build time mi viene in mente suitejs.Probabilmente nessuno di voi l'ha mai incontrato nella sua via.Ma che cos'è? è semplicemente un linguaggio che poi viene traspilato in javascript e che permette l'utilizzo di un concetto che è il concetto di macro.Che cos'è una macro? Una macro è uno strumento che ti permette di definire i tuoi operatori.Quindi in realtà è uno strumento che ti permette di definire il tuo linguaggio all'interno del linguaggio.E ci sono tantissimi linguaggi di programmazione che lo permettono.Per cui abbiamo la possibilità di andare a creare la nostra sintassi all'interno del linguaggio.Questa cosa è molto utile, specie quando lavoriamo con un linguaggio o in un progetto la cui vastità è molto ampia.le cui figure coinvolte all'interno dello sviluppo del nostro progetto sono eterogenee e per vastità non hanno la capacità, la forza, il tempo di conoscere tutto il dettaglio.Per cui alcune estrazioni implementative possiamo trasformarle semplicemente in sintassi.Si impara la sintassi, tutto il resto è trasparente, ci vediamo attraverso, quindi non lo vediamo e lo sviluppo diventa più semplice.Voi le avete mai usate in qualche progetto, in qualche contesto? Io non ho mai usato una macro in nessun linguaggio, ma ne sono sempre stato affascinato.Ho letto diversi sorgenti in C e in C++ dove c'erano queste cose stranissime che generavano altre cose stranissime e facendo altre cose stranissime e devo dimenticare sono abbastanza ignorante in maniera.Quando ho fatto metà programmazione l'ho sempre quasi fatta con dei linguaggi che mi permettevano di farlo a runtime.Non ho mai definito una macro in vita mia, forse in elixir ma tipo nel tutorial proprio che c'è sul sito.Non ho mai avuto esperienza, ho avuto amici che erano i maestri del macro e del templating c++ e li ho sempre invidiati anche per la grande pazienza con cui facevano quella roba, io non ce l'avrei mai fatta.Io nemmeno più o meno, stessa esperienza, so che tipo in PHP c'è qualche libreria che fa macro, ne avevo trovata una, ma credo anche quasi abbandonata, cioè IAI, YAY che definisce macro.Per me non mi attirano, diciamo così, perché alla fine sì, è quello che dici, crei un altro linguaggio perché stai usando un meta linguaggio o un nuovo linguaggio da dare in pasto alla tua tuo programma, quindi da dare come input al tuo programma che ti da come output un altro programma.Però che cosa vuol dire un altro linguaggio? Vuol dire che te lo devi quantomeno documentare, è un linguaggio che ti devi inventare, quindi è una tua, diciamo, la opinione, un'opinione ha un problema, una tua soluzione, ha un problema che poi regalerai ai posteri e che quindi se canni la tua soluzione, la tua opinione, i posteri ti possono anche non ricordare in modo carino e simpatico.Assolutamente, anzi, secondo me una cosa che vorrei dire a tutti gli spettatori di questa puntata è metà programmazione fa rima con documentazione e non a caso, perché spesso e volentieri ho visto specialmente i YouTube delle cose bellissime, di una complessità mistica che tu guardi quel codice sorgente e poi vedi l'infinito e non c'è una riga di commento e dovete vedere quanto è brutto quando vedi una cosa nella stack trace che se la cerchi nel sorgente non c'è e mori dentro.Quando fate questi grandi pezzi d'artista documentate tutto, per voi e per i vostri colleghi.Infatti, anche perché sono cose che poi tu non ci puoi arrivare manco pregando a quello che fa quel pezzo che stai guardando, perché effettivamente non ha una logica visibile.cioè con le macro, poi addirittura con questa libreria qui del PHP, potevi dire addirittura che il carattere dollaro, così vuoto, era l'equivalente di dissa.C'è, cavolo, grande guadagno di complessità, però, cioè poi alla fine come fai? Cioè lo guardi, come fai a capirlo? Non puoi, cioè, deve essere documentato da qualche parte e comunque di sicuro non è documentato dove stai guardando, perché non è che per risparmiare a scrivere dis, ti devo scrivere un commento sopra tutte le volte che lo uso.E quindi, cioè, bisogna stare molto molto attenti.Io questa metà programmazione la considero un po' un gradino sopra l'hack.L'hack a volte, cioè, l'hack è male e quindi è il male sempre.Però l'hack risolve magari tanti problemi, ti risolve il problema di riscrivere, di rifattorizzare, eccetera eccetera, però alla fine ti aggiunge pian piano complessità.La stessa cosa possiamo dire di alcune pratiche della metà programmazione.Mentre parlavi, mentre parlavate, mi è venuto in mente un parallelismo.Dittemi se secondo voi è una fesseria o regge la metà programmazione per sé come concetto, in fase proprio quando quando lo applichiamo, è un qualcosa di classista.Nel senso che fa spartiacque tra chi conosce quel costrutto e chi non lo conosce.Sì, secondo me fa da spartiacque tra chi usa il linguaggio e chi lo conosce.secondo me questa è ancora più una divisione più netta.Eh, fammi capire meglio questa...Allora, ad esempio, vi prendo l'esempio, quello che io c'ho più fa...fa...fa...mi da le Ruby.Ho conosciuto diversi programmatori bravi in Ruby che comunque facevano il loro lavoro, sostanzialmente erano più che altro applicazioni web fatte con Rails, ma di, diciamo, delle grandi potenzialità che ti offre il linguaggio, infatti di metaprogrammazione, di code generation, di monkey patching, ha tutto un sistema Ruby anche, diciamo, con i mixin, puoi fare delle cose veramente spaventose, sia in senso buono, sia in senso cattivo, non conoscevano nulla, un po' perché magari non gli era mai servito.quindi non avevo mai diciamo approfondito anche quell'aspetto lì.Io che mi sono concentrato più che altro su quell'aspetto lì perché ero interessato, io sono affascinato da tutta questa parte dei linguaggi di grammazione, specialmente come viene fatto il rubri, credo sia veramente, cioè se ci si pensa bene, sicuramente fuori di testa e bellissimo allo stesso tempo, arrivavo a risolvere ed approcciare alcuni problemi in una maniera totalmente diversa.E mi rendevo conto di quando discutevo quella soluzione che avevo trovato con quegli strumenti lì, c'era effettivamente un bel gap, che poi magari avevo fatto una cosa bruttissima, un attrezzo complesso semplicemente perché mi andava, però effettivamente era così, che credo che una cosa possa fare tanto da spartiacqua anche magari tra non voglio dire l'amatoriale e l'esperto perché non credo sia così, però non mi viene in mente una definizione diversa, diciamo da, ecco esatto, da chi lo usa e da chi lo conosce, non so, mi sentirei di dire questo, almeno per la mia esperienza.Sì, beh, non saprei, credimi.Certo è che in realtà molti di noi utilizzano i linguaggi senza conoscerli a fondo e quando si vedono davanti queste cose mistiche diventano incomprensibili.come è stato incomprensibile per me vedere la prima annotation che faceva qualcosa nel codice php in realtà è stato scioccante prossimo alle lacrime per poi usarle come un martello dappertutto anche per stendere la pasta per la pizza detto questo però continuiamo a esplorare un po il mondo della metà programmazione e ci spostiamo invece sul concetto di metà a runtime che è fondamentalmente quando il nostro bel codice viene chiamata anche reflection questa branca della metà programmazione ed è un po' come quando il nostro codice si guarda allo specchio e prova a capirsi, comprendersi e interviene su se stesso facendo del make up.Un po' questa metafora secondo me lo rappresenta abbastanza bene.In realtà l'azione della reflection, quindi della lettura, analisi, comprensione del codice da parte di un nostro blocco di codice e della modifica dello stesso si divide in tre tipologie specifiche.La prima è l'inspection, il nome lo dice chiaro cioè quando il nostro codice va a ispezionare un altro blocco di codice e lo fa a run time.Io vengo dal mondo javascript quindi la prima cosa che mi viene in mente sono alcuni costrutti del linguaggio javascript per esempio alcune metodi dell'api object di javascript fanno inspezione.La prima cosa che mi viene in mente è "object keys" oppure "object entries" non fanno altro che fare inspezione dell'oggetto per andare per esempio "object keys" a prenderne le proprietà e quella di per sé può essere definita metaprogrammazione.Un'altra cosa che utilizziamo per fare inspezione come metaprogrammazione sul php sono le "annotation" cioè la reflection API di PHP per andare a leggere per esempio le annotation nel codice o il nome delle classi o qualunque cosa per andare poi a comportarci di conseguenza.Adesso la mia domanda è avete mai usato la tecnica di inspection? se sì in quali casi d'uso? io alcuni li ho citati poco fa però immagino ce ne siano anche degli altri.Per la validazione credo sempre, alla fine anche, credo, qualunque libreria di validazione magari di strutture dati in generale faccia questa cosa qui, alla fine anche quando magari in JS usiamo costrutti come typeof, instanceof, stiamo effettivamente facendo questo.E una cosa magari a cui non pensiamo, e io ci sono pensato proprio in questo momento qui, Alla fine tutto il web moderno, tutta la parte front-end moderna, mi sicuro meglio, è basata sui polyfill.I polyfill non fanno nient'altro che fare monkey patching.Quindi alla fine la usiamo tutti i giorni, ma spesso non ci rendiamo nemmeno conto.Sono tanti costruttori che fanno parte della nostra quotidianità e non ci facciamo manco caso.Sì, infatti, pensandoci, praticamente vengono usati ogni giorno questi strumenti.In APHP c'è il distance off, dove in base alla tipologia di un input ti comporti in in modo diverso, e quello è introspezione.Come anche usando la reflection, a livello applicativo non la uso spesso, proprio perché mi secca poi doverla documentare, però a livello invece, se sto costruendo una libreria o un meccanismo di routing o qualsiasi altra la reflection dei metodi che poi vado a vedere quali sono gli argomenti che accetta, addirittura qual è il nome dell'argomento che accetta, in base a quello mi regolo e gli do in pasto gli argomenti che vuole.Anche quella è una cosa comoda e funziona, quando l'ho fatta questa era una cosa che avevo provato proprio quando avevo scoperto questa magia della reflection.e ho provato così.Mi spaventa, devo dire la verità, all'inizio mi ha spaventato il concetto di annotation in PHP perché, cioè per me il fatto che un commento che è a tutti gli effetti un commento che va a interferire col codice per me era una cosa fuori dal mondo.In che senso un commento, perché io poi non faccio PHP, ora sono curioso.No, in PHP non c'erano, fino alla versione 8, quindi che dovrebbe adesso ci sono con la 8, non c'erano le annotation, quindi c'erano le librerie, i framework esterni, come Symfony se non sbaglio, che con questi meccanismi di reflection possono andare a leggere i commenti, il PHP doc sostanzialmente del metodo della classe e una volta letti ce l'hanno come input se lo parsano e quindi poi lo trattano come annotation vero e proprio.Però io all'epoca il concetto di annotation non ce l'avevo quindi per me era un commento questa cosa che a tutti gli effetti è un commento santo cielo.Le annotation di DPRP mi hanno fatto fare le porcate più grandi della mia vita.Cioè...Eh beh, appunto bisogna stare attenti a queste cose.Anche perché poi c'è un povero pirla come me che non le sa queste cose.Ma come fa ad arrivarci? Ti spiego un caso d'uso, un caso d'uso molto semplice.Symphony le utilizza per un gozzilerdo di cose, dalla validazione, o almeno le usava quando utilizzavo io symphony dalla validazione a tu scrivi la tua classe controller poi ci metti una bella notation e ti genera il router e ti fa già il mapping della rotta bella pronta che burro ragazzi alla definizione degli elementi di persistenza quindi mettendo una notation tu sai che dov'è il tuo repository di entity e ste belle cose qua.In realtà io devo dire che le annotation e questo livello di metà programmazione che poi viene gestita in un secondo momento mi hanno permesso di semplificare tantissimo la scrittura di alcune parti che poi sarebbero dovute essere riutilizzabili da altri sviluppatori.Io qualche anno fa ho fatto un DMS che era un Destination Management System, un pezzo di codice abbastanza grosso, dove in realtà dovevo trovare il modo semplice per utilizzare una libreria di autorizzazione, quindi quella libreria che diceva "questo utente può entrare e questo utente no e dovevo permettere di far utilizzare questa libreria di autorizzazione a qualunque sviluppatore senza dover scendere nel dettaglio della libreria di autorizzazione perché la libreria di autorizzazione lavorava su tre livelli utente organizzazione e territorio e i diritti dovevano essere incrociati tra questi tre utenti quindi immaginate la complessità del sistema autorizzazione se avessi dovuto spiegarlo a tutti i dev sarebbe stata un'operazione impossibile, no? invece cosa ho fatto? semplicemente c'erano dei pattern a notation già belli pronti lo sviluppatore copiava il pattern, qua il controller era blindato per quella specie di utenza particolare quindi in quel caso mi è stato utile perché? perché si è dimostrato un ottimo vetro quindi trasparente per tutta quella complessità che altrimenti in qualche modo avrebbero dovuto conoscere magari attraverso una chiamata un metodo o in qualche altro modo invece così per loro era del tutto trasparente quella complessità e neanche ci pensavano ecco secondo me in questo tipo di situazioni Le annotation e quindi la metà programmazione in genere può essere utile La costruzione quindi di un metalinguaggio che tu utilizzi nella tua applicazione e ha senso farlo quando la tua applicazione raggiunge certe dimensioni, non prima, perché se no è un po' overkill la cosa e soprattutto anche abbastanza stupida, però una volta che tu raggiungi certi livelli devo dire che ti toglie le castagne dal fuoco.ma infatti poi, la mia reazione che ho descritto poco fa era la reazione della prima volta che avevo visto le annotations, poi quando ho avuto esperienza e ho fatto le cose, magari ho fatto le mie librerie, ho fatto i miei framework e non le volevo usare queste diavolerie moderne, per quanto moderne possano essere, alla fine a conti fatti mi son pentito perché appunto, le annotation riducono la complessità, le annotation evitano di farti andare nel dettaglio dove nel dettaglio non devi andare, perché altrimenti poi il codice non è più leggibile e l'applicazione diventa astrusa, perché anche se metti tanti livelli di astrazione, anche seguire i livelli di astrazione subito dopo non è la cosa più semplice del mondo, alla fine forse dove bastava qualche annotation, che nel PHP 8 adesso sono chiamati attributi, se mai qualcuno lo volesse cercare, risolverebbero quindi, risolvono tanti problemi.Certo bisogna saperli usare perché altrimenti, come detto, sono hack, è bello una volta, la seconda volta, la terza volta quando sei inesperto dici "ah che figo, quanto sono bravo perché con un carattere riesco a fare quello che voglio, con una riga riesco a fare ad aggirare questo problema" e poi dopo due settimane non capisci più niente di quello che fai.Ripeto è un gradino sopra questo, sono un gradino sopra gli hack.Carmine tu hai avuto qualche esperienza con notation e in genere con la parte di inspection, quindi di lettura del codice, di parsing del codice da parte di altro codice? Allora sì, sì, l'ho avuta sempre in Ruby, che come, cioè, se non si fosse capito, è il mio linguaggio preferito, anche se non lo uso ormai tutti i giorni al lavoro, ed è anche il mio martello preferito, come avete capito.E ci ho fatto tante cose anche in quest'ottica qui.Alla fine, la metà programmazione è qualche cosa che può andare molto a braccetto con la creazione di un DSL, di un Domain Specific Language, che in questo caso, nel tuo esempio, era fatto con le annotation di PHP, diciamo anche in Ruby con Rails, ci sono tante librerie di autenticazione che funzionano in questo modo qui.Il concetto di annotations come in PHP non c'è, però ci sono altri meccanismi in cui fare embedding di un pezzo di codice che può fare inspection, che può fare reflection e può aggiungere metodi, può aggiungere middleware ad un controllere, può fare qualunque cosa.Diciamo, questa è una cosa che a me piace molto, che ho fatto tanto, anche perché insomma il Ruby e il CoreOS in generale è lo stesso framework, oltre che il linguaggio ti spinge su quella cosa lì, però mi sono ritrovato anch'io in situazioni in cui mi sono dato la zappa sui piedi da solo.Io in realtà ero figo all'inizio, arrivato ad un certo livello di complessità, effettivamente più ci sono in cartato space.Ecco, diciamo che se lo dovessi rifare, farei molto meno il figo con quella cosa lì e adotterei una soluzione che magari è più convenzionale, tra virgolette, ma più manutenibile anche da altre persone del team.Insomma, nel senso, a me piacerebbe far passare il messaggio che sono strumenti molto potenti, ma se non sono usati con la parsimonia e con la coscienza di quello che si sta facendo, viene veramente una cosa brutta.Vi faccio un esempio di tutto quello che secondo me non dovete fare e che io ho fatto.Relativamente ero in un controller, che era uno dei miei primi giorni da rubista junior, che si era appena finito di leggere il libro "Meta Programming Ruby", che tra l'altro vi consiglio di leggere se fate Ruby o volete fare Ruby.E quindi sono andato in questo controller, ho fatto questo array con questi simboli dentro, ci ho ciclato sopra ed ho creato questi metodi a runtime che erano le action del mio controller con una definizione presa da un file, una roba che mi sembrava spaziale.Dopo tre, quattro giorni non sappiamo più quello che cazzo stavo scrivendo.Quindi nel senso sono bellissimi strumenti, usateli con parsimonia.che quel mio pezzo di codice sia ancora in produzione, ma arrivare ad un certo punto fatto più righe di commento che di codice.Ovviamente questa, insomma, è colpa mia, perché non ho saputo, diciamo, usare lo strumento nel modo giusto, però arrivare a farsi sfuggire di mano la situazione è molto molto semplice, secondo me.Specialmente se vi lasciate prendere dalla cosa, insomma.metaprogrammaziosi ma responsabilmente.Diciamo così.Sì, ma hai ricordato? Anch'io ho fatto una roba del genere in PHP, una classe praticamente vuota, dove c'erano solo annotation e ti generava un crude controller che ti faceva la validazione a partire dai dati, una cosa veramente aliena che poi...cioè, la cui paternità poi neghi fino alla morte, Devo dire.Esatto, no no, ma infatti quello che posso dire è che il bello della metà, della metà programmazione, se avete una code base grande, quindi magari avete anche delle librerie che vengono incluse dentro, arriva anche magari il vostro collega povero che non ci ha mai messo mano ma è l'ultimo sul GitBlame per quella riga di codice e basta, è finita."Ma scusa, ma te me lo fai un po', non so cosa significa".E questo va scappato.C'è anche da dire che appunto a volte, insomma, anche quando lo fai bene, cosa di cui sinceramente non ho esperienza a fare bene le cose, intendo.Che cosa succede? Succede che ti è facile andare a modificare il programma, no? Molto spesso.E quindi che cosa, qual è il drawback? È che, essendo facile modificarlo, lo modifichi volentieri.Quindi se hai una richiesta, se ti cambia qualcosa, se ti arriva il venditore o quello che è che ti chiede questa modifica, tu la fai perché non ti costa nulla, perché hai fatto un sistema che è altamente flessibile.Però a volte comunque vai a complicare, per ogni modifica che fai vai ad aumentare la complessità, magari a volte impercettibilmente, però la aumenti.A volte è meglio avere davanti un mostro che dici "no, no, questa modifica mi ci vogliono due mesi e mezzo" e poi chi te la chiede dice "va beh, allora non fa niente" e hai risolto in un modo o nell'altro, anche senza metà programmazione, hai risolto in modo più efficiente perché alla fine non hai aumentato la complessità della la tua applicazione.In questa frase mi hai riportato alla memoria una persona che definiva un PM, un project manager, un product manager lavandino che prendeva tutte le richieste e le colava sotto.Invece in questo caso lo trasformi in un product manager schermo che riflette praticamente tutte le richieste.È troppo complesso.Alla fine avere qualcosa su cui intervenire è un pelo più difficile, ti fa anche pensare un po' di più a questa modifica, ma davvero la vogliamo, ma è proprio necessaria.Ovviamente se sei un bravissimo project manager non hai bisogno di questi trucchi, però forse per noi comuni mortali forse sì.Mi ricordo c'era un mio collega che la chiamava metà programmazione perché è metà programmazione e metà bestemmi e metà bestemmi e magia.Quindi c'era tutta questa cosa, mi ricordo che passiamo ore a fissare tre, quattro righe di codice e tu dici "ma stai un bel cazzo a fare, boh non lo so, a stack trace si ferma qua" ma a stack trace dove? buh non lo so, cioè quindi tutto questo guardare queste due teorie è maledire noi stessi perché se l'ha fatta quella cosa lì.Però questa cosa qui a me affascina tanto, non so se a voi affascina.Sì, è il fascino di costruire il tuo linguaggio che secondo me fa la differenza.Esatto, il fascino, ora qui entriamo proprio nel filosofico mistico, però a me piace perché lo trovo che sia un modo per dominare lo strumento in tutto e per tutto, per piegarlo alla tua volontà, alla tua creatività, più di questo non c'è più niente.Insomma, al di là dell'algoritmica, della correttezza, avere la possibilità di intervenire a questo livello di dettaglio e di volontà del programmatore sullo strumento è una cosa che mi affascina garantissimo.Crea la tua lingua per raccontare le tue cose no? fondamentalmente è questo il ragionamento.Ci prendiamo un attimo, un secondo di pausa per ringraziare il donatore di questa settimana.La donazione è avvenuta pochi minuti fa mentre eravamo già in registrazione.Io devo ringraziare Ezio Frassi che ci ha invitato 5 birre scrivendo podcast e gruppo telegram spettacolari.Da malato cronico di sindrome dell'impostore, benvenuto tra gli impostori direi io, e papà alla continua ricerca del giusto work life balance.Buon lavoro.qua abbiamo Luca che dispensa consigli sulla gestione familiare su cosa non seguire, su cosa non fare non avete idea di quanto mi abbia fatto bene ascoltare gli episodi dedicati a questi argomenti complimenti e continuate così ora però vogliamo Zimuel allora per quanto riguarda Zimuel io l'ho contattato l'ho ricontattato l'altro giorno per fissare un'altra giornata Insomma per un'intervista non mi ancora disposto non vorrei se la fosse presa per Per come alcuni ammutinati hanno visto il biancapino scherzo sicuramente risponderà a brevissimo Organizzeremo tra l'altro L'intervista avremmo dovuto registrarla quindi per colpa mia non si è fatta però a brevissimo recupereremo tranquilli Detto questo riprendiamo un attimino le fila prima stavamo parlando di metà programmazione a runtime in realtà Ognuno di noi l'ha sempre usata la metà programmazione quello che io sto buttando qua sul tavolo Come definizione diciamo che è stato un po il modo con cui mi sono ritrovato a, come dicevo prima, attaccare etichette a robe che già usavano e ho trovato questa ulteriore etichetta che si chiama "self modification".Che cos'è la self modification? La self modification è quell'atto che fa il nostro codice che fa sì che il nostro codice vada a modificarsi al runtime e quindi a modificarne i suoi comportamenti.Questa cosa può sembrare super astrusa, ma la utilizziamo tutti i giorni.Immaginiamo di voler accedere a una proprietà di un oggetto dove il nome della proprietà ce l'abbiamo dentro una variabile.Quella di per sé è definita metaprogrammazione ed è l'atto appunto della self-modification perché stiamo controllando il comportamento del nostro codice a partire dal codice.Strano no? Sentire questa azione che facciamo costantemente etichettata come metaprogrammazione, cosa ne pensate? In questo momento sto vedendo il meme di Toy Story con il tizio che abbraccia e fa metà programmazione, metà programmazione ovunque.C'ho questa immagine, no, ed è effettivamente vero, lo siamo spesso, un po' ovunque.Io sinceramente no, non l'avevo mai codificato in questo modo.Essendo programmatore non aver codificato una cosa è molto grave, però siamo qui in un bar e siamo anche sinceri.Quando l'ho fatta l'ultima volta, direi per fortuna circa tre mesi fa, perché è da un po' che non programmo, però sì, anche lì forse non sempre si dovrebbe fare, a volte farlo può portare più problemi che soluzioni e ve la lascio qui al lettore il compito di dimostrare perché adesso ci penso anch'io un attimo, mi è colto alla sprobista.Ma alla fine secondo me si va sempre diciamo appunto su questa cosa che hai detto che spesso utilizziamo, diciamo, degli strumenti, anche delle funzioni, delle caratteristiche avanzate dei nostri strumenti e non ce ne andiamo nemmeno conto.Ad esempio, quando scriviamo "testing", no? Scusa, quando scriviamo "test", il nostro framework preferito, il linguaggio preferito, il nostro tool preferito, e stiamo magari usando una libreria per il che fa mocking o che fa stabbing.Noi stiamo utilizzando tutto quello che noi stiamo dicendo ora.Quindi magari, diciamo, è molto più presente nel nostro svolgere il lavoro quotidiano di quanto possiamo mai pensare.Alla fine, se voi utilizzate "u" norma in un linguaggio, diciamo, interpretato, voglio prendere proprio super super super super generica, al 90% state utilizzando qualche cosa che fa uso di tutte queste tecniche.In un modo oppure nell'altro.Se avete memorizzato ad esempio Active Record, io faccio sempre lo stesso esempio insomma, state utilizzando una metaforamazione molto molto spinta, sostanzialmente nel vostro codice delle classiche sono vuote, ma su cui sono presenti, guarda un po' dei metodi, degli accessi, comunque delle proprietà, che sono proprio i campi della vostra tabella.E noi quelle proprietà non le abbiamo mai scritte, quei metodi non le abbiamo mai scritti.e ovviamente non l'abbiamo mai scritto, quindi diciamo ovviamente non è magia, ma è quasi magia.se ci pensiamo bene.Abbiamo del codice che si è adattato allo schema, alla forma del nostro database.Cioè è una cosa secondo me bellissima anche solo pensare, è una cosa bellissima ed è una cosa ovviamente che magari può dare anche un po' di timore, perché alla fine il trade off è o meno controllo su questa cosa qui, ma prendo tutti i vantaggi di non doverlo riscrivere ogni volta per ogni singola cosa.Certo, l'automagia affascina.No, no, infatti, assolutamente.Dipende da quale livello del tuo codice sei, cioè se sei a livello applicativo, se stai scrivendo una libreria, se stai scrivendo un framework, se stai scrivendo dei test, ovviamente il problema che deve risolvere deve essere quello giusto, scontato dirlo però.Carmine, prima hai parlato di Mocking, in realtà noi abbiamo il massimo esperto di Mocking che oggi ci ha dato Bucca e lo salutiamo, Mattia, come in realtà avremmo dovuto avere anche qualcuno che ci poteva parlare di l'ISP, no? E quindi diciamo che lasciamo ai prossimi episodi un follow up con Mattia che ci parla di Mocking e Alessio che ci parla di l'ISP e omoiconicità.Perché in realtà, devo dirlo, io ho provato a leggere qualcosa, a sull'omo-omo o iconicità.Ho capito che cos'è ma non sono in grado di spiegarla.Quindi vuol dire che non l'ho capito abbastanza bene e lasciamo la palla ad Alessio al prossimo episodio.Però almeno un'introduzione rapida su che cos'è il Mocking e perché usa appunto la metà programmazione per funzionare.Ma allora, diciamo sostanzialmente se prendiamo proprio il caso più base, quello più profano, immaginate di avere un'interfaccia, un'interfaccia che ha determinati metodi e se state facendo le cose fatte per bene, state facendo qualche tipo di dependency injection, che può essere con un framework o con un IOC container o semplicemente stare passando una dipendenza come parametro al costruttore della vostra classe, alla vostra funzione, a qualunque cosa.Ebbene, voi nei vostri test vi potete ritrovare un'implementazione concreta fatta ad hoc per quel test, magari anche con dei metodi che vi permettono insomma di fare dei test anche per vedere quella funzione con quali parametri è stata chiamata, diciamo avere delle funzioni accessorie, ma senza aver mai scritto una riga di codice per l'implementazione effettiva di quell'interfaccia.L'ho spiegata molto molto alla buona, ma è sicuramente qualcosa con cui abbiamo lavorato tutti, prima o prima o poi, insomma, anche semplicemente comunque i test play, solder, che qualche framework va e che magari non non implementeremo mai, insomma.Sì, in realtà, proprio parlando di mocking, mi hai accompagnato verso un'altra etichettina che ho trovato nella via per la scoperta del concetto di metà programmazione, che è questa parola che può ricordare a qualcuno qualche rito in realtà è una cosa molto rappresenta una cosa molto semplice ve la metto così io credo che di essere il peggior programmatore sulla faccia della terra e il mio codice per il 90 per cento dei casi molto accoppiato adesso sto estremizzando no? giusto per avere un contesto diciamo che sia accoppiato ma qualche volta mi ricordo anche di disaccoppiare Alle volte utilizziamo all'interno del nostro codice, dei nostri blocchi di codice, dei costrutti nativi del linguaggio che quando però dobbiamo andare a testare abbiamo bisogno che questi non entrino in gioco.Immaginate la creazione di un file, la scrittura di un file.Noi vogliamo un meccanismo tale per cui in fase di testing la funzione che va a generare un file non lo vado a fare.Questa è un'esigenza comune riconosciuta ed è proprio l'atto in cui noi andiamo a modificare i comportamenti base del linguaggio per esempio a modificare la funzione che ci permette di scrivere un file che facciamo appunto un atto di intercession.In javascript ve ne dico vi dico due funzionalità che ci permettono di farlo.Il metodo define property su un oggetto ci permette di definire una proprietà e di dire se è scrivibile o non scrivibile.Insomma ragazzi ci stiamo comportando da linguaggio in quel caso stiamo proprio agendo a livello di linguaggio.Oppure l'object freeze anche questa è un metodo in javascript che ci permette appunto di fare questo tipo d'azione e poi vi cito anche la proxy class che è diciamo una trovata fighissima in javascript non c'è da moltissimo perché è stata introdotta con l'ecma script 6 se ricordo bene e ci permette appunto di andare a fare l'override, quindi andare a sovrascrivere alcuni comportamenti, praticamente quasi tutti, di un oggetto.E questa è appunto intercezione ed è un tipo di azione che si utilizza spesso quando si fa mocking, no? L'ultimo che ho citato l'ho utilizzato di recente in una prova che ho fatto, per esempio, volevo scimmiottare Vue, per esempio, e cosa dovevo fare? Dovevo mettermi in mezzo tra le funzioni native del Ray, quindi il Ray Push, il Ray Pop, il shift e quant'altro, quindi li dovevo intercettare per non far scattare quello nativo, ma far fare le mie cose.Questo per appunto associare un array a una lista della document model, della DOM, e quindi quando su quell'array venivano aggiunti o tolti degli elementi, un push il pop non doveva scattare quello nativo e basta, ma dovevo dovevo proxarlo sul mio oggetto che tra le varie cose che faceva andava a manipolare la dom.Penso sia anche lo stesso, in soldoni la stessa cosa che fanno i vari framework e le varie librerie che fanno la stessa cosa.Però è figo.Cavolo, quando lo fai e dici "Caspita, sto bypassando JavaScript, lo sto rifacendo".Comando io! Il JavaScript è bellissimo da questo punto di vista, almeno dalla mia esperienza, perché proprio puoi fare quello che vuoi.Si fa violentare in tutti i modi.Sì, sì, è bellissimo, è come una pros...ok.No, e quindi niente, ero molto soddisfatto di questa prova che avevo fatta, l'avevo anche rilasciata, ma come esercizio nulla che sia da poter mettere in produzione, sia mai, però era carino.E come mio solito ho trovato un nome stupendo per questa, che era...siccome l'avevo fatta sulla falsariga di "View" l'ho chiamata "Han Baby"."Han Baby che bersito! Cioè ci hanno mai cliccato sopra?" Perché mi sembrava giusto.Niente, questo lo volevo dire così perché pareva brutto che stava lì da sola.No, mettiamo nelle note dell'episodio, allora.No, no, per carità, grazie.È solo teoria, si fa solo per parlare.No, no, cioè, alla fine Sono cose che come stiamo...ora ne stiamo parlando e siamo tutti comunque affascinati da questa cosa qui.Alla fine poi ci sono tante scuole di pensiero, no? C'è chi magari pensa che queste cose non debbano essere utilizzate per un motivo o per un altro.c'è chi ne abusa follemente per fare insomma delle cose brutte, anche io sono stato uno di quelli, però alla fine sono degli strumenti, lo stiamo ripetendo tante volte, e come tutti gli strumenti alla fine credo che davvero solo l'esperienza ti può insegnare quando utilizzarlo e quando non utilizzarlo.secondo me escluderli a prescindere è un peccato, perché veramente secondo me ci si tiene fuori da un mondo che è bellissimo e che soprattutto ci si porta fuori da tutta una parte di programmazione che comunque esiste e comprenderla ci può aiutare tanto, anche se non lo siamo direttamente.Nel momento in cui incontrate quel bug strano, quelle eggigride strane nel vostro ORM preferito, non voglio dire che andate sul repository dell'ORM e fate una vostra pull request, ma avete gli strumenti per capire quello che sta succedendo e magari potete intervenire.secondo me è qualcosa che dovrebbe essere approfondita da tutti e qui super bold opinion specialmente dalle persone junior o che si approcciano per la prima volta ad un linguaggio di programmazione che supporta questo tipo di programmazione per capire veramente come funzionano le cose.Non è una parte imprescindibile per poter capire quello che succede dietro le quinte, specialmente in JavaScript, dove magari c'è tanta complessità che ci viene astratta dal bundler di turno o dal framework di turno.Riuscire a capire quello che succede può essere una cosa che comunque in dei casi più avanzati, più nasti, più pelosi, potrei chiamarli come preferite, possono sicuramente tornare utili.A questo punto mi sento di chiedervi, secondo voi quando ha senso usare la metà programmazione e quando non ha senso? Bella domanda, ti ringrazio per averla posta.Allora, sicuramente ha senso se stai facendo una libreria o un framework, se è il tuo caso, che puoi documentare, come abbiamo ricordato subito all'inizio.In quel caso puoi usare tutte le potenzialità che il linguaggio ti mette a disposizione, e forse anche di più, e fare in modo di semplificare la vita e il lavoro ai programmatori che useranno la tua libreria.A quello serve la metaprogrammazione.A patto, lo ripeto, non mi sembra di averlo detto che sia documentato, che sia documentata bene.E inoltre è essenziale, secondo me, tu sia nel ruolo esatto per poter decidere una cosa del genere.Come detto, la programmazione, secondo me, è una soluzione a un problema.Una soluzione può essere un'opinione, perché il problema può avere differenti soluzioni.Quindi, quella che tu stai facendo è una tua opinione.Questa opinione se la dovranno comunque, sarà ereditata da chi verrà dopo o dai tuoi colleghi, quindi tu devi essere nella posizione di poter fare una scelta del genere.Non sempre lo sei, magari può essere il tuo responsabile, può essere il capo progetto, può essere il tuo capo, bisogna stare attenti anche al livello di dominio da questo punto di vista.Un accenno sulle performance, forse in quel caso per diversi meccanismi fare determinate cose a per runtime potrebbe non essere ottimale per le performance e quindi in quel caso potrebbe essere da evitare se quello che stai facendo debba essere usato, dovrà essere usato da qualcuno che tiene particolarmente alle performance, per esempio come me.Ed è per questo anche che comunque ringrazio anche Carmine, volevo dirlo anche prima, ha dato il consiglio che avrei voluto sentire io dieci anni fa su questa cosa, e che io quindi lo rinnovo, perché anche io ero uno di quelli che si spaventava di queste cose esoteriche, non tanto per il - esoteriche, scusate - non tanto per la comprensione del linguaggio, perché quello, anzi sono sempre andato molto a fondo nel linguaggio, proprio per una questione di formamenti.Io che magari ci sono tanti programmatori, forse sono come me o erano come me, e hanno bisogno di questi consigli, di abbracciare questi meccanismi che all'inizio possono spaventare, però se qualcuno li usa, forse, forse, non è detto, non è una regola, qualche problema lo risolve e forse può risolvere anche il tuo.Sono totalmente d'accordo, se dovessi dare proprio una risposta secca quando usare la metà programmazione, alla fine la metà programmazione si usa diciamo più, secondo me il corretto uso della metà programmazione c'è per aggirare e quindi diciamo per andare incontro alla verbosità e alla complessità.Se hai qualcosa che è molto verboso, vai di metà programmazione.Se hai qualcosa che ovviamente sia verboso, che sia ripetitivo, non ha senso se devi scrivere una volta sola che fai un accrocchio e potrai ciò scrivere dentro, ma se hai delle parti del tuo codice, della tua business logic, che sono per loro una natura, per il linguaggio, per qualunque motivo, sono molto verbose e possono essere scritte in una maniera che è più complessa, ma più concisa sul lungo termine della metàprogrammazione, vai.Se invece usi la metàprogrammazione per gestire la complessità, lì è un po' più spinoso come tema, perché ovviamente chi è che ti dà il trade-off migliore tra la complessità di quello che stai scrivendo e la complessità di trovare una soluzione con la complessità aggiunta della metà programmazione.Chi è che ti dice se lo stai facendo bene, te lo dice sostanzialmente l'esperienza, perché magari ci hai sbattuto la testa tante volte e spesso arrivi al punto in cui ha senso o non ha senso farlo.Una cosa per cui io uso e uso tanto la metaformazione in generale è per automatizzare tutto ciò che è verboso ed error prone.Ed error prone.lo scrivo una sola volta, lo commento, lo documento e lo testo.Ovviamente non è mai infallibile perché nulla è infallibile, ma io ho isolato qualcosa che può essere complesso o poi non complesso, ma ho isolato qualche cosa che è ripetitivo e che è error prone perché ogni volta bisogna riscrivere, fai copia e incolla qua di là, L'ho automatizzato e magari sono uscito a renderlo anche più esplicito magari con un DSL o comunque con qualche cosa che può semplicitarmi la vita.Non utilizzarlo come strumento per aggirare un problema, perché quando hai un problema ed è diverso da avere un dominio complesso.Magari hai un problema o magari sei semplicemente figo di non usare la metà programmazione per aggiare questa cosa perché tanto non è oggi, non è domani, non è dopo domani, è qualche cosa che esce sicuramente fuori ed esce ancora più cattiva e più dura di prima.Questo è semplicemente il consiglio che mi sento di dare.Io invece vi posso dire tutti i modi in cui non dovete usarla, perché sono tutti i modi in cui l'ho usata io.Scherzo! No, quello che ha detto Carmine è molto interessante, tra l'altro mi ha riportato alla mente un ragionamento, no? Che è questo.Se noi siamo portati ad utilizzare delle astrazioni che esulano dal nostro dominio, ancora prima di utilizzarle dobbiamo fare un passo indietro e provare a capire bene il nostro dominio.Forse quella cosa che noi stiamo provando ad astrarre, riusciamo a risolverla in modo più semplice capendo e dedicando un po' più tempo alla comprensione del dominio.Questa era una frase che diceva in quel libro "Philosophy of Software Design" qualcosa del già adesso non ricordo il titolo.Lo stesso libro che ha Luca dietro che si travede nel secondo scaffale, che tra l'altro ma anche io, bellissimo, esatto.Esatto, proprio là l'ho letta e secondo me ci casca a fagiolo in questo momento.Vi posso dire quando ho usato la metà programmazione e non me ne sono pentito.Intanto l'ho usata in situazioni dove il time constraint era molto stringente cioè devo fare qualcosa rapida riproducibile evitare ripetizioni e farli in modo molto molto veloce quindi quello è un caso un secondo caso può essere in questo caso non l'ho mai utilizzata così però secondo me può essere un caso intelligente quella di fissare al volo una dipendenza di terze parti sulla quale non abbiamo controllo anche se là poi i rischi ci sono perché basta che l'autore di quella libreria fa un update e noi spacchiamo tutto quindi dobbiamo stare molto attenti vuol dire che dobbiamo avere 16 ore e 12 occhi puntati su quella libreria aspettando che qualcosa cambi.Io l'ho utilizzato spesso in tutti i layer che coinvolgevano l'ambito platform.Quindi dalle assertion o il testing, dalla serializzazione per esempio, alla persistenza, non l'ho mai utilizzato se non a parte quel caso specifico con l'autorizzazione in ambiti di dominio.E mi è sempre stato comodo per disacopiare quei comportamenti che si ripetevano spesso e proprio avevo bisogno di strappare dalla logica di dominio, di separare in modo in modo...in modo forte.Però un po' a me la metà programmazione ha ricordato i pattern, no? Cioè c'è un momento in cui li incontriamo, no? Li conosciamo.Non ci capiamo una cippa e sfido chiunque, quando apre il libro della Gang of Four, provare a capirci qualcosa la prima volta.No, non ci capiamo niente, chiudiamo il libro e lo mettiamo da parte.Poi riprendiamo il libro e lo studiamo con dedizione, magari un po' più di calma e iniziamo a capirci, no? E iniziamo anche a padroneggiarli ed è là che scopria il casino.Perché quando iniziamo a padroneggiarli li utilizziamo dappertutti, di appertutto.Sia questa cosa vale con i pattern e vale con la metà programmazione.Li utilizziamo...beh, io li ho utilizzati anche per rimorchiare mia moglie.quindi credo che penso di essere la persona che ha messo i pattern dappertutto non l'ho fatto con la metà programmazione però credo che possa essere qualcosa di simile.Quando arriviamo a questo punto ne abusiamo perché pensiamo che siano davvero il nostro proiettile d'argento per poi eliminarli dalla nostra vita e ritornare a una vita un po' francescana pulita e libera da queste diavolerie.In realtà sono strumenti, lo strumento di per sé non è un male o un bene.Un male o un bene lo decidiamo noi quando quando lo usiamo, quindi credo che la consapevolezza sia alla base proprio di un uso buono o meno buono di questo tipo di strumenti.Detto questo noi siamo arrivati al nostro momento topico, il momento topico e tipico del nostro podcast, che sono...che sono il Paese dei Balocchi.Ragazzi sono...sono bollito, credetemi.Ho appena sentito un pianto e ho il terrore adesso di uscire da questa stanza, perché fuori c'è la realtà.Voglio continuare a parlare di metà programmazione.No, il Paese dei Balocchi."E conduco nel paese dei balocchi" "Ah, il paese dei balocchi" Allora, io riciclo un balocco che in realtà non sapevo che era un balocco, mi scuso se l'ho già detto, però questo ci cade veramente a fagiolo.Il libro "Meta Programming Ruby", che è un libro bellissimo, che vi guida alla scoperta non tanto, ovviamente anche di ciò che fa Ruby in tutto l'ambito della metà programmazione, delle grandi possibilità che vi offre, ma secondo me vi porta anche, diciamo, a pensare in una maniera, diciamo, un po' più laterale ai problemi.E' una cosa che a me ha aiutato tantissimo.Lo potete trovare su Amazon, insomma, o dove vi pare e l'autore è Paolo Perrotta.E vi sento di consigliare ancora una volta Racket.Che cos'è Racket? Racket è, ve la butto così, super semplice, super clickbait, ma nemmeno tanto, è un linguaggio per creare linguaggi.E mi fermo qui.lo affermo qui, lo trovate comunque nelle note dell'EPI Sodio.Se leggete il libro comunque diciamo approfondite un po'
