Scalabilità terabyte per le supply chain

00:00:06 Sfide nel trattamento dei dati della supply chain e la scalabilità 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 Principali intuizioni e scoperte che hanno portato ai miglioramenti di Lokad.
00:08:00 Archiviazione tabellare vs archiviazione colonnare nei database e le loro efficienze.
00:10:36 Sfide e costi associati all’elaborazione di grandi quantità di dati.
00:12:04 L’impatto dell’elaborazione terabyte sugli scienziati della supply chain e sull’efficienza del lavoro.
00:14:10 Benefici concreti di un’elaborazione più veloce e della gestione di set di dati più grandi.
00:15:30 Importanza dell’eliminazione dei casi limite e del pericolo dei processi lunghi nelle iniziative quantitative della supply chain.
00:17:43 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 della supply chain.
00:21:10 L’impatto della scalabilità terabyte sulle prospettive di Lokad e sul futuro dell’ottimizzazione della supply chain.
00:24:41 Considerazioni finali e possibili strade per migliorare l’ottimizzazione della supply chain.

Riassunto

Kieran Chandler intervista Joannes Vermorel, fondatore di Lokad, sull’ottimizzazione della supply chain e sulla gestione di vasti set di dati. Lokad ha aumentato la sua capacità di elaborazione di 20 volte dal 2017, utilizzando il loro linguaggio specifico del 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, consentendo agli scienziati della supply chain di lavorare in modo più efficiente. Vermorel sottolinea l’importanza dell’agilità e dell’ottimizzazione iterativa per le iniziative di supply chain di successo. La scalabilità 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 della supply chain.

Riassunto Esteso

In questa intervista, Kieran Chandler, il conduttore, discute con Joannes Vermorel, il fondatore di Lokad, un’azienda software specializzata nell’ottimizzazione della supply chain. Parlano delle sfide nel gestire grandi quantità di dati nell’industria della supply chain e degli sviluppi di Lokad nella scalabilità 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 di 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 quantitativa della supply chain. La piattaforma utilizza il linguaggio di scripting specifico del dominio di Lokad chiamato Envision. Envision è progettato per affrontare le specifiche esigenze dei problemi della supply chain e facilitare l’elaborazione di dati su larga scala.

Prima del 2018, uno script Envision poteva essere eseguito solo su una singola 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, attività come l’ordinamento dei dati erano ancora limitate a una grande macchina.

Nel 2018, Lokad ha introdotto un’architettura completamente aggiornata per la logica di esecuzione del backend degli script Envision. La nuova architettura consente la parallelizzazione automatica su più CPU e persino su intere flotte di macchine. Di conseguenza, attività come l’ordinamento dei dati possono ora essere eseguite molto più velocemente utilizzando la potenza di elaborazione di decine di macchine.

Nel confrontare Envision con linguaggi di programmazione generici come Python, Java, C++ e C#, Joannes spiega che Envision è un linguaggio specifico del dominio progettato per gestire problemi della supply chain. Mentre i linguaggi di programmazione generici offrono la possibilità di fare praticamente tutto, spesso richiedono configurazioni più complesse e una comprensione più approfondita di librerie e framework specifici per ottenere l’elaborazione distribuita.

Envision, d’altra parte, semplifica queste questioni tecniche, rendendo più facile gestire l’elaborazione distribuita e i dati su larga scala nel contesto dell’ottimizzazione della supply chain. Questo approccio specializzato consente a Lokad di migliorare la scalabilità e gestire terabyte di dati in modo più efficace rispetto all’utilizzo di linguaggi di programmazione generici.

Discutono del software dell’azienda, Envision, dei suoi vantaggi e di come gli ultimi sviluppi abbiano migliorato l’analisi della supply chain.

