Scalabilità a terabyte per Supply Chains

00:00:06 Sfide nell’elaborazione dei dati della supply chain e la scalabilità a terabyte di Lokad.
00:00:38 Miglioramenti nella capacità di elaborazione di Lokad nell’ultimo anno.
00:01:33 Spiegazione della piattaforma di Lokad e del loro linguaggio di scripting Envision.
00:03:55 Confronto tra Envision e altri linguaggi di programmazione come Python.
00:06:27 Intuizioni chiave e scoperte che hanno portato ai miglioramenti di Lokad.
00:08:00 Archiviazione tabellare vs. colonnare nei database e la loro efficienza.
00:10:36 Sfide e costi associati all’elaborazione di grandi quantità di dati.
00:12:04 L’impatto dell’elaborazione a terabyte sui Supply Chain Scientist e sull’efficienza del lavoro.
00:14:10 Benefici concreti di un’elaborazione più rapida e della gestione di set di dati più grandi.
00:15:30 L’importanza di eliminare i casi limite e il pericolo di processi lunghi nelle iniziative quantitative di supply chain.
00:17:43 L’importanza di un approccio iterativo per gestire le contingenze del mondo reale.
00:20:47 Sfide e implicazioni dell’elaborazione di dati su larga scala nell’ottimizzazione di supply chain.
00:21:10 L’impatto della scalabilità a terabyte sulla visione di Lokad e sul futuro dell’ottimizzazione di supply chain.
00:24:41 Considerazioni finali e possibili vie per migliorare l’ottimizzazione di supply chain.

Riassunto

Kieran Chandler intervista Joannes Vermorel, fondatore di Lokad, riguardo supply chain optimization e la gestione di vasti set di dati. Lokad ha aumentato la sua capacità di elaborazione di 20 volte dal 2017, utilizzando il loro linguaggio specifico di dominio, Envision, per l’elaborazione di dati su larga scala. Envision semplifica il calcolo distribuito nel contesto della supply chain rispetto ai linguaggi di programmazione generici. I progressi di Lokad hanno ridotto i tempi di elaborazione dei dati da ore a minuti, permettendo ai Supply Chain Scientist di lavorare in modo più efficiente. Vermorel sottolinea l’importanza dell’agilità e dell’ottimizzazione iterativa per il successo delle iniziative di supply chain. La scalabilità a terabyte di Lokad consente un approccio più olistico all’ottimizzazione e prevede di migliorare l’espressività degli script Envision per affrontare meglio le situazioni reali di supply chain.

Sintesi Estesa

In questa intervista, Kieran Chandler, il conduttore, discute con Joannes Vermorel, il fondatore di Lokad, una società software specializzata in supply chain optimization. Parlano delle sfide della gestione di enormi quantità di dati nell’industria della supply chain e degli sviluppi di Lokad nella scalabilità a terabyte.

Joannes menziona che il 2018 è stato un anno di scalabilità per Lokad, con l’azienda che ha aumentato la sua capacità di elaborazione di un fattore 20 rispetto all’anno precedente. Questo miglioramento ha permesso a Lokad di gestire set di dati multi-terabyte con relativa facilità, considerando lo stato attuale della tecnologia.

L’azienda ha raggiunto questo obiettivo sviluppando la piattaforma Solocat, progettata per l’ottimizzazione quantitative supply chain. La piattaforma utilizza il linguaggio di scripting specifico di dominio di Lokad, chiamato Envision. Envision è progettato per rispondere alle necessità specifiche dei problemi di supply chain e facilitare l’elaborazione di dati su larga scala.

Prima del 2018, un singolo script Envision poteva essere eseguito solo su una macchina, anche se la piattaforma poteva contenere diversi terabyte di dati. L’azienda aveva implementato un certo livello di scalabilità distribuendo i calcoli di machine learning su più macchine. Tuttavia, compiti come l’ordinamento dei dati erano comunque limitati a una singola grande macchina.

Nel 2018, Lokad ha lanciato un’architettura completamente aggiornata per la logica di esecuzione backend degli script Envision. La nuova architettura consente la parallelizzazione automatica su più CPU e persino su intere flotte di macchine. Di conseguenza, compiti come l’ordinamento dei dati possono ora essere eseguiti molto più rapidamente sfruttando la potenza di elaborazione di dozzine di macchine.

Quando si confronta Envision con linguaggi di programmazione generici come Python, Java, C++ e C#, Joannes spiega che Envision è un linguaggio specifico di dominio, studiato per affrontare i problemi della supply chain. Mentre i linguaggi generici offrono la possibilità di fare quasi tutto, spesso richiedono configurazioni più complesse e una comprensione più approfondita di librerie e framework specifici per ottenere il calcolo distribuito.

Envision, invece, semplifica queste tecnicalità, rendendo più facile gestire il calcolo distribuito e l’elaborazione di dati su larga scala nel contesto dell’ottimizzazione di supply chain. Questo approccio specializzato permette a Lokad di migliorare la scalabilità e di gestire i terabyte di dati in modo più efficace rispetto all’utilizzo di linguaggi di programmazione generici.

Discutono del software dell’azienda, Envision, dei suoi benefici e di come i recenti progressi abbiano migliorato l’analisi di supply chain.

Envision è un linguaggio di scripting progettato specificamente per i problemi di supply chain, rendendolo più facile ed efficiente da usare rispetto ad altri linguaggi di programmazione di uso generale. Sacrifica un po’ di espressività per la semplicità, ma dato che si concentra su un tipo specifico di problema, questo compromesso è accettabile. Vermorel paragona la facilità d’uso di Envision alla scrittura di fogli Excel avanzati con medie sofisticate, ordinamenti e ricerche complesse.

Un anno fa, Lokad aveva già implementato un approccio colonnare per l’archiviazione dei dati per l’analisi dei big data, che è più adatto all’analisi batch piuttosto che all’elaborazione in tempo reale. Questo approccio memorizza i dati per colonna, anziché per riga, permettendo un’elaborazione più efficiente delle operazioni che toccano solo alcune colonne. Tuttavia, lo svantaggio è che l’aggiunta di nuove righe richiede di lavorare con ogni singola colonna, rendendolo meno efficiente per l’elaborazione in tempo reale.

Discutendo dei costi associati all’elaborazione di grandi quantità di dati, Vermorel sottolinea che la risorsa più costosa è il Supply Chain Scientist (o data scientist), poiché sono scarsi, richiedono conoscenze specifiche e necessitano di un’ampia formazione. Di conseguenza, Lokad punta a ottimizzare l’uso del tempo di questi scientist riducendo il tempo impiegato nell’elaborazione dei dati.

In precedenza, l’elaborazione di terabyte di dati richiedeva ore, ma i recenti progressi hanno ridotto quel tempo a minuti. Ciò permette ai Supply Chain Scientist di rimanere concentrati sui loro compiti e di passare più rapidamente alla fase successiva, invece di attendere i risultati. Tuttavia, significa anche che hanno meno opportunità di fare pause.

Il progresso nell’elaborazione più rapida di set di dati più grandi porta numerosi benefici concreti. Permette alle aziende di analizzare e ottimizzare le loro supply chains in modo più efficiente ed efficace, migliorando in ultima analisi le loro operazioni complessive.

Affrontano le sfide per raggiungere l’ottimizzazione, l’importanza dell’agilità e l’approccio iterativo necessario per gestire le contingenze del mondo reale.

Vermorel identifica il pericolo principale nell’implementare un’iniziativa quantitative supply chain come il tempo necessario per perfezionare il sistema, poiché è fondamentale gestire tutti i casi limite per evitare interventi manuali. Più ci mette, maggiori sono le probabilità che il progetto subisca interruzioni, come aggiornamenti IT o ERP, o trasformazioni aziendali drammatiche, che possono rendere obsoleti i lavori precedenti.

Per avere successo, le iniziative di ottimizzazione di supply chain devono essere messe in produzione rapidamente, il che richiede agilità. Vermorel spiega che, sebbene possa sembrare molto da realizzare in pochi mesi, impiegare troppo tempo comporta il rischio di fallimento del progetto. Sottolinea l’approccio iterativo all’ottimizzazione, necessario a causa della natura imprevedibile delle supply chain e delle contingenze del mondo reale che possono far deragliare numerical recipes.

L’ottimizzazione iterativa è essenziale per gestire l’infinita serie di sorprese che accompagna la gestione di supply chain. Vermorel spiega che le supply chain sono complesse, coinvolgendo molteplici mercati, paesi, fornitori e linee di prodotto. È impossibile fare brainstorming e elencare tutte le potenziali sfide tecniche in anticipo, quindi l’agilità è fondamentale quando si risolvono numerical recipes.