Envision è un linguaggio di scripting appositamente progettato per problemi della supply chain, che lo rende più facile ed efficiente da usare rispetto ad altri linguaggi di programmazione generici. Sacrifica un po’ di espressività per semplicità, ma poiché si concentra su un tipo specifico di problema, questo compromesso è accettabile. Vermorel paragona la facilità di utilizzo di Envision alla scrittura di fogli Excel avanzati con medie, ordinamenti e ricerche sofisticate.

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

Nel discutere dei costi associati all’elaborazione di grandi quantità di dati, Vermorel sottolinea che la risorsa più costosa è lo scienziato della supply chain (o data scientist), in quanto sono scarsi, richiedono conoscenze specifiche e necessitano di una formazione approfondita. Di conseguenza, Lokad mira a ottimizzare l’utilizzo del tempo di questi scienziati riducendo il tempo dedicato all’elaborazione dei dati.

In passato, l’elaborazione di terabyte di dati richiedeva ore, ma gli ultimi sviluppi hanno ridotto quel tempo a pochi minuti. Ciò consente agli scienziati della supply chain di rimanere concentrati sulle loro attività e di passare più rapidamente alla fase successiva, anziché aspettare i risultati. Tuttavia, significa anche che hanno meno opportunità di fare pause.

Il progresso nell’elaborazione di set di dati più grandi in modo più rapido ha diversi vantaggi nel mondo reale. Consente alle aziende di analizzare e ottimizzare le loro supply chain in modo più efficiente ed efficace, migliorando in definitiva 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’implementazione di un’iniziativa quantitativa della supply chain nel tempo necessario per perfezionare il sistema, poiché è fondamentale gestire tutti i casi limite per evitare interventi manuali. Più tempo ci vuole, più probabile è che il progetto si trovi di fronte a disruption, come aggiornamenti IT o ERP o trasformazioni aziendali drastiche, che possono rendere obsoleto il lavoro precedente.

Per avere successo, le iniziative di ottimizzazione della supply chain devono essere messe in produzione rapidamente, il che richiede agilità. Vermorel spiega che, anche se potrebbe sembrare molto da realizzare in pochi mesi, impiegare troppo tempo comporta il rischio di fallimento del progetto. Egli sottolinea l’approccio iterativo all’ottimizzazione, che è necessario a causa della natura imprevedibile delle supply chain e delle contingenze del mondo reale che possono deviare ricette numeriche.

L’ottimizzazione iterativa è essenziale per gestire il flusso infinito di sorprese che accompagnano la gestione della supply chain. Vermorel spiega che le supply chain sono complesse, coinvolgono diversi mercati, paesi, fornitori e linee di prodotto. È impossibile prevedere e elencare tutte le possibili sfide tecniche in anticipo, quindi l’agilità è fondamentale quando si correggono le ricette numeriche.

Kieran chiede quindi a Vermorel quale sia l’impatto della scalabilità dei terabyte su Lokad e sul suo futuro. Vermorel afferma che l’azienda ha compiuto enormi progressi nella scalabilità dell’elaborazione, il che apre nuove opportunità per l’ottimizzazione della supply chain. Egli precisa che la scalabilità non riguarda solo il confronto con aziende più grandi, ma anche il raggiungimento dell’ottimizzazione a livello di rete.

Vermorel sottolinea che la vera ottimizzazione richiede di considerare l’intera rete come un’unica entità, anziché ottimizzare singoli negozi o fornitori in modo isolato. La scalabilità dei terabyte consente a Lokad di avvicinarsi all’ottimizzazione in modo più olistico, il che a sua volta aiuta a evitare che i problemi vengano spostati lungo la supply chain.

In futuro, Lokad intende utilizzare i suoi progressi nella scalabilità per migliorare l’espressività, consentendo modi più fluidi e diretti per riflettere situazioni complesse del mondo reale nei loro script Envision. Ciò faciliterà lo sviluppo di ricette numeriche che affrontano efficacemente situazioni reali della supply chain.

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

Trascrizione completa