Kieran poi chiede a Vermorel l’impatto della scalabilità a terabyte su Lokad e la sua visione futura. Vermorel afferma che l’azienda ha realizzato enormi miglioramenti nella scalabilità dell’elaborazione, che aprono nuove opportunità per l’ottimizzazione di supply chain. Sottolinea che la scalabilità non riguarda solo la gestione di aziende più grandi, ma anche il raggiungimento di un’ottimizzazione a livello di rete.

Vermorel sottolinea che una vera ottimizzazione richiede di considerare l’intera rete come un’unica entità, invece di ottimizzare ogni negozio o fornitore isolatamente. La scalabilità a terabyte permette a Lokad di affrontare l’ottimizzazione in modo più olistico, contribuendo così a evitare che i problemi vengano spostati lungo la supply chain.

In futuro, Lokad prevede di utilizzare i suoi progressi in termini di scalabilità per migliorare l’espressività, permettendo modi più fluidi e diretti per riflettere situazioni complesse del mondo reale nei loro script Envision. Ciò renderà più semplice sviluppare numerical recipes che affrontino in modo efficace le situazioni di supply chain del mondo reale.

L’intervista si conclude con Vermorel che sottolinea l’importanza dell’agilità, dell’ottimizzazione iterativa e di approcci olistici alla gestione di supply chain.

Trascrizione Completa

Kieran Chandler: Oggi su Lokad TV, andremo a comprendere la straordinaria quantità di dati gestita all’interno di una supply chain e discuteremo anche di come Lokad abbia sviluppato la scalabilità a terabyte per affrontare tale situazione. Quindi, Joannes, oggi parleremo un po’ della ricerca e sviluppo condotta da Lokad nell’ultimo anno. Su cosa avete lavorato nel 2018?

Joannes Vermorel: Il 2018 è stato per noi l’anno della scalabilità. Abbiamo lavorato quasi ininterrottamente per un anno per aumentare la scalabilità. Rispetto a gennaio dell’anno scorso, abbiamo aumentato la nostra capacità di elaborazione di circa un fattore 20, il che ci permette di gestire set di dati multi-terabyte con relativa facilità. Non esiste un’elaborazione a terabyte facile, considerando la tecnologia attuale, ma può comunque essere resa relativamente semplice.

Kieran Chandler: Un fattore 20 suona come un miglioramento incredibilmente grande. Quali passaggi avete dovuto compiere per raggiungere questo miglioramento?

Joannes Vermorel: Lokad è una piattaforma progettata per l’ottimizzazione di supply chain. Tecnicamente, è accessibile tramite script scritti nel nostro linguaggio di scripting fatto in casa chiamato Envision. Questo linguaggio è progettato non solo per rispondere specificamente alle esigenze dell’ottimizzazione di supply chain, ma anche per facilitare l’elaborazione su larga scala. Fino allo scorso anno, un singolo account di uno dei nostri clienti poteva contenere diversi terabyte di dati, ma un singolo script o pezzo di codice veniva eseguito su una sola macchina. Avevamo già implementato lo scale-out, ovvero l’idea di distribuire il calcolo su molte macchine per componenti specifici come il machine learning. Tuttavia, in generale, quando si ordinavano semplicemente i dati, ciò avveniva su una grande macchina. Nel 2018, abbiamo lanciato un’architettura completamente aggiornata per la logica di esecuzione backend degli script Envision. Oggi, infatti, si ha una parallelizzazione automatica non solo su più processori e CPU, ma anche su un’intera flotta di macchine. Ciò significa che un singolo script che esegue un’operazione semplice, come ordinare i dati per data, prodotto, negozio o prezzo, può essere eseguito su una flotta di dozzine di macchine, rendendolo molto più veloce.

Kieran Chandler: Parliamo un po’ di Envision. In che modo Envision contribuisce a questi miglioramenti e a migliorare la scalabilità rispetto all’utilizzo di altri linguaggi di programmazione come Python o simili?