Kieran Chandler: Oggi su Lokad TV, cercheremo di capire l’enorme quantità di dati gestiti all’interno di una supply chain e discuteremo anche di come Lokad abbia sviluppato la scalabilità dei terabyte per affrontare questa sfida. Quindi, Joannes, oggi parleremo un po’ della ricerca e sviluppo svolta da Lokad nell’ultimo anno. Su cosa hai lavorato nel 2018?

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

Kieran Chandler: Un fattore di 20 sembra un miglioramento incredibilmente grande. Quali passi hai dovuto compiere per raggiungere questo risultato?

Joannes Vermorel: Lokad è una piattaforma progettata per l’ottimizzazione della supply chain. Tecnicamente, è accessibile tramite script scritti nel nostro linguaggio di scripting fatto in casa chiamato Envision. Questo linguaggio è progettato non solo per affrontare specificamente le esigenze dell’ottimizzazione della supply chain, ma anche per facilitare l’elaborazione su larga scala. Fino all’anno scorso, un singolo account per uno dei nostri clienti poteva contenere diversi terabyte di dati, ma uno script o un pezzo di codice veniva eseguito su una singola macchina. Avevamo già implementato la scalabilità orizzontale, quindi l’idea che è possibile distribuire il calcolo su molte macchine per componenti specifici come il machine learning. Tuttavia, in generale, quando si ordinavano i dati, ciò avveniva su una singola macchina di grandi dimensioni. Nel 2018, abbiamo introdotto un’architettura completamente aggiornata per la logica di esecuzione del backend degli script Envision. Oggi, hai la parallelizzazione automatica non solo su più processori e CPU, ma anche su un insieme di macchine. Ciò significa che uno script singolo che esegue un’operazione semplice, come l’ordinamento dei dati per data, prodotto, negozio o prezzo, può avvenire su un insieme di dozzine di macchine, rendendolo molto più veloce.

Kieran Chandler: Parliamo un po’ di Envision. Come funziona Envision nel realizzare questi miglioramenti e migliorare la scalabilità rispetto al lavoro con altri linguaggi di programmazione come Python o qualcosa del genere?

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

Kieran Chandler: Ok, quindi quello che stai dicendo è che è molto più semplice utilizzare Envision piuttosto che un altro tipo di linguaggio di programmazione?

Joannes Vermorel: Esattamente. Voglio dire, scrivere uno script che elabora tabelle contenenti diversi 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 rotture di stock in una grande rete negli ultimi tre anni, è qualcosa che potresti fare con letteralmente una dozzina di righe di codice. Ma un codice che è facile da scrivere. Quando dico facile da scrivere, intendo che non è mai così facile scrivere codice, ma non è più difficile, diciamo, scrivere un foglio di calcolo avanzato di Excel che fa medie fantasiose, ordinamenti fantasiosi e ricerche fantasiose sui dati.

Kieran Chandler: Ok, e quali sono state alcune delle intuizioni chiave e delle scoperte che hanno portato a questi miglioramenti?

Joannes Vermorel: Solo per capire da dove siamo partiti, un anno fa, Lokad aveva già molti ingredienti di big data a disposizione. Uno di questi è avere un approccio colonnare allo storage dei dati. Quindi, in poche parole, i database SQL tradizionali adottano uno storage tabellare. Ciò significa che quando hai una tabella, stai memorizzando righe di dati e se hai una riga, essa si trova insieme ed è la tua unità. Quindi, in pratica, ciò rende i database tabellari molto efficienti nell’eseguire piccoli aggiornamenti o letture/scritture riga per riga.

Al contrario, negli ultimi decenni, quando si vuole fare analisi di grandi dimensioni, è stato sviluppato un approccio colonnare. Quindi, quando hai una tabella, diciamo che hai una tabella con 20 colonne, stai andando a memorizzare i dati impacchettati per colonna. Quindi, cosa significa? Significa che quando esegui un’operazione, ad esempio, “Ho il prezzo per unità e ho la quantità. Diciamo che hai una tabella che rappresenta la cronologia delle vendite. Ora vuoi conoscere l’importo totale delle vendite, quindi cosa devi fare? Devi moltiplicare il prezzo per la quantità e fare la somma di tutto ciò in tutta la tabella”. Beh, si scopre che la tua tabella potrebbe avere 20 colonne, ma l’operazione che ho appena descritto tocca solo due colonne. Quindi, se hai uno storage colonnare, il vantaggio principale è che ogni operazione che tocca solo poche colonne, quelle poche colonne verranno elaborate e il resto può essere semplicemente ignorato. Se hai un formato tabellare, beh, le altre colonne sono ancora completamente in mezzo e non puoi davvero saltarle.

Ma l’inconveniente potrebbe essere che se stai aggiungendo righe aggiuntive, se stai lavorando in tempo reale, se stai adottando un approccio colonnare, se stai aggiungendo una riga, devi lavorare con ogni singola colonna.

Kieran Chandler: Quindi, quando si aggiunge una riga, è necessario toccare 20 colonne, rendendolo relativamente inefficiente. Lo storage colonnare è più adatto per l’analisi batch, non esattamente in tempo reale, ma più il tipo di analisi che ti interessa per la supply chain. Può essere aggiornato ogni minuto, ma non ogni millisecondo. Parliamo un po’ dei costi associati alla potenza di elaborazione e al lavoro con grandi quantità di dati. Come ha influenzato i costi del lavoro con i dati l’implementazione della scalabilità dei terabyte?

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

Quando si entra nel campo dell’elaborazione dei terabyte, tutto è lento. Elaborare un terabyte di dati può richiedere parecchio tempo, soprattutto se si effettuano calcoli non banali che coinvolgono calcoli probabilistici con variabili casuali. Ciò potrebbe richiedere ore, ma ora richiede minuti. Per gli scienziati della supply chain, ciò significa che possono rimanere concentrati sul compito, ottenere i risultati e passare alla prossima cosa anziché rimanere bloccati in attesa dei risultati. Quindi, se vogliamo, è una brutta notizia per i nostri scienziati della supply chain perché avranno meno pause caffè.

Kieran Chandler: Cosa significa questa scoperta per il mondo reale? Ovviamente, siamo in grado di lavorare con set di dati molto più grandi e di lavorare con essi molto più velocemente, ma ci sono altri benefici che stiamo riscontrando?

Joannes Vermorel: Sì, uno dei pericoli chiave, o cause principali di fallimento delle iniziative quantitative della supply chain, è il tempo necessario per farle funzionare correttamente, per renderle operative e completamente perfezionate in modo da non avere casi limite persistenti. Con la capacità di elaborare set di dati più grandi più velocemente, ora possiamo affrontare questi problemi in modo più efficiente, il che porta in ultima analisi a decisioni migliori sulla supply chain.

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

Joannes Vermorel: Sì, e questo ritardo è letale perché ad un certo punto, le persone perdono fiducia nel successo dell’iniziativa. Se sei lento, c’è la possibilità che l’IT venga interrotto a metà. Ad esempio, se il tuo progetto richiede due anni, c’è una probabilità su tre che ci sarà un aggiornamento dell’ERP a metà. Inizi ad ottimizzare la supply chain e poi c’è un cambiamento massiccio nell’idea dell’azienda. Molto di ciò che hai fatto crolla solo perché tutti i sistemi vengono cambiati.

Più aspetti, più cose possono interrompere il tuo progetto. L’azienda stessa può subire una trasformazione drammatica che rende il tuo lavoro precedente obsoleto alla luce dei nuovi cambiamenti aziendali. Ci sono molte forze trainanti che mettono pressione per ottenere il prodotto in produzione rapidamente. Se non riesci a avere successo entro pochi mesi, c’è la possibilità che la tua iniziativa fallisca. Ed è qui che l’agilità è assolutamente necessaria.