Joannes Vermorel: Envision è un linguaggio di programmazione specifico di dominio, mentre Python, Java, C++ e C# sono linguaggi di programmazione generici. Con un linguaggio generico, hai la possibilità di fare praticamente qualsiasi cosa, ma il prezzo da pagare è che emergono classi di tecnicismi nell’ambiente di programmazione. Ad esempio, con Python puoi fare calcolo distribuito, ma devi scrivere il codice in modo da sfruttare specifiche librerie e framework affinché quei calcoli vengano eseguiti su una flotta di macchine. Inoltre, dovrai configurare tu stesso un cluster di macchine affinché possa eseguire questa logica distribuita. Se hai diversi programmi concorrenti che vengono eseguiti sullo stesso cluster perché hai script o utenti differenti, diventa più complesso. Diverse esigenze… Insomma, dobbiamo avere tutta l’infrastruttura in atto per condividere le risorse, sai, la banda, i dischi, le CPU e così via. E tutto ciò è esattamente ciò che Envision fa in modo completamente integrato per te. Quindi, quello che perdi è molta espressività, il che va bene perché, ancora, Envision può cavarsela. Non è rotto, nonostante abbia perso molta espressività, perché siamo specializzati in un tipo specifico di problema, cioè i problemi di supply chain. Quindi non cerchiamo di risolvere ogni singolo problema. Non cerchiamo di scrivere un motore per giocare a scacchi o per fare modellazione 3D. È molto focalizzato su tipi specifici di problemi.

Kieran Chandler: Quindi, se ho capito bene, stai dicendo che è molto più semplice usare Envision piuttosto che un altro tipo di linguaggio di programmazione?

Joannes Vermorel: Esattamente. Voglio dire, scrivere uno script che processa tabelle contenenti diverse miliardi di righe per eseguire il tipo di analisi che ci si aspetterebbe in un contesto di supply chain, come stimare il costo e l’impatto delle stockouts in una vasta rete negli ultimi tre anni, è qualcosa che potresti fare con letteralmente una dozzina di righe di codice. Ma codice che è facile da scrivere. Quando dico facile da scrivere, intendo che non è mai così semplice scrivere codice, ma non è più difficile che, diciamo, scrivere un foglio Excel avanzato che esegue medie sofisticate, ordinamenti e ricerche complesse sui dati.

Kieran Chandler: Ok, e quali sono stati alcuni degli spunti chiave e delle scoperte che hanno portato a questi miglioramenti?

Joannes Vermorel: Solo per capire da dove partivamo, un anno fa, Lokad aveva già molti ingredienti big data in essere. Uno di questi era avere un approccio colonnare all’archiviazione dei dati. Quindi, in breve, i database SQL tradizionali adottano un’archiviazione tabellare. Ciò significa che quando hai una tabella, stai memorizzando righe di dati, e se hai una riga, essa è memorizzata insieme, e quella è la tua unità. Fondamentalmente, questo rende i database tabellari molto efficienti nell’effettuare piccoli aggiornamenti o operazioni di lettura/scrittura riga per riga.

Al contrario, nel corso degli ultimi decenni, ogni volta che vuoi fare una grande analisi dei dati, è stato sviluppato un approccio colonnare. Fondamentalmente, quando hai una tabella, ad esempio una tabella con 20 colonne, memorizzerai i dati raggruppati per colonna. Cosa significa questo? Significa che quando esegui un’operazione, come per esempio, “Ho il prezzo per unità, e ho la quantità. Supponiamo di avere una tabella che rappresenta la storico delle vendite. Ora vuoi conoscere l’importo totale delle vendite, quindi cosa devi fare? Devi moltiplicare il prezzo per la quantità e sommare tutto quello presente nella tabella.” Beh, si scopre che la tua tabella potrebbe avere 20 colonne, ma l’operazione appena descritta tocca solo due colonne. Quindi, se usi un’archiviazione colonnare, il principale vantaggio è che ogni operazione che tocca solo poche colonne, quelle poche colonne verranno elaborate, mentre il resto può essere semplicemente ignorato. Se utilizzi un formato tabellare, invece, le altre colonne rimangono completamente al loro posto, e non puoi semplicemente saltarle.

Ma lo svantaggio potrebbe essere che se stai aggiungendo righe aggiuntive, se lavori in tempo reale, se utilizzi un approccio colonnare, se aggiungi una riga, dovrai operare su ogni singola colonna.

Kieran Chandler: Quindi, quando aggiungi una riga, devi toccare 20 colonne, rendendo l’operazione relativamente inefficiente. L’archiviazione colonnare è più adatta per analisi batch, non esattamente in tempo reale, ma più del tipo di analisi a cui sei interessato per la supply chain. Può essere aggiornato ogni minuto, ma non ogni millisecondo. Parliamo un po’ dei costi associati alla potenza di calcolo e alla gestione di grandi quantità di dati. In che modo l’implementazione della scalabilità in terabyte ha influenzato i costi legati al lavoro con i dati?

Joannes Vermorel: In realtà, parecchio. Le risorse più costose quando si cerca di ottimizzare una supply chain su larga scala sono i Supply Chain Scientist. Queste persone non sono gratuite, ed è una sfida trovare e formare individui con il giusto talento. La risorsa scarsa non sono le CPU, i dischi o la larghezza di banda, che possono essere acquisiti a basso costo dalla tua piattaforma di cloud computing preferita, ma piuttosto le persone di talento con cui lavorare sul problema.

Quando entri nel campo dell’elaborazione in terabyte, tutto diventa lento. L’elaborazione di un terabyte di dati può richiedere parecchio tempo, specialmente se stai eseguendo calcoli non banali che coinvolgono calcoli probabilistici con variabili casuali. Questo poteva richiedere ore, ma ora ci vogliono minuti. Per i Supply Chain Scientist, ciò significa che possono rimanere concentrati sul compito, ottenere i risultati e passare alla cosa successiva invece di rimanere bloccati in attesa dei risultati. Quindi, se mai, sono cattive notizie per i nostri Supply Chain Scientist, perché avranno meno pause caffè.

Kieran Chandler: Cosa significa questa scoperta per il mondo reale? Ovviamente, siamo in grado di lavorare con dataset molto più grandi e farlo molto più rapidamente, ma ci sono altri benefici che stiamo osservando?

Joannes Vermorel: Sì, uno dei pericoli principali, o cause alla radice del fallimento delle iniziative quantitative per la supply chain, è il tempo necessario per farle funzionare correttamente, per farle lavorare e diventare completamente rifinite in modo da non lasciare casi limite irrisolti. Con la possibilità di elaborare dataset più grandi più velocemente, ora possiamo affrontare questi problemi in modo più efficiente, il che porta in definitiva a decisioni migliori nella supply chain.

Kieran Chandler: I vostri sistemi sono buoni, ma c’è ancora una persona che rimane completamente manuale. Questo richiede molta manodopera per esaminare manualmente tutti i casi limite che non sono gestiti correttamente. Ciò in qualche modo vanifica lo scopo di avere un’automazione avanzata basata su machine learning per l’ottimizzazione. Il pericolo è che il processo per eliminare tutti i casi limite, per affinare davvero la ricetta numerica che guida il processo decisionale, possa richiedere troppo tempo.

Joannes Vermorel: Sì, e quel ritardo è letale perché a un certo punto le persone perdono fiducia nel successo dell’iniziativa. Se sei lento, ci sono buone probabilità che l’IT venga interrotta nel mezzo. Ad esempio, se il tuo progetto dura due anni, c’è una possibilità su tre che nel mezzo venga effettuato un aggiornamento ERP. Inizi a ottimizzare la supply chain, e poi c’è un cambiamento massiccio nell’idea aziendale. Gran parte di ciò che hai fatto crolla semplicemente perché tutti i sistemi vengono cambiati.

Più a lungo aspetti, più le cose possono ostacolare il tuo progetto. L’azienda stessa può subire trasformazioni drammatiche che rendono il tuo lavoro precedente obsoleto alla luce dei nuovi cambiamenti aziendali. Ci sono molte forze trainanti che mettono pressione per portare il prodotto in produzione rapidamente. Se non riesci a ottenere successo entro pochi mesi, è probabile che la tua iniziativa fallisca. È qui che l’agilità è assolutamente necessaria.

Può sembrare molto, un paio di mesi, ma quando tocchi terabyte di dati e ci vogliono ore per ottenere un risultato, sostanzialmente stai modificando le tue ricette numeriche al massimo una o due volte al giorno. Le cose iniziano a rallentare notevolmente.

Kieran Chandler: Quindi, quello di cui stai parlando è una sorta di approccio iterativo per ottimizzare la supply chain. Perché esiste un approccio iterativo del genere? Perché non puoi semplicemente premere un pulsante, usare deep learning per apprendere e ottenere una buona previsione e buoni risultati?