Potrebbe sembrare molto, un paio di mesi, ma quando si lavora con terabyte di dati e ci vogliono ore per ottenere un risultato, si sta essenzialmente perfezionando le proprie ricette numeriche una o due volte al giorno al massimo. Le cose iniziano a diventare molto lente.

Kieran Chandler: Quindi, ciò su cui stai facendo riferimento è un tipo di approccio iterativo per ottimizzare la supply chain. Perché c’è un tale approccio iterativo? Perché non puoi semplicemente premere un pulsante, utilizzare il deep learning per imparare e ottenere una buona previsione e buoni risultati?

Joannes Vermorel: La realtà ha un modo per mettersi sulla tua strada. La supply chain riguarda davvero la gestione delle contingenze del mondo reale. Ci sono così tanti casi limite che emergono proprio dalla stessa realtà. Ad esempio, inizi a calcolare una quantità ideale da ordinare, diciamo 80 unità. È la migliore quantità da ordinare, ma i pallet arrivano solo in unità zero o 100 perché sono imballati su un pallet. 80 non è un’opzione, quindi cosa fai?

Ci sono decine di situazioni come questa. Potresti pensare che il valore del tuo inventario diminuisca gradualmente nel tempo, ma non è così. Perché? Perché c’è un ciclo di vita con una data specifica. Quando raggiungi il limite di shelf-life, il valore del tuo inventario scende da qualcosa a zero o addirittura negativo perché ora devi pagare per smaltire questa merce inutile.

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

Kieran Chandler: Ora concentriamoci sulla scalabilità dei terabyte e iniziamo a mettere insieme le cose. Come cambia questo le prospettive di Lokad e cosa significa per il futuro?

Joannes Vermorel: Abbiamo fatto enormi miglioramenti in termini di scalabilità del processo. Questo sviluppo apre molte opportunità che in precedenza ci erano inaccessibili. Non si tratta solo di gestire aziende più grandi, ci sono molte possibilità di imbrogliare, 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 è quello di elaborare ogni mercato in modo isolato e se hai, diciamo, 200 mercati, avresti bisogno solo di 200 macchine, una per mercato, e si scalerebbe. Ma questo metodo non porterà al miglioramento della supply chain che stai cercando perché non stai ottimizzando a livello di rete. Stai ottimizzando localmente ogni negozio in modo isolato, ignorando completamente ciò che sta accadendo nel resto della rete.

Kieran Chandler: Quindi queste 200 macchine non si comunicano tra loro?

Joannes Vermorel: Esattamente. Se hai silos indipendenti, è molto facile scalare il tuo processo. Ma la sfida è quando inizi a pensare alla tua rete come a un’unica entità in cui tutto è collegato. Puoi effettivamente spedire inventario e materiali in tutta la rete in praticamente qualsiasi modo tu voglia. Anche se ci sono molte modalità che non sono redditizie e non hanno senso, è possibile. E alcune di queste modalità sottili potrebbero essere idee molto buone e redditizie. Hai bisogno di un sistema che possa elaborare tutto in una volta sola, in modo monolitico. Cosa significa per il futuro? Significa che si aprono molte possibilità per una migliore ottimizzazione olistica. La maledizione dell’ottimizzazione della supply chain è che non risolvi i problemi; li sposti solo. Puoi guardare un’area e ottimizzarla, ma tutto ciò che stai facendo è spostare il problema lungo la linea o indietro al fornitore. Un’altra possibilità è che ora che abbiamo guadagnato significativamente in scalabilità, probabilmente cercheremo di tornare all’espressività. Fondamentalmente, cerchiamo di esprimere situazioni complesse che si verificano nel mondo reale in modo più diretto e fluente in quegli script di Envision. In questo modo, è più facile fornire ricette numeriche che si adattino bene alle situazioni del mondo reale.

Kieran Chandler: Sembra fantastico. Dobbiamo concludere qui, ma grazie per il tuo tempo oggi. Questo è tutto per questa settimana. Grazie mille per aver guardato e ci vediamo la prossima volta. Ciao per ora.