Joannes Vermorel: La realtà ha un modo tutto suo di ostacolarti. La supply chain riguarda davvero la gestione delle contingenze del mondo reale. Ci sono così tanti casi limite che emergono semplicemente dal tessuto stesso della realtà. Ad esempio, inizi a calcolare una quantità ideale da ordinare, diciamo 80 unità. È la quantità migliore da ordinare, ma i pallet vengono forniti solo in 0 unità o 100 unità perché sono confezionati su un pallet. 80 non è un’opzione, quindi cosa fai?

Ci sono dozzine di situazioni come questa. Potresti pensare che il valore del tuo inventario decada gradualmente nel tempo, ma non è così. Perché? Perché c’è una shelf-life con una data specifica. Quando raggiungi il limite della shelf-life, il valore dell’inventario scende da un certo valore a zero o addirittura in negativo, perché ora devi pagare per smaltire questo stock senza valore.

La realtà è che le supply chain sono complesse. Se parliamo di aziende che operano in molti mercati, in diversi paesi, con molti fornitori e potenzialmente decine di linee di prodotti, ci sono molte complicazioni. È un’illusione pensare che ci si possa semplicemente sedere in una stanza e fare un brainstorming con il team su tutte le sfide tecniche che emergeranno lungo la strada con le iniziative. Non puoi semplicemente dire… Riunisciti con il tuo team di supply chain e elencate tutte le piccole cose che potrebbero far deragliare la ricetta numerica che genera le decisioni ottimizzate per la supply chain. La realtà, come sempre, ha il modo di sorprenderti perché scoprirai cose bizzarre, come ad esempio un certo paese che applica una tassa strana su qualcosa. Tornando alla tua domanda iniziale sull’approccio iterativo, l’unico modo per affrontare questo flusso infinito di sorprese è essere estremamente agili nel correggere la propria ricetta numerica quando ti trovi di fronte a qualcosa di inaspettato.

Kieran Chandler: Ora concentriamoci sulla scalabilità in terabyte e iniziamo a mettere insieme le cose. In che modo questo cambia le prospettive per Lokad, e cosa significa per il futuro?

Joannes Vermorel: Abbiamo fatto enormi miglioramenti in termini di scalabilità dell’elaborazione. Questo sviluppo apre molte porte che prima ci erano precluse. Non si tratta solo di gestire aziende più grandi, ci sono diversi modi per aggirare il problema, ad esempio. Considera una grande rete di vendita al dettaglio. Se il tuo approccio per ottimizzare una rete di vendita al dettaglio su larga scala consiste nell’elaborare ogni mercato in isolamento, e se hai, diciamo, 200 mercati, avresti bisogno solo di 200 macchine, una per ogni mercato, e ciò scalerebbe. Ma questo metodo non porterà il miglioramento della supply chain che cerchi, perché non stai ottimizzando a livello di rete. Stai ottimizzando localmente ogni negozio in isolamento, ignorando completamente ciò che accade nel resto della rete.

Kieran Chandler: Quindi queste 200 macchine non comunicherebbero tra loro?

Joannes Vermorel: Esatto. Se hai silos indipendenti, è molto facile scalare il tuo processo. Ma la sfida è quando inizi a considerare la tua rete come un’entità unica in cui tutto è connesso. Puoi effettivamente spedire inventario e materiali attraverso la rete praticamente in qualsiasi modo tu voglia. Anche se ci sono molti modi che non sono redditizi e non hanno senso, è possibile. E alcuni di questi modi sottili potrebbero essere ottime idee e molto profittevoli. Hai bisogno di un sistema che possa elaborare tutto contemporaneamente, in modo monolitico. Cosa significa questo per il futuro? Significa che apre molte strade per un’ottimizzazione migliore e olistica. La maledizione dell’ottimizzazione della supply chain è che non risolvi i problemi; li sposti semplicemente. Puoi guardare un’area e ottimizzarla, ma tutto ciò che fai è spostare il problema lungo la catena o indietro al fornitore. Un’altra via è che, ora che abbiamo guadagnato significativamente in scalabilità, probabilmente cercheremo di tornare all’espressività. Fondamentalmente, miriamo a esprimere in modo più diretto e fluido le situazioni complesse che si verificano nel mondo reale in quegli script Envision. In questo modo, è più facile fornire ricette numeriche che si adattano bene ad affrontare situazioni reali.

Kieran Chandler: Sembra fantastico. Dovremo concludere qui, ma grazie per il tuo tempo oggi. Questo è tutto per questa settimana. Grazie mille per averci seguito, e ci vediamo la prossima volta. Arrivederci.