00:05 Einführung
02:50 Zwei Täuschungen
09:09 Ein Compiler-Pipeline
14:23 Der bisherige Verlauf
18:49 Frachtbrief
19:40 Sprachdesign
23:52 Die Zukunft
30:35 Die Vergangenheit
35:57 Die Kämpfe auswählen
39:45 Grammatiken 1/3
42:41 Grammatiken 2/3
49:02 Grammatiken 3/3
53:02 Statische Analyse 1/2
58:50 Statische Analyse 2/2
01:04:55 Typsystem
01:11:59 Compiler-Internas
01:27:48 Laufzeitumgebung
01:33:57 Fazit
01:36:33 Bevorstehende Vorlesung und Fragen des Publikums
Beschreibung
Die Mehrheit der Lieferketten wird immer noch über Tabellenkalkulationen (z. B. Excel) abgewickelt, während Unternehmenssysteme seit ein, zwei oder manchmal sogar drei Jahrzehnten im Einsatz sind - angeblich, um sie zu ersetzen. Tatsächlich bieten Tabellenkalkulationen eine zugängliche programmatische Ausdrucksfähigkeit, während diese Systeme dies im Allgemeinen nicht tun. Allgemeiner gesagt gibt es seit den 1960er Jahren eine ständige gemeinsame Entwicklung der Softwareindustrie als Ganzes und ihrer Programmiersprachen. Es gibt Hinweise darauf, dass die nächste Stufe der Leistung der Lieferkette weitgehend durch die Entwicklung und den Einsatz von Programmiersprachen oder besser gesagt von programmierbaren Umgebungen vorangetrieben wird.
Vollständiges Transkript
Willkommen zu dieser Reihe von Vorlesungen zur Lieferkette. Ich bin Joannes Vermorel und heute werde ich “Sprachen und Compiler für die Lieferkette” präsentieren. Ich erinnere mich nicht daran, jemals Compiler in einem Lehrbuch zur Lieferkette diskutiert zu haben, und doch ist das Thema von grundlegender Bedeutung. Wir haben im allerersten Kapitel dieser Reihe, in der Vorlesung mit dem Titel “Produktorientierte Lieferung”, gesehen, dass Programmierung der Schlüssel ist, um die investierte Zeit von Lieferkettenexperten zu nutzen. Ohne Programmierung können wir ihre Zeit nicht nutzen und behandeln Lieferkettenexperten als entbehrlich.
Darüber hinaus haben wir in diesem vierten Kapitel in den beiden vorherigen Vorlesungen “Mathematische Optimierung für die Lieferkette” und “Maschinelles Lernen für die Lieferkette” gesehen, dass diese beiden Bereiche - Optimierung und Lernen - im Laufe des letzten Jahrzehnts von Programmierparadigmen angetrieben wurden, anstatt eine Reihe von Algorithmen und Modellen zu bleiben, wie es in der Vergangenheit der Fall war. All diese Elemente weisen auf die grundlegende Bedeutung von Programmiersprachen hin und werfen somit die Frage nach einer Programmiersprache und einem Compiler auf, die entwickelt wurden, um Herausforderungen in der Lieferkette anzugehen.
Der Zweck dieser Vorlesung besteht darin, das Design einer solchen Programmiersprache für die Zwecke der Lieferkette zu entmystifizieren. Ihr Unternehmen wird wahrscheinlich nie eine solche Programmiersprache selbst entwickeln. Dennoch ist es wichtig, einige Einblicke in das Thema zu haben, um die Angemessenheit der von Ihnen verwendeten Werkzeuge beurteilen zu können und um die Angemessenheit der Werkzeuge zu beurteilen, die Sie erwerben möchten, um den Herausforderungen in der Lieferkette Ihres Unternehmens gerecht zu werden. Darüber hinaus sollte Ihnen diese Vorlesung auch dabei helfen, einige der großen Fehler zu vermeiden, die Menschen, die keinerlei Einblick in dieses Thema haben, in diesem Bereich tendieren zu machen.
Fangen wir damit an, zwei Illusionen zu zerstreuen, die in den letzten drei Jahrzehnten in Unternehmenssoftware Kreisen weit verbreitet waren. Die erste ist die “Lego-Programmierung” Illusion, bei der Programmierung als etwas betrachtet wird, das vollständig umgangen werden kann. Tatsächlich ist Programmierung schwierig, und es gibt immer Anbieter, die versprechen, dass durch ihr Produkt und ihre fantastische Technologie die Programmierung in ein visuelles Erlebnis verwandelt werden kann, das für jeden zugänglich ist und alle Schwierigkeiten der Programmierung selbst vollständig beseitigt, so dass das Erlebnis im Wesentlichen dem Zusammenbauen von Lego ähnelt, etwas, das sogar ein Kind tun kann.
Dies wurde in den letzten Jahrzehnten unzählige Male versucht und ist immer wieder gescheitert. Im besten Fall wurden Produkte, die ein visuelles Erlebnis bieten sollten, zu regulären Programmiersprachen, die im Vergleich zu anderen Programmiersprachen nicht besonders leicht zu beherrschen sind. Dies ist übrigens der Grund, warum es in der Serie von Microsoft-Produkten beispielsweise die “Visual”-Serie gibt, wie Visual Basic for Application und Visual Studio. Alle diese visuellen Produkte wurden in den 90er Jahren eingeführt, in der Hoffnung, die Programmierung in ein rein visuelles Erlebnis mit Designern zu verwandeln, bei dem man nur noch ziehen und ablegen muss. Die Realität ist, dass all diese Tools letztendlich einen sehr hohen Grad an Erfolg erzielt haben, aber heutzutage sind sie einfach nur ziemlich normale Programmiersprachen. Von den visuellen Teilen, die am Anfang dieser Produkte standen, ist sehr wenig übrig geblieben.
Der Lego-Ansatz ist gescheitert, weil der Flaschenhals nicht das Hindernis der Programmiersyntax ist. Dies ist ein Hindernis, aber ein minimales, insbesondere im Vergleich zum Beherrschen der Konzepte, die immer dann ins Spiel kommen, wenn Sie jede Art von anspruchsvoller Automatisierung einführen möchten. Ihr Verstand wird zum Flaschenhals, und Ihr Verständnis der Konzepte, die im Spiel sind, ist viel bedeutender als die Syntax.
Die zweite Illusion ist die “Star Wars Tech” Illusion, die darin besteht zu denken, dass es einfach ist, fantastische Technologien einzusetzen. Diese Illusion ist sowohl für Anbieter als auch für interne Projekte sehr verlockend. Es ist sehr verlockend zu sagen, dass es diese fantastische NoSQL-Datenbank gibt, die wir einfach einsetzen können, oder dass es diesen fantastischen Deep Learning Stack gibt, den wir übernehmen können, oder diese Graphdatenbank oder dieses verteilte Aktiv-Framework usw. Das Problem bei diesem Ansatz ist, dass Technologie behandelt wird, wie es in Star Wars behandelt wird. Wenn man eine mechanische Hand hat, kann der Held die mechanische Hand einfach nehmen und sie funktioniert. Aber in der Realität dominieren Integrationsprobleme.
Star Wars umgeht die Tatsache, dass es eine Reihe von Problemen geben würde: Zuerst bräuchten Sie Antibiotika, dann eine lange Umschulung der Hand, um sie überhaupt benutzen zu können. Sie bräuchten auch ein Wartungsprogramm für die Hand, weil sie mechanisch ist, und was ist mit der Stromquelle usw. All diese Probleme werden einfach umgangen. Sie stecken einfach das fantastische Stück Technologie ein, und es funktioniert. Das ist in der Realität nicht der Fall. Integrationsprobleme dominieren, und zum Beispiel arbeiten in großen Softwareunternehmen die meisten Softwareingenieure nicht an fantastisch coolen Technologien. Der Großteil der Ingenieurarbeit der großen Mehrheit dieser großen Softwareanbieter ist ausschließlich der Integration aller Teile gewidmet.
Wenn Sie Module, Komponenten oder Apps haben, benötigen Sie eine kleine Armee von Ingenieuren, um all diese Dinge zusammenzufügen und mit allen Problemen umzugehen, die auftreten, wenn Sie diese Dinge zusammenbringen möchten. Selbst wenn Sie alle Hürden der Integration überwunden haben, benötigen Sie immer noch eine große Anzahl von Ingenieuren, um mit der Tatsache umzugehen, dass Sie, wenn Sie einen Teil des Systems ändern, tendenziell Probleme in anderen Teilen des Systems verursachen. Sie benötigen also diese Ingenieurarbeit, um diese Probleme zu beheben.
Übrigens, als Anekdote, ein weiteres Problem, das ich bei coolen Technologien beobachtet habe, ist der Dunning-Kruger-Effekt, den sie bei Ingenieuren hervorrufen. Sie führen ein cooles Stück Technologie in Ihren Stack ein, und plötzlich denken Ingenieure, nur weil sie mit einer Technologie spielen, die sie kaum verstehen, dass sie plötzlich KI-Experten oder so etwas sind. Das ist ein typischer Fall des Dunning-Kruger-Effekts und hängt sehr stark mit der Anzahl der coolen Technologien zusammen, die Sie in Ihre Lösung einbringen. Zusammenfassend lässt sich sagen, dass wir mit diesen beiden Illusionen das Problem der Programmierung nicht wirklich umgehen können. Wir müssen es funktional angehen, einschließlich der schwierigen Teile.
Nun, nachdem das gesagt ist, das Interessante an Programmiersprachen ist, dass Unternehmenssoftwareanbieter versehentlich ständig Programmiersprachen neu erfinden. Tatsächlich besteht in der Supply Chain ein enormer Bedarf an Konfigurierbarkeit. Wie wir in früheren Vorlesungen gesehen haben, ist die Welt der Supply Chain vielfältig und die Probleme sind zahlreich und vielfältig. Wenn Sie also ein Supply Chain Softwareprodukt haben, besteht ein äußerst intensiver Bedarf an Konfigurierbarkeit. Übrigens ist dies der Grund, warum die Konfiguration einer Software in der Regel ein mehrmonatiges oder manchmal sogar mehrjähriges Projekt ist. Es gibt eine enorme Menge an Komplexität, die in diese Konfiguration einfließt.
Konfigurationseinstellungen sind oft komplex, nicht nur Schaltflächen oder Kontrollkästchen. Sie können Auslöser, Formeln, Schleifen und allerlei Blöcke haben. Es gerät schnell außer Kontrolle, und durch diese Konfigurationseinstellungen erhalten Sie eine emergente Programmiersprache. Da es sich jedoch um eine emergente Programmiersprache handelt, ist sie in der Regel sehr schlecht.
Die Entwicklung einer tatsächlichen Programmiersprache ist eine etablierte Ingenieuraufgabe. Es gibt Dutzende von Büchern über die praktischen Aspekte der Entwicklung eines produktionsreifen Compilers. Ein Compiler ist ein Programm, das Anweisungen, normalerweise Textanweisungen, in Maschinencode oder eine niedrigere Form von Anweisungen umwandelt. Immer wenn es eine Programmiersprache gibt, ist ein Compiler beteiligt. Zum Beispiel haben Sie in einer Excel-Tabelle Formeln, und Excel hat einen eigenen Compiler, um diese Formeln zu kompilieren und auszuführen. Wahrscheinlich haben die meisten Zuhörer ihr gesamtes Berufsleben lang Compiler verwendet, ohne es zu wissen.
Auf dem Diagramm sehen Sie eine typische Pipeline, und dieses Archetyp passt zu den meisten Programmiersprachen, von denen Sie wahrscheinlich jemals gehört haben, wie Python, JavaScript, Java und C#. All diese Sprachen haben eine Pipeline, die im Wesentlichen der hier skizzierten ähnelt. In einer Compiler-Pipeline haben Sie eine Reihe von Transformationen, und in jeder Phase des Prozesses haben Sie eine Repräsentation, die das gesamte Programm darstellt. Die Art und Weise, wie ein Compiler entwickelt wird, besteht darin, eine Reihe von klar definierten Transformationen zu haben, und in jeder Phase des Prozesses arbeiten Sie mit dem gesamten Programm. Es wird nur anders dargestellt.
Die Idee ist, dass jede Transformation für eine klar definierte Menge von Problemen verantwortlich ist. Sie lösen diese Probleme und gehen dann zur nächsten Transformation über, die einen anderen Aspekt des Prozesses behandelt. In der Regel bewegen Sie sich in jeder Phase näher am maschinennahen Code. Der Compiler beginnt mit dem Skript, und er beginnt mit Transformationen, die sehr nahe an der Syntax der interessierenden Programmiersprache liegen. Während dieser frühen Transformationen erfasst ein typischer Compiler syntaktische Fehler, die verhindern, dass der Compiler ein Skript, das nicht einmal ein gültiges Programm darstellt, in etwas ausführbares umwandelt. Wir werden später in dieser Vorlesung genauer auf eine Compiler-Pipeline eingehen.
Diese Vorlesung ist die fünfte Vorlesung des vierten Kapitels dieser Serie. Im ersten Kapitel habe ich meine Ansichten über die Supply Chain sowohl als Forschungsfeld als auch als Praxis vorgestellt. Im zweiten Kapitel habe ich die geeigneten Methoden für den Umgang mit Situationen in der Supply Chain untersucht. Wie wir gesehen haben, sind die meisten Situationen in der Supply Chain ziemlich konfrontativ, daher benötigen wir Strategien und Methoden, die resilient gegenüber konfrontativem Verhalten aller Parteien innerhalb und außerhalb der Unternehmen sind.
Das dritte Kapitel ist dem Supply Chain-Personal gewidmet und befasst sich ausschließlich mit der Untersuchung der Supply Chain-Probleme selbst. Wir müssen sehr vorsichtig sein, um das Problem, das wir aufdecken, nicht mit der Art von Lösung zu verwechseln, die wir uns vorstellen können, um dieses Problem anzugehen. Das sind zwei verschiedene Anliegen: Wir müssen das Problem von der Lösung trennen.
Das vierte und aktuelle Kapitel dieser Vorlesungsreihe ist den Hilfswissenschaften der Supply Chain gewidmet. Diese Hilfswissenschaften sind nicht die Supply Chain selbst, aber sie sind sehr hilfreich für die Praxis der modernen Supply Chain. Wir bewegen uns derzeit durch die Abstraktionsleiter. Wir haben dieses Kapitel mit der Physik der Berechnung begonnen, dann mit Algorithmen sind wir in den Bereich der Software gewechselt. Wir haben die mathematische Optimierung eingeführt, die für die Supply Chain von großem Interesse ist und auch die Grundlage für maschinelles Lernen bildet.
Heute stellen wir Sprachen und Compiler vor, die für die Implementierung jeder Art von Programmierparadigma unerlässlich sind. Obwohl das Thema Sprachen und Compiler für das Publikum überraschend sein mag, glaube ich, dass es zu diesem Zeitpunkt nicht allzu überraschend sein sollte. Wir haben gesehen, dass mathematische Optimierung und maschinelles Lernen heutzutage durch Programmierparadigmen angegangen werden sollten, was die Frage aufwirft, wie man diese Programmierparadigmen implementiert. Das führt uns zum Entwurf einer Programmiersprache und ihres unterstützenden Compilers, was genau das Thema für heute ist.
Dies ist eine Zusammenfassung des Rests dieser Vorlesung. Wir werden mit hochrangigen Beobachtungen zur Geschichte und zum Markt der Programmiersprachen beginnen. Wir werden Branchen überprüfen, die meiner Meinung nach sowohl die Zukunft als auch die Vergangenheit der Supply Chain repräsentieren. Dann werden wir uns allmählich mit dem Entwurf von Programmiersprachen und Compilern befassen und uns mit niedrigeren Ebenen und den technischen Details des Entwurfs eines Compilers befassen.
Seit den 1950er Jahren wurden Tausende von Programmiersprachen in die Produktion gebracht. Schätzungen variieren, aber die Anzahl der Programmiersprachen, die für Produktionszwecke verwendet wurden, liegt wahrscheinlich zwischen tausend und zehntausend. Viele dieser Sprachen sind nur Variationen oder Verwandte voneinander, manchmal sogar nur der Codebasis des Compilers, der in eine etwas andere Richtung verzweigt wurde. Es ist bemerkenswert, dass mehrere sehr große Unternehmen für Unternehmenssoftware durch die Einführung eigener Programmiersprachen stark expandiert sind. Zum Beispiel führte SAP 1983 ABAP ein, Salesforce führte 2006 Apex ein und sogar Microsoft begann vor Windows mit der Entwicklung von Altair BASIC im Jahr 1975.
Historisch gesehen werden sich diejenigen von Ihnen im Publikum, die alt genug sind, um sich an die 90er Jahre zu erinnern, daran erinnern, dass die Anbieter damals mit Programmiersprachen der dritten und vierten Generation warben. Die Realität ist, dass es eine gut definierte Reihe von Generationen gab - erste, zweite, dritte, vierte usw. - die zur fünften führten, wo die Community im Wesentlichen aufhörte, in Bezug auf Generationen zu zählen. Während der ersten drei oder vier Jahrzehnte folgten all diese Programmiersprachen einer schönen Entwicklung hin zu höheren Abstraktionsebenen. Ende der 90er Jahre gab es jedoch bereits viele weitere Richtungen neben einer höheren Abstraktion, je nach Anwendungsfall.
Das Entwickeln einer neuen Programmiersprache wurde schon oft gemacht. Es ist ein etabliertes Gebiet der Ingenieurwissenschaften, und es gibt ganze Bücher, die sich praktisch mit dem Thema befassen. Die Entwicklung einer neuen Programmiersprache ist eine Praxis, die viel bodenständiger und vorhersehbarer ist als beispielsweise ein Data-Science-Experiment durchzuführen. Es besteht eine nahezu sichere Gewissheit, dass Sie das gewünschte Ergebnis erhalten, wenn Sie die angemessene Ingenieurarbeit leisten und berücksichtigen, was heute bekannt ist und als Wissen verfügbar ist.
Das wirft wirklich die Frage auf: Was ist mit einer speziell für Supply-Chain-Zwecke entwickelten Programmiersprache? Tatsächlich kann es erhebliche Vorteile in Bezug auf Produktivität, Zuverlässigkeit und sogar Leistung der Lieferkette geben.
Um diese Frage zu beantworten, müssen wir einen Blick in die Zukunft werfen. Glücklicherweise gibt es für uns den einfachsten Weg, in die Zukunft zu schauen, indem wir uns eine Branche ansehen, die in den letzten drei Jahrzehnten konsequent ein Jahrzehnt voraus war und das ist die Videospielindustrie. Dies ist heutzutage eine sehr große Branche, und um Ihnen eine Vorstellung von der Größenordnung zu geben: Die Videospielindustrie ist weltweit zwei Drittel so groß wie die Luft- und Raumfahrtindustrie in Bezug auf die vergleichbare Größe und wächst viel schneller als die Luft- und Raumfahrtindustrie. In zehn Jahren könnten Videospiele tatsächlich größer sein als die Luft- und Raumfahrtindustrie.
Das Interessante an der Videospielindustrie ist, dass sie eine sehr gut etablierte Struktur hat. Zunächst haben wir Spiele-Engines, wobei die beiden Marktführer Unity und Unreal sind. Diese Spiele-Engines bieten die Low-Level-Komponenten, die für hochintensive, raffinierte 3D-Grafiken von Interesse sind, und sie legen die Landschaft für das Infrastrukturniveau Ihres Codes fest. Es gibt einige Unternehmen, die sehr komplexe Produkte namens Spiele-Engines entwickeln, und diese Engines werden von der gesamten Branche verwendet.
Als nächstes haben wir Spielestudios, die den Spielcode für jedes einzelne Spiel entwickeln. Der Spielcode wird eine Codebasis sein, die in der Regel spezifisch für das entwickelte Spiel ist. Die Spiele-Engine erfordert sehr hardcore Softwareingenieure, die technisch sehr versiert sind, aber nicht unbedingt viel über Spiele wissen. Die Entwicklung des Spielcodes erfordert nicht so viel reine technische Fähigkeiten. Die Softwareingenieure, die den Spielcode entwickeln, müssen jedoch das Spiel verstehen, an dem sie arbeiten. Der Spielcode legt die Plattform für die Spielmechanik fest, gibt jedoch nicht die Details vor.
Diese Aufgabe wird in der Regel von Spiele-Designern übernommen, die keine Softwareingenieure sind, aber Code in den Skriptsprachen schreiben, die ihnen vom Entwicklungsteam für den Spielcode zur Verfügung gestellt werden. Wir haben diese drei Stufen: Spiele-Engines, bei denen hochtechnische Hardcore-Softwareingenieure Kernbausteine entwickeln; Studios, die Entwicklungsteams haben, in der Regel eines pro Spiel, die das Spiel als Plattform für die Spielmechanik entwickeln; und schließlich Spiele-Designer, die keine Softwareingenieure sind, sondern Spiele-Spezialisten, die das Verhalten implementieren, das die Spieler, die Kunden am Ende der Pipeline, glücklich machen wird.
Heutzutage ist der Spielcode häufig für die Fangemeinde zugänglich, was bedeutet, dass Spiele-Designer Regeln schreiben und das Spiel möglicherweise ändern können, aber auch Fans, die nur normale Verbraucher der Spiele sind, können das tun. In der Branche gibt es einige interessante Anekdoten. Zum Beispiel begann das Spiel Dota 2, das unglaublich erfolgreich ist, als Modifikation eines bestehenden Spiels. Die erste Version, einfach Dota genannt, war eine reine Fanbase-Modifikation des Spiels World of Warcraft 3. Sie können sehen, dass dieser Grad an Konfigurierbarkeit und Programmierbarkeit auf der Ebene der Spielregeln sehr umfangreich ist, da es möglich war, aus einem bestehenden kommerziellen Spiel, World of Warcraft 3, ein völlig neues Spiel zu erstellen, das dann durch die zweite Version zu einem massiven kommerziellen Erfolg wurde. Nun, das ist interessant, und wir können anfangen, indem wir uns die Spieleindustrie ansehen, darüber nachzudenken, was das für die Supply-Chain-Branche bedeutet.
Nun, wir könnten darüber nachdenken, welche Art von Parallele wir ziehen könnten. Wir könnten eine Supply Chain Engine haben, die sich um die sehr schwierigen algorithmischen Teile, die Low-Level-Infrastruktur und die Kern-Technologie-Bausteine wie mathematische Optimierung und maschinelles Lernen kümmert. Die Idee ist, dass für jede einzelne Supply Chain ein Engineering-Team benötigt wird, um alle relevanten Daten zu bringen und die gesamte Anwendungslandschaft zu integrieren.
Als erste Stufe bräuchten wir das Äquivalent von Spiele-Designern, die Supply Chain-Spezialisten wären. Diese Spezialisten sind keine Software-Ingenieure, aber sie sind diejenigen, die durch vereinfachten Code alle Regeln und Mechanismen schreiben werden, die für die Implementierung der prädiktiven Optimierung für die Supply Chain erforderlich sind. Die Spieleindustrie liefert ein anschauliches Beispiel dafür, was in den nächsten Jahrzehnten im Bereich der Supply Chain passieren wird.
Bisher bleibt der Ansatz der Spieleindustrie in der Supply Chain Science-Fiction, abgesehen von einigen Unternehmen. Ich glaube, dass die meisten dieser Unternehmen zufällig Kunden von Lokad sind. Zurück zum heutigen Thema: Wir haben in früheren Vorlesungen gesehen, dass Excel die Nummer eins Programmiersprache in dieser Branche bleibt. Übrigens ist Excel in Bezug auf Programmiersprachen eine funktionale reaktive Programmiersprache, also eine eigene Klasse.
Sie hören vielleicht heutzutage von Anbietern, die vorschlagen, die Supply Chains mit Hilfe einer Art Data Science-Setup zu verbessern. Meine beiläufige Beobachtung der letzten zehn Jahre ist jedoch, dass die überwiegende Mehrheit dieser Initiativen gescheitert ist. Das ist bereits Vergangenheit, und um zu verstehen, warum, müssen wir uns die Liste der beteiligten Programmiersprachen ansehen. Wenn wir uns Excel ansehen, sehen wir, dass es im Wesentlichen zwei Programmiersprachen umfasst: Excel-Formeln und VBA. VBA ist nicht einmal eine Voraussetzung; Sie können weit kommen, indem Sie nur VLOOKUPs in Excel verwenden. In der Regel wird es nur eine Programmiersprache sein, und sie ist für Nicht-Software-Ingenieure zugänglich.
Auf der anderen Seite ist die Liste der Programmiersprachen, die erforderlich sind, um die Fähigkeiten von Excel mit einem Data Science-Setup zu replizieren, ziemlich umfangreich. Wir benötigen SQL und möglicherweise mehrere SQL-Dialekte, um auf die Daten zuzugreifen. Wir benötigen Python, um die Kernlogik zu implementieren. Python allein tendiert jedoch dazu, langsam zu sein, daher benötigen Sie möglicherweise eine Unterprogrammiersprache wie NumPy. An diesem Punkt tun Sie immer noch nichts in Bezug auf maschinelles Lernen oder mathematische Optimierung, daher benötigen Sie für eine echte Hardcore-Numerikanalyse etwas anderes, eine eigene Programmiersprache wie zum Beispiel PyTorch. Jetzt, da Sie all diese Elemente haben, haben Sie schon ziemlich viele bewegliche Teile, sodass Ihre Konfiguration der Anwendung selbst ziemlich komplex sein wird. Sie benötigen eine Konfiguration, und diese Konfiguration wird mit einer weiteren Programmiersprache wie JSON oder XML geschrieben. Diese sind zwar keine superkomplexen Programmiersprachen, aber sie kommen noch hinzu.
Was passiert, wenn Sie so viele bewegliche Teile haben, ist, dass Sie in der Regel ein Build-System benötigen, etwas, das alle Compiler und banalen Rezepte ausführen kann, die benötigt werden, um die Software zu erstellen. Build-Systeme haben ihre eigenen Sprachen. Der traditionelle Ansatz ist eine Sprache namens Make, aber es gibt viele andere. Zusätzlich, da Excel Ergebnisse anzeigen kann, benötigen Sie eine Möglichkeit, Dinge für den Benutzer anzuzeigen und zu visualisieren. Dies wird mit einer Mischung aus JavaScript, HTML und CSS gemacht, was die Liste um weitere Sprachen erweitert.
Zu diesem Zeitpunkt haben wir eine lange Liste von Programmiersprachen, und ein tatsächliches Produktions-Setup könnte noch komplexer sein. Das erklärt, warum die meisten Unternehmen, die in den letzten zehn Jahren versucht haben, diese Data Science-Pipeline zu nutzen, überwiegend gescheitert sind und in der Praxis bei Excel geblieben sind. Der Grund dafür ist, dass es bedeutet, fast ein Dutzend Programmiersprachen zu beherrschen, anstatt nur eine, wie im Fall von Excel. Wir haben noch nicht einmal damit begonnen, eines der eigentlichen Supply-Chain-Probleme anzugehen; wir haben nur über die technischen Details gesprochen, die im Weg stehen, um überhaupt etwas zu tun.
Nun, lassen Sie uns darüber nachdenken, wie eine Programmiersprache für die Supply Chain aussehen könnte. Zunächst müssen wir entscheiden, was in der Sprache enthalten ist und was zur Sprache als Bürger erster Klasse gehört und was zu Bibliotheken gehört. Tatsächlich ist es bei Programmiersprachen immer möglich, Fähigkeiten an Bibliotheken auszulagern. Betrachten wir zum Beispiel die Programmiersprache C. Sie gilt als ziemlich niedrigstufige Programmiersprache, und C hat keinen Garbage Collector. Es ist jedoch möglich, einen Garbage Collector von Drittanbietern als Bibliothek in einem C-Programm zu verwenden. Da die Garbage Collection kein Bürger erster Klasse in der Programmiersprache C ist, ist die Syntax tendenziell relativ umfangreich und mühsam.
Für die Supply Chain gibt es Anforderungen wie mathematische Optimierung und maschinelles Lernen, die in der Regel als Bibliotheken behandelt werden. Daher haben wir eine Programmiersprache, und all diese Anforderungen werden im Wesentlichen an Bibliotheken ausgelagert. Wenn wir jedoch eine Programmiersprache für die Supply Chain entwickeln würden, würde es wirklich Sinn machen, diese Anforderungen als Bürger erster Klasse in die Programmiersprache selbst zu integrieren. Außerdem würde es Sinn machen, relationale Daten als Teil der Sprache als Bürger erster Klasse zu haben. In der Supply Chain hat die Anwendungslandschaft, zu der viele Unternehmenssoftwarekomponenten gehören, relationale Daten in Form von relationalen Datenbanken wie SQL-Datenbanken überall. Praktisch alle heutzutage existierenden Unternehmenssoftwareprodukte haben als Kern eine relationale Datenbank, was bedeutet, dass wir in der Supply Chain, sobald wir die Daten berühren wollen, in der Realität mit relationalen Daten interagieren werden. Die Daten präsentieren sich als Liste von Tabellen, die aus all diesen Datenbanken extrahiert wurden, die verschiedene Apps unterstützen, und jede Tabelle hat eine Liste von Spalten oder Feldern.
Es macht wirklich Sinn, relationale Daten in der Sprache zu haben. Was ist außerdem mit der Benutzeroberfläche (UI) und der Benutzererfahrung (UX)? Einer der Stärken von Excel ist, dass all das vollständig in die Sprache eingebettet ist, sodass Sie keine Programmiersprache und dann alle möglichen Bibliotheken von Drittanbietern haben, um sich mit Präsentation, Rendering und Benutzerinteraktion zu befassen. All das gehört zur Sprache. Es wäre auch von sehr großem Interesse im Hinblick auf die Supply Chain, wenn all das als Bürger erster Klasse vorhanden wäre, zumindest wenn wir so gut sein wollen wie Excel für Supply Chains sein kann.
Bei der Sprachgestaltung repräsentiert die Grammatik die formale Darstellung der Regeln, die ein gültiges Programm gemäß Ihrer neu eingeführten Programmiersprache definieren. Im Wesentlichen beginnen Sie mit einem Textstück, und zuerst wenden Sie einen Lexer an, der eine spezifische Klasse von Algorithmen oder ein kleines Programm ist. Der Lexer zerlegt Ihr Textstück, das Programm, das Sie gerade geschrieben haben, in eine Sequenz von Tokens. Der Lexer isoliert alle Variablen und Symbole, die in Ihrer Programmiersprache verwendet werden. Die Grammatik hilft dabei, die Sequenz von Tokens in die eigentliche Semantik des Programms umzuwandeln und zu definieren, was das Programm bedeutet und welche genauen, eindeutigen Operationen ausgeführt werden müssen, um es auszuführen.
Die Grammatik selbst wird in der Regel als Kompromiss zwischen den Anliegen betrachtet, die Sie in Ihrer Sprache internalisieren möchten, und den Konzepten, die Sie externalisieren möchten. Wenn wir zum Beispiel relationale Daten als externes Anliegen betrachten, müsste der Programmierer viele spezialisierte Datenstrukturen wie Wörterbücher, Suchtabellen und Hash-Tabellen einführen, um manuell innerhalb der Programmiersprache all diese Operationen durchzuführen. Wenn die Grammatik die relationale Algebra internalisieren möchte, bedeutet das, dass der Programmierer in der Regel die gesamte relationale Logik direkt in ihrer relationalen Form schreiben kann. Das bedeutet jedoch, dass plötzlich all diese relationalen Einschränkungen und die gesamte relationale Algebra zu einer Belastung werden, die die Grammatik tragen muss.
Aus der Perspektive der Lieferkette ist relationale Daten in Unternehmenssoftware sehr verbreitet, daher ist es sinnvoll, dass eine Grammatik sich direkt auf der Grammatikebene um alle relationalen Anliegen kümmert.
Grammatiken in der Informatik sind ein enorm untersuchtes Thema. Sie existieren seit Jahrzehnten und dennoch ist es wahrscheinlich der Bereich, in dem Anbieter von Unternehmenssoftware am meisten scheitern. Tatsächlich erzeugen sie unweigerlich zufällige Programmiersprachen, die natürlich entstehen, wann immer komplexe Konfigurationseinstellungen im Spiel sind. Wenn Sie Bedingungen, Trigger, Schleifen und Reaktionen haben, müssen Sie sich in der Regel um diese Sprache kümmern, anstatt sie einfach von selbst entstehen zu lassen.
Was passiert, wenn Sie keine Grammatik haben, ist, dass Sie bei Änderungen an der Anwendung unvorhersehbare Auswirkungen auf das tatsächliche Verhalten des Systems haben werden. Übrigens erklärt dies auch, warum ein Upgrade von einer Version einer Unternehmenssoftware auf eine andere in der Regel sehr komplex ist. Die Konfiguration soll gleich sein, aber wenn Sie versuchen, dieselbe Konfiguration in der nächsten Version der Software auszuführen, erhalten Sie völlig unterschiedliche Ergebnisse. Die Ursache für diese Probleme ist das Fehlen einer Grammatik und einer etablierten formalisierten Semantik dafür, was die Konfiguration bedeuten wird.
Die typische Art, eine Grammatik formal darzustellen, ist die Verwendung der Backus-Naur-Form (BNF), die eine spezielle Notation ist. Auf dem Bildschirm sehen Sie eine Mini-Programmiersprache, die US-Postadressen repräsentiert. Jede Zeile mit einem Gleichheitszeichen stellt eine Produktionsregel dar. Auf der linken Seite haben Sie ein nicht-terminales Symbol, und auf der rechten Seite des Gleichheitszeichens befindet sich eine Sequenz von terminalen und nicht-terminalen Symbolen. Terminale Symbole sind rot und repräsentieren Symbole, die nicht weiter abgeleitet werden können. Nicht-terminale Symbole befinden sich in eckigen Klammern und können weiter abgeleitet werden. Diese Grammatik hier ist nicht vollständig; es müssten noch viele weitere Produktionsregeln hinzugefügt werden, um eine vollständige Grammatik zu erstellen. Ich wollte diese Folie nur einigermaßen knapp halten.
Eine Grammatik ist etwas sehr Einfaches, das in Bezug auf die Syntax für Ihre Programmiersprache definiert werden kann, und sie stellt auch sicher, dass sie nicht-ambigu ist. Es ist jedoch nicht so, dass eine Grammatik, die mit der Backus-Naur-Form geschrieben ist, eine gültige oder sogar gute Grammatik sein wird. Um eine gute Grammatik zu haben, müssen wir etwas mehr tun. Die mathematische Art, eine gute Grammatik zu charakterisieren, besteht darin, eine kontextfreie Grammatik zu haben. Eine Grammatik gilt als kontextfrei, wenn die Produktionsregeln für jedes Nichtterminal angewendet werden können, unabhängig von den Symbolen, die Sie rechts und links finden. Die Idee ist, dass eine kontextfreie Grammatik etwas ist, bei dem Sie die Produktionsregeln in beliebiger Reihenfolge anwenden können und sobald Sie eine Übereinstimmung oder Ableitung sehen, wenden Sie sie einfach an.
Was Sie aus einer kontextfreien Grammatik erhalten, ist eine Grammatik, bei der der Compiler das Programm, in dem die Mehrdeutigkeit auftritt, nicht kompilieren kann, wenn Sie etwas darin ändern und diese Änderung eine Mehrdeutigkeit erzeugt. Dies ist von besonderem Interesse, wenn Sie beabsichtigen, eine Konfiguration über einen längeren Zeitraum aufrechtzuerhalten. In Supply Chains sind die meisten Unternehmenssoftware sehr langlebig. Es ist nicht ungewöhnlich, dass Unternehmenssoftwarestücke zwei oder drei Jahrzehnte lang betrieben werden. Bei Lokad bedienen wir über 100+ Unternehmen, und es ist ziemlich üblich, dass wir Daten aus Systemen extrahieren, die seit über drei Jahrzehnten im Einsatz sind, insbesondere bei großen Unternehmen.
Mit einer kontextfreien Grammatik erhalten Sie die Garantie, dass Sie die Mehrdeutigkeiten identifizieren können, die auftreten, wenn Sie diese Änderung anwenden, wenn Änderungen an dieser Sprache vorgenommen werden sollen (und denken Sie daran, wenn ich “Sprache” sage, kann ich etwas so Grundlegendes wie Konfigurationseinstellungen meinen). Dies ist anstelle von Mehrdeutigkeiten, die einfach auftreten, ohne dass Sie erkennen, dass Sie ein Problem haben, was zu Schwierigkeiten beim Upgrade von einem System auf ein anderes führen kann.
Was passiert, wenn Menschen nichts über Grammatiken wissen, ist, dass sie manuell einen Parser schreiben. Wenn Sie noch nie von einer Grammatik gehört haben, würde ein Softwareingenieur einen Parser schreiben, der ein Programm erstellt, das eine Art Baum darstellt, der die geparste Version Ihres Programms darstellt. Das Problem dabei ist, dass Sie eine Semantik für Ihr Programm erhalten, die unglaublich spezifisch für die eine Version des Programms ist, die Sie haben. Wenn Sie also dieses Programm ändern, ändern Sie die Semantik und erhalten unterschiedliche Ergebnisse, was bedeutet, dass Sie dieselbe Konfiguration, aber unterschiedliches Verhalten für Ihre Supply Chain haben können.
Glücklicherweise gab es 2004 einen kleinen Durchbruch, der von Brian Ford mit einem Artikel mit dem Titel “Parsing Expression Grammars: A Recognition-Based Syntactic Foundation” eingeführt wurde. Mit dieser Arbeit hat Ford der Community eine Möglichkeit zur Formalisierung der Art von zufällig ad-hoc Parsern gegeben, die es in der Branche gibt. Diese Grammatiken werden zum Beispiel Parsing Expression Grammars (PEGs) genannt, und mit PEGs können Sie diese halb zufälligen empirischen Parser in tatsächliche formale Grammatiken irgendeiner Art umwandeln.
Python hat zum Beispiel keine kontextfreie Grammatik, sondern hat eine PEG. PEGs sind in Ordnung, wenn Sie einen umfangreichen Satz automatisierter Tests haben, weil Sie in diesem Fall mit der Erhaltung der Semantik im Laufe der Zeit umgehen können. Tatsächlich haben Sie mit PEGs eine Formalisierung Ihrer Grammatik, sodass Sie in einer besseren Situation sind als wenn Sie keine Grammatik haben und nur einen Parser haben. In Bezug auf die Entwicklung der Semantik werden Sie jedoch mit einer PEG nicht automatisch erkennen, dass Sie eine Änderung der Semantik haben, wenn Sie die Grammatik selbst ändern. Daher müssen Sie einen umfangreichen Satz automatisierter Tests auf Ihrer PEG haben, was übrigens genau das ist, was die Python-Community hat. Sie haben einen sehr robusten und umfangreichen Satz automatisierter Tests. Aus Sicht der Supply Chain glaube ich, dass Grammatiken nicht nur von Interesse sind, um Ihnen ihre Bedeutung bewusst zu machen, sondern auch einen Lackmustest darstellen. Sie können tatsächlich Unternehmenssoftwareanbieter testen, wenn Sie eine Software mit erheblicher Komplexität diskutieren. Sie sollten den Anbieter nach der Grammatik fragen, die er für die komplexe Konfiguration verwendet. Wenn der Anbieter mit “Was ist eine Grammatik?” antwortet, dann wissen Sie, dass Sie in Schwierigkeiten sind und die Wartung wahrscheinlich langsam und teuer sein wird.
Programmieren ist sehr schwierig, und Menschen machen viele Fehler. Wenn es einfach wäre, bräuchten wir Programmierung überhaupt nicht. Eine gute Programmiersprache minimiert die Zeit, die benötigt wird, um einen Fehler zu identifizieren und zu beheben. Dies ist einer der wichtigsten Aspekte einer Programmiersprache, der eine anständige Produktivität für jeden gewährleistet, der Code schreibt.
Betrachten wir die folgende Situation: Wenn der Fehler beim Schreiben des Codes erkannt werden kann, zum Beispiel durch eine rote Unterstreichung bei einem Tippfehler in Microsoft Word, dann kann die Rückkopplungsschleife zur Fehlerbehebung so kurz wie 10 Sekunden sein, was ideal ist. Wenn der Fehler erst erkannt werden kann, wenn das Programm ausgeführt wird, dauert die Rückkopplungsschleife mindestens 10 Minuten. In der Supply Chain haben wir oft große Datensätze zu verarbeiten, und wir können nicht erwarten, dass das Programm in wenigen Sekunden alle Daten durchläuft. Wenn das Problem also nur zur Laufzeit auftritt, dauert die Rückkopplungsschleife 10 Minuten oder länger.
Wenn der Fehler erst erkannt werden kann, nachdem das Skript abgeschlossen ist, das Programm also einen Fehler hat, aber nicht abstürzt, dauert die Rückkopplungsschleife etwa 10 Stunden oder länger. Wir sind von 10 Sekunden Echtzeit-Rückmeldung auf 10 Minuten umgestiegen, wenn wir das Programm ausführen müssen, und dann auf 10 Stunden, wenn wir die numerischen Ergebnisse und KPIs überprüfen müssen, die das Programm erzeugt.
Es gibt sogar noch schlimmere Szenarien: Wenn die Plattform, auf der Sie arbeiten, nicht streng deterministisch ist, das heißt, dass sie Ihnen bei gleicher Eingabe und Daten unterschiedliche Ergebnisse liefern kann. Das ist gar nicht so seltsam, denn in der Supply Chain können wir zum Beispiel Monte-Carlo-Simulationen haben. Wenn es also Zufälligkeit in den Ergebnissen gibt, kann es vorkommen, dass etwas nur gelegentlich fehlschlägt, und in dieser Situation dauert die Rückkopplungsschleife in der Regel länger als 10 Tage. Wir sind also von 10 Sekunden auf 10 Tage umgestiegen, und es steht viel auf dem Spiel, um diese Rückkopplungsschleife zu verkürzen. Statische Analyse stellt eine Reihe von Techniken dar, die angewendet werden können, um Probleme, Fehler oder Ausfälle zu erkennen, ohne das Programm überhaupt auszuführen. Bei statischer Analyse geht es darum, dass Sie das Programm nicht einmal ausführen müssen, was bedeutet, dass Sie den Fehler in Echtzeit melden können, während die Leute den Code eingeben, ähnlich wie eine rote Unterstreichung für Tippfehler in Microsoft Word. Allgemeiner gesagt besteht ein großes Interesse daran, jedes Problem so zu transformieren, dass es in eine frühere Klasse von Rückmeldungen aufsteigt, Probleme, die Tage dauern würden, in Minuten oder Minuten in Sekunden ändern usw.
Aus Sicht der Supply Chain haben wir in einer der vorherigen Vorlesungen gesehen, dass Supply Chains mit viel Chaos rechnen müssen. Wir können keine klassischen Release-Zyklen haben, bei denen Sie auf die nächste Version Ihrer Software warten. Manchmal gibt es außergewöhnliche Ereignisse wie eine Tarifänderung, ein Containerschiff, das im Kanal stecken bleibt, oder eine Pandemie. In solchen Notfallsituationen sind Notfallkorrekturen erforderlich, und die Menge an statischer Analyse, die Sie über Ihre Programmiersprache durchführen können, definiert im Wesentlichen, wie viel Chaos Sie in der Produktion aufgrund von Fehlern haben werden, die nicht in Echtzeit beim Tippen des Codes erfasst wurden. Außergewöhnliche Ereignisse mögen selten erscheinen, aber in der Praxis sind Überraschungen in der Supply Chain recht häufig.
Es gibt mathematische Beweise dafür, dass es nicht möglich ist, alle Fehler mit einer allgemeinen Programmiersprache in einer allgemeinen Situation zu erkennen. Zum Beispiel ist es nicht einmal möglich zu beweisen, dass das Programm abgeschlossen wird, das heißt, dass es nicht möglich ist, zu garantieren, dass das Geschriebene nicht einfach endlos weiterläuft.
Bei statischer Analyse erhalten Sie in der Regel drei Kategorien: Einige Teile des Codes sind wahrscheinlich gut, einige Teile sind wahrscheinlich schlecht, und für viele Dinge in der Mitte wissen Sie es einfach nicht. Die Idee ist, dass je mehr Sie von “nicht wissen” zu “schlechtem Code” verschieben, desto mehr Aufwand Sie in Bezug auf die Sprachgestaltung benötigen, um den Compiler davon zu überzeugen, dass Ihr Programm gültig ist. Wir müssen also einen Kompromiss finden zwischen dem Aufwand, den Sie investieren möchten, um die Programmiersprache davon zu überzeugen, dass Ihr Code korrekt ist, und den Garantien, die Sie zum Zeitpunkt der Kompilierung des Programms haben möchten, noch bevor das Programm tatsächlich ausgeführt wird. Das ist eine Frage der Produktivität.
Nun, eine schnelle Liste typischer Fehler, die mit statischer Analyse erkannt werden, umfasst Syntaxfehler wie vergessene Kommas oder Klammern. Einige Programmiersprachen können Syntaxfehler nicht einmal vor der Laufzeit anzeigen, wie zum Beispiel Bash, die Shell-Sprache unter Linux. Statische Analyse kann auch Typfehler erkennen, die auftreten, wenn Sie den falschen Typ oder die falsche Anzahl von Argumenten für eine Funktion aufrufen.
Unausführbarer Code kann ebenfalls erkannt werden, was bedeutet, dass der Code in Ordnung ist, aber niemals ausgeführt wird, weil das gesamte Programm ohne jenen Codeabschnitt ausgeführt werden kann. Es handelt sich um toten Code oder eine vergessene logische Verbindung. Unbedeutender Code ist ein weiteres Problem, das identifiziert werden kann, bei dem der Code ausgeführt wird, aber keinen Einfluss auf die endgültige Ausgabe hat. Es handelt sich um eine Variante von unerreichbarem Code.
Es kann auch überschüssiger Code erkannt werden, der sich auf Code bezieht, der ausgeführt würde, aber die benötigten Rechenressourcen weit übersteigt, die Sie für Ihr Programm aufbringen können. Ein Programm verbraucht Rechenressourcen wie Speicher, Speicherplatz und CPU. Durch statische Analyse können Sie nachweisen, dass ein Codeblock weit mehr Ressourcen verbraucht, als Sie sich leisten können, unter Berücksichtigung Ihrer Einschränkungen wie der Vervollständigung der Berechnung innerhalb eines bestimmten Zeitrahmens. Sie möchten, dass dies bereits zur Kompilierungszeit fehlschlägt, anstatt Ihr Programm eine Stunde lang auszuführen und dann aufgrund eines Timeouts fehlschlägt, was zu einer sehr geringen Produktivität führen würde.
Es gibt jedoch einen Haken bei der statischen Analyse. Beim Tippen haben Sie es immer mit einem ungültigen Programm zu tun. Wenn Sie Tastenanschlag für Tastenanschlag eingeben, verwandeln Sie ein gültiges Programm in ein ungültiges. Eine branchenübliche Lösung für diese Situation wird als Language Server Protocol bezeichnet. Dieses Tooling wird mit einer Programmiersprache geliefert und ist der Stand der Technik, wenn es um Echtzeit-Fehlerfeedback für die von Ihnen eingegebenen Programme geht.
Über ein Language Server Protocol können Sie Funktionen wie “Definition anzeigen” aufrufen, wenn Sie auf eine Variable klicken. Das Language Server Protocol ist grundsätzlich zustandsbehaftet und erinnert sich an die letzte Version Ihres Programms, die korrekt war, zusammen mit den verfügbaren Annotationen und Semantiken. Es behält diese Annotationen und zusätzlichen Informationen bei, wenn es mit Ihrem fehlerhaften Programm umgeht, nur weil Sie eine zusätzliche Taste gedrückt haben und es kein gültiges Programm mehr ist. Es ist ein Game Changer in Bezug auf Produktivität, und wann immer es einen gewissen Grad an Dringlichkeit gibt, macht es einen großen Unterschied für die Supply Chain-Zwecke.
Nun wollen wir uns das Typsystem genauer ansehen. Als erste grobe Annäherung ist ein Typsystem eine Reihe von Regeln, die die Kategorisierung innerhalb der Objekte in Ihrem Programm oder die Kategorisierung der Elemente, die Sie manipulieren, nutzen, um zu klären, ob bestimmte Interaktionen erlaubt oder nicht erlaubt sind. Beispiele für typische Typen sind Zeichenketten, Ganzzahlen und Gleitkommazahlen, die alle sehr grundlegende Typen sind. Es wird festlegen, dass das Hinzufügen von zwei Ganzzahlen gültig ist, das Hinzufügen einer Zeichenkette und einer Ganzzahl jedoch nicht gültig ist, außer in JavaScript, da die Semantik dort anders ist.
Typsysteme im Allgemeinen sind ein offenes Forschungsproblem und können unglaublich abstrakt werden. Um etwas Licht ins Dunkel zu bringen, müssen wir klären, dass es zwei Arten von Typen gibt, die häufig verwechselt werden. Erstens gibt es die Typen von Werten, die nur zur Laufzeit existieren, wenn das Programm tatsächlich ausgeführt wird. Zum Beispiel, in Python, wenn wir eine Funktion betrachten, die das erste Element eines Arrays von Ganzzahlen zurückgibt, dann ist der Typ des von dieser Funktion zurückgegebenen Werts eine Ganzzahl. Aus dieser Perspektive haben alle Programmiersprachen Typen - sie sind alle typisiert.
Zweitens gibt es die Typen von Variablen, die nur zur Kompilierungszeit existieren, während das Programm kompiliert wird und noch nicht ausgeführt wird. Die Herausforderung bei Variablentypen besteht darin, so viele Informationen wie möglich über diese Variablen zur Kompilierungszeit zu extrahieren. Wenn wir zum vorherigen Beispiel zurückkehren, kann es in Python möglich sein oder auch nicht, den Typ des Rückgabewerts der Funktion zu identifizieren, da Python zur Kompilierungszeit nicht vollständig stark typisiert ist.
Von einer Supply-Chain-Perspektive aus suchen wir nach einem Typsystem, das das unterstützt, was wir für die Supply Chain tun möchten. Wir möchten so restriktiv wie möglich sein, um Probleme und Fehler frühzeitig zu erfassen, aber auch so flexibel wie möglich, um alle interessanten Operationen zu ermöglichen. Betrachten wir zum Beispiel die Addition eines Datums und einer Ganzzahl. In einer regulären Programmiersprache würden Sie wahrscheinlich sagen, dass dies nicht zulässig ist, aber aus Sicht der Supply Chain wäre es sinnvoll, “Datum + 7” zu schreiben, wenn wir ein Datum haben und sieben Tage hinzufügen möchten. Es gibt viele Operationen in der Supply-Chain-Planung, bei denen Daten um eine bestimmte Anzahl von Tagen verschoben werden, daher wäre es nützlich, eine Algebra zu haben, in der eine Addition zwischen einem Datum und einer Zahl möglich ist.
In Bezug auf Typen möchten wir das Hinzufügen eines Datums zu einem anderen wahrscheinlich nicht zulassen. Aber möchten wir die Subtraktion zwischen zwei Daten zulassen? Warum nicht? Wenn wir ein Datum von einem anderen abziehen, das davor liegt, erhalten wir den Unterschied, der in Tagen ausgedrückt werden könnte. Dies ergibt für Berechnungen im Rahmen der Planung viel Sinn.
Wenn wir uns weiter mit dem Thema Daten beschäftigen, gibt es auch Eigenschaften, die im Hinblick auf Supply-Chain-Anforderungen interessant sein könnten. Was ist zum Beispiel mit der Beschränkung des akzeptablen Zeitraums? Wir könnten sagen, dass Daten außerhalb des Bereichs von 20 Jahren in der Vergangenheit und 20 Jahren in die Zukunft einfach ungültig sind. Die Wahrscheinlichkeit ist groß, dass, wenn wir eine Planungsoperation durchführen und an einem Punkt im Programm ein Datum manipulieren, das mehr als 20 Jahre in die Zukunft liegt, die Chancen überwältigend sind, dass es sich nicht um eine gültige Planungssituation für die meisten Branchen handelt. In den meisten Fällen plant man keine täglichen Operationen mehr als 20 Jahre im Voraus. Daher können wir nicht nur die üblichen Typen verwenden, sondern sie auch so neu definieren, dass sie restriktiver und für Supply-Chain-Zwecke angemessener sind.
Außerdem gibt es den Aspekt der Unsicherheit. Im Supply-Chain-Management schauen wir immer nach vorne, aber leider ist die Zukunft immer unsicher. Der mathematische Weg, Unsicherheit zu erfassen, besteht darin, Zufallsvariablen zu verwenden. Es würde Sinn machen, Zufallsvariablen in die Sprache zu integrieren, um unsichere zukünftige Nachfrage, Durchlaufzeiten und Kundenrückgaben sowie andere Dinge darzustellen.
Bei Lokad haben wir Envision entwickelt, eine Programmiersprache, die der prädiktiven Optimierung von Supply Chains gewidmet ist. Envision ist eine Mischung aus SQL, Python, mathematischer Optimierung, maschinellem Lernen und Big-Data-Fähigkeiten, die alle als First-Class-Citizens in der Sprache selbst integriert sind. Diese Sprache wird mit einer webbasierten integrierten Entwicklungsumgebung (IDE) geliefert, was bedeutet, dass Sie ein Skript aus dem Web schreiben und alle modernen Code-Editing-Funktionen haben können. Diese Skripte arbeiten über ein integriertes verteiltes Dateisystem, das mit der Lokad-Umgebung geliefert wird, sodass die Datenebene vollständig in die Programmiersprache integriert ist.
Envision-Skripte werden auf einer Flotte von Maschinen ausgeführt, die darauf ausgelegt sind, die gesamte Cloud zu nutzen. Wenn das Skript ausgeführt wird, verteilt es sich auf viele Maschinen, um schneller ausgeführt zu werden. Auf dem Bildschirm sehen Sie die Compiler-Pipeline, die von Envision verwendet wird. Heute werden wir nicht über diese Programmiersprache diskutieren, sondern nur über ihre Compiler-Pipeline, denn das ist das Thema des heutigen Vortrags.
Zunächst beginnen wir mit einem Text, der das Envision-Skript enthält. Es repräsentiert ein Programm, das von einem Supply Chain-Experten und nicht von einem Softwareingenieur geschrieben wurde, um eine bestimmte Supply Chain-Herausforderung anzugehen. Diese Herausforderung könnte darin bestehen, zu entscheiden, was produziert, aufgefüllt, verschoben oder ob der Preis angepasst werden soll. Diese Anwendungsfälle beinhalten Entscheidungen darüber, was produziert, aufgefüllt, verschoben oder ob Preise angepasst werden sollen. Der Text des Skripts enthält die Anweisungen und die Idee besteht darin, dieses Skript zu verarbeiten und den Lossless Syntax Tree (LST) zu erhalten. Der LST ist interessant, weil er eine sehr spezifische Darstellung ist, die kein einziges Zeichen verwirft. Selbst nicht signifikante Leerzeichen werden beibehalten. Der Grund dafür ist, sicherzustellen, dass automatisierte Umformungen des Programms den vorhandenen Code nicht verändern. Dieser Ansatz vermeidet Situationen, in denen Tools Code umsortieren, Einrückungen verschieben oder andere Störungen verursachen, die den Code schwer erkennbar machen.
Eine grundlegende Refaktorisierungsoperation könnte zum Beispiel das Umbenennen einer Variablen und aller ihrer Vorkommen im Programm ohne Berührung anderer Elemente beinhalten. Vom LST gehen wir zum Abstract Syntax Tree (AST) über, wo wir den Baum vereinfachen. Klammern sind in diesem Stadium nicht erforderlich, da die Baumstruktur die Prioritäten aller Operationen definiert. Darüber hinaus führen wir eine Reihe von Desugaring-Operationen durch, um jegliche Syntax zu entfernen, die dem Endprogrammierer zugute kommt.
Vom AST gehen wir zum Abstract Syntax Graph (ASG) über, wo wir den Baum abflachen. Dieser Prozess beinhaltet die Zerlegung komplexer Anweisungen mit stark verschachtelten Ausdrücken in eine Sequenz elementarer Anweisungen. Zum Beispiel würde eine Anweisung wie “a = b + c + d” in zwei Anweisungen aufgeteilt, von denen jede nur eine Addition enthält. Genau das passiert während des Übergangs vom AST zum ASG.
Vom ASG gehen wir zum Optimization Graph (OG) über, wo wir Typformung und Broadcasting durchführen, insbesondere in Bezug auf relationale Algebra. Wie bereits erwähnt, enthält Envision eine relationale Algebra innerhalb der Sprache. Wie bereits mehrmals angedeutet, enthält Envision eine relationale Algebra, ähnlich wie in relationalen Datenbanken oder SQL-Datenbanken, als First-Class-Citizen. Es gibt zahlreiche relationale Operationen und wir überprüfen, ob diese relationalen Operationen gemäß dem Schema der Tabellen, mit denen wir arbeiten, gültig sind, wenn wir vom ASG zum OG übergehen. Der Optimization Graph (OG) stellt den letzten Schritt unseres Compiler-Front-Ends dar und besteht aus reinen, elementaren relationalen Operationen, die auf das Programm angewendet werden und winzige Logikteile darstellen. Wie in SQL sind diese Elemente relationaler Natur.
Der Optimierungsgraph wird “Optimierung” genannt, weil es zahlreiche Transformationen gibt, die von OG zu OG stattfinden. Diese Transformationen erfolgen, weil bei der Arbeit mit relationaler Algebra das Organisieren von Operationen auf bestimmte Weise das Programm viel schneller ausführen kann. Zum Beispiel ist es in SQL viel besser, zuerst die Daten zu filtern und dann die Operation anzuwenden oder zuerst die Operation und dann den Filter anzuwenden. Dadurch wird sichergestellt, dass Operationen nur auf den erforderlichen Daten angewendet werden und die Effizienz verbessert wird.
Bei Lokad ist der letzte Schritt des Front-End-Compilers die High Intermediate Representation (HIR). Die HIR ist eine saubere, stabile und dokumentierte Grenze zwischen dem Front-End und dem Back-End der Compiler-Pipeline. Im Gegensatz zum Optimization Graph (OG), der aufgrund von Heuristiken ständig wechselt, ist die HIR stabil und liefert eine konsistente Eingabe für das Back-End des Compilers. Darüber hinaus ist die HIR serialisierbar, dh sie kann problemlos in ein Byte-Pack umgewandelt werden, um von einer Maschine auf eine andere verschoben zu werden. Diese Eigenschaft ist für die Verteilung von Berechnungen über mehrere Maschinen unerlässlich.
Von der High Intermediate Representation aus gehen wir zu “funcs” über. Funcs sind Werte, die noch ausgewertet werden müssen und die atomaren Berechnungsblöcke innerhalb einer verteilten Ausführung darstellen. Wenn zum Beispiel zwei gigantische Vektoren aus einer Tabelle mit Milliarden von Zeilen addiert werden, gibt es eine Reihe von funcs, die verschiedene Teile dieser Vektoren repräsentieren. Jede func ist dafür verantwortlich, einen Teil der beiden Vektoren zu addieren und wird auf einer Maschine ausgeführt. Große Berechnungen werden in viele funcs aufgeteilt, um die Arbeitslast auf mehrere CPUs und mehrere Maschinen zu verteilen, wenn die Berechnung groß genug ist, um diesen Grad der Verteilung zu rechtfertigen. Funcs werden “lazy” genannt, weil sie anfangs nicht ausgewertet werden; sie werden ausgewertet, wenn sie benötigt werden. Viele Berechnungen können durchgeführt werden, bevor einige funcs tatsächlich berechnet werden, und sobald eine func berechnet wird, wird die func selbst durch ihr Ergebnis ersetzt.
Innerhalb der func finden Sie die Low Intermediate Representation, die die imperative Low-Level-Logik darstellt, die innerhalb der func ausgeführt wird. Sie kann zum Beispiel Schleifen und Wörterbuchzugriffe enthalten. Schließlich wird diese Low-Level Intermediate Representation in Bytecode kompiliert, der das Endziel unserer Compiler-Pipeline darstellt. Bei Lokad zielen wir auf den .NET-Bytecode ab, der technisch als MSIL bekannt ist.
Aus Sicht der Supply Chain ist es wirklich interessant, dass wir durch diese möglicherweise komplexe Compiler-Pipeline den Grad der Integration reproduzieren, der in Microsoft Excel zu finden ist. Die Sprache ist mit der Datenebene und der UI/UX-Ebene integriert, sodass Benutzer die Ausgaben des Programms sehen und damit interagieren können, genauso wie sie es mit einer Excel-Tabelle tun würden. Im Gegensatz zu Excel tauchen wir jedoch in viel interessantere Gebiete des Supply Chain Managements ein, indem wir relationale Konzepte als Bürger erster Klasse sowie mathematische Optimierung und maschinelles Lernen nutzen.
Sowohl die mathematische Optimierung als auch das maschinelle Lernen in dieser Pipeline durchlaufen die gesamte Pipeline, anstatt nur eine Bibliothek aufzurufen, die irgendwo liegt. Das Vorhandensein von maschinellem Lernen als Bürger erster Klasse in der Pipeline ermöglicht verständlichere Fehlermeldungen, was einen großen Unterschied in Bezug auf die Produktivität für Supply Chain-Experten ausmacht.
Als abschließendes Thema zielen Compiler heutzutage fast immer auf eine virtuelle Maschine ab, aber diese virtuellen Maschinen werden wiederum auf eine andere virtuelle Maschine kompiliert. Auf dem Bildschirm sind die typischen VM-Ebenen in einer serverbasierten Umgebung sehr ähnlich wie bei einem Envision-Skript. Ich habe gerade die Compiler-Pipeline vorgestellt, aber grundsätzlich wäre es ziemlich dasselbe Stack, wenn wir über ein Python-Skript oder eine Excel-Tabelle nachdenken würden, die von einem Server aus betrieben wird. Bei der Gestaltung eines Compilers wählen Sie im Wesentlichen die Ebene aus, auf der Sie den Code einfügen möchten. Je tiefer die Ebene, desto mehr technische Details müssen berücksichtigt werden. Bei der Auswahl der Ebene müssen eine Reihe von Anliegen berücksichtigt werden.
Zuerst gibt es die Sicherheit. Wie schützen Sie Ihren Speicher und was sollte oder sollte das Programm nicht zugreifen? Wenn Sie eine generische Programmiersprache haben, sind Ihre Möglichkeiten begrenzt. Möglicherweise müssen Sie auf der Ebene des Gastbetriebssystems arbeiten, obwohl auch das möglicherweise nicht sehr sicher ist. Es gibt Möglichkeiten zur Sandbox, aber es ist sehr heikel, sodass Sie möglicherweise sogar noch weiter gehen müssen.
Zweitens gibt es die Frage der Low-Level-Funktionen, an denen Sie interessiert sind. Dies könnte zum Beispiel wichtig sein, wenn Sie eine leistungsfähigere Ausführung erreichen möchten, um die Menge der für Ihr Programm benötigten Rechenressourcen zu reduzieren. Sie können sich entscheiden, ausreichend niedrig zu gehen, um den Speicher und die Threads zu verwalten. Mit dieser Leistung kommt jedoch die Verantwortung, den Speicher und die Threads tatsächlich zu verwalten.
Drittens gibt es Komfortfunktionen wie Garbage Collection, Stack Trace, Debugger und Profiler. In der Regel ist die Instrumentierung rund um den Compiler komplexer als der Compiler selbst. Die Menge der Komfortfunktionen, von denen Sie profitieren, sollte nicht unterschätzt werden.
Viertens gibt es Bedenken hinsichtlich der Ressourcenzuweisung. Wenn Sie mit einer Excel-Tabelle auf Ihrem Desktop arbeiten, kann Excel alle Rechenressourcen in Ihrer Workstation verbrauchen. Bei Envision oder SQL haben Sie jedoch mehrere Benutzer zu bedienen und müssen entscheiden, wie Sie die Ressourcen zuweisen möchten. Darüber hinaus müssen Sie bei Envision nicht nur mehrere Benutzer, sondern auch mehrere Unternehmen bedienen, da Lokad mehrmandantenfähig ist. Dies ergibt Sinn in der Supply Chain, da der Bedarf an Rechenressourcen für die meisten Supply Chains sehr intermittierend ist.
In der Regel benötigen Sie nur eine sehr intensive Rechenleistung für etwa eine halbe Stunde oder vielleicht eine Stunde und dann nichts für die nächsten 23 Stunden. Dann wiederholen Sie dies täglich. Wenn Sie Hardware-Rechenressourcen einem Unternehmen zuweisen würden, blieben diese Ressourcen 90% der Zeit oder sogar noch länger ungenutzt. Daher möchten Sie die Arbeitslast auf viele Maschinen und über viele Unternehmen verteilen können, möglicherweise Unternehmen, die in verschiedenen Zeitzonen tätig sind.
Schließlich gibt es die Frage des Ökosystems. Die Idee ist, dass es recht bequem ist, Ihren Compiler mit allem zu integrieren und zu verbinden, was auch auf die genau gleichen virtuellen Maschinen abzielt, wenn Sie sich für eine bestimmte Ebene und eine bestimmte VM entscheiden. Dies wirft die Frage des Ökosystems auf: Was können Sie auf derselben Ebene wie das von Ihnen anvisierte finden, um das Rad nicht für jedes einzelne Detail in Ihrem gesamten Stack neu zu erfinden? Dies ist die letzte und wichtige Frage.
Abschließend gratuliere ich den glücklichen Wenigen, die es bis hierher in dieser Reihe von Supply-Chain-Vorlesungen geschafft haben. Dies ist wahrscheinlich eine der technischsten Vorlesungen bisher. Compiler sind zweifellos ein sehr technisches Stück; die Realität moderner Lieferketten ist jedoch, dass alles durch eine Programmiersprache vermittelt wird. Es gibt keine rohe, direkt beobachtbare Lieferkette mehr. Die einzige Möglichkeit, eine Lieferkette zu beobachten, besteht darin, die elektronischen Aufzeichnungen zu vermitteln, die von allen Teilen der Unternehmenssoftware erstellt werden, die die Anwendungslandschaft bilden. Daher ist eine Programmiersprache erforderlich, und standardmäßig ist diese Programmiersprache Excel.
Wenn wir jedoch besser als Excel sein wollen, müssen wir uns genau überlegen, was “besser” aus Sicht der Lieferkette bedeutet und was es in Bezug auf Programmiersprachen bedeutet. Wenn ein Unternehmen nicht die richtige Strategie oder Kultur hat, wird keine Technologie es retten. Wenn jedoch die Strategie und Kultur solide sind, dann ist die Werkzeugausstattung wirklich wichtig. Die Werkzeugausstattung, einschließlich Programmiersprachen, bestimmt Ihre Fähigkeit zur Ausführung, die Produktivität, die Sie von Ihren Supply-Chain-Experten erwarten können, und die Leistung, die Sie aus Ihrer Lieferkette erhalten, wenn Sie die Makrostrategie in die Tausende von alltäglichen Entscheidungen umsetzen müssen, die Ihre Lieferkette treffen muss. Die Fähigkeit, die Angemessenheit der Werkzeuge, einschließlich der Programmiersprachen, die Sie zur Bewältigung von Herausforderungen in der Lieferkette verwenden möchten, zu bewerten, ist von größter Bedeutung. Wenn Sie nicht in der Lage sind, zu bewerten, handelt es sich nur um einen vollständigen Kult des Frachtverkehrs.
Die nächste Vorlesung wird sich mit Softwaretechnik befassen. Heute haben wir über die Werkzeugausstattung gesprochen, aber nächstes Mal werden wir über die Menschen sprechen, die die Werkzeuge verwenden, und welche Art von Teamarbeit erforderlich ist, um die Arbeit gut zu erledigen. Die Vorlesung findet am gleichen Wochentag, Mittwoch, um 15 Uhr Paris Zeit statt.
Jetzt werde ich mir die Fragen ansehen.
Frage: Bei der Auswahl von Software für Lieferketten, wie können Unternehmen, die nicht technikversiert sind, beurteilen, ob der Compiler und die Programmierung für ihre Bedürfnisse geeignet sind?
Nun, ich bin ziemlich sicher, dass ein typisches Unternehmen, das eine typische Lieferkette betreibt, nicht die Qualifikationen hat, um ein Fahrzeug zu entwickeln. Dennoch schaffen sie es, Lastwagen zu kaufen, die für ihre Lieferkette und ihre Transportanforderungen angemessen sind. Es liegt nicht daran, dass Sie kein Experte sind und nicht in der Lage sind, einen Lastwagen neu zu bauen und umzugestalten, dass Sie keine sehr fundierte Meinung darüber haben können, ob es ein guter Lastwagen für Ihre Transportbedürfnisse ist. Also, ich sage nicht, dass Unternehmen, die nicht technikversiert sind, einen unglaublichen Sprung nach vorne machen sollten und plötzlich Experten im Design von Compilern werden sollten. Ich glaube jedoch, dass wir in nur anderthalb Stunden ziemlich viel abgedeckt haben. Mit weiteren 10 Stunden einer detaillierteren und langsameren Einführung würden Sie alles lernen, was Sie jemals über die Sprachgestaltung für Lieferkettenzwecke wissen müssen.
Es gibt einen Unterschied zwischen einem Experten zu sein und so unglaublich unwissend zu sein, dass Ihnen jemand einen Roller als Lastwagen verkaufen kann. Wenn wir diese Art von Unwissenheit, die ich im Hinblick auf das Design von Unternehmenssoftware beobachtet habe, auf die Automobilindustrie übertragen würden, würden die Leute behaupten, dass ein Roller ein Sattelschlepper ist und umgekehrt, und damit durchkommen.
Diese Vorlesungsreihe behandelt Hilfswissenschaften, daher besteht keine Absicht, dass Personen, die Supply Chain-Praktiker werden möchten, in diesen Bereichen Experten werden. Dennoch können Sie mit grundlegendem Wissen sehr weit kommen, um zu bewerten. Die meiste Zeit müssen Sie nur genug Wissen haben, um schwierige Fragen zu stellen. Wenn der Anbieter Ihnen eine unsinnige Antwort gibt, sieht das nicht gut aus. Wenn Sie nicht einmal wissen, welche technischen Fragen Sie stellen sollen, können Sie getäuscht werden.
Mein Vorschlag ist, dass Sie nicht unglaublich technikversiert sein müssen; Sie müssen nur versiert genug sein, um ein Einsteiger-Amateur zu sein, der Lücken aufdecken und beurteilen kann, ob das Ganze auseinanderfällt oder ob tatsächlich Substanz dahinter steckt. Das Gleiche gilt für mathematische Optimierung, maschinelles Lernen, CPUs und so weiter. Die Idee ist, genug zu wissen, um zwischen etwas Betrügerischem und etwas Legitimem zu unterscheiden.
Frage: Haben Sie das Problem mit bestehenden Programmiersprachen, die nicht für die Lieferkette entwickelt wurden, direkt angesprochen?
Das ist eine sehr gute Frage. Das Entwickeln einer brandneuen Programmiersprache mag völlig verrückt erscheinen. Warum nicht einfach etwas bereits etabliertes wie Python verwenden und die kleinen Modifikationen einbringen, die wir benötigen? Das wäre eine Option gewesen. Das Problem ist jedoch nicht wirklich, was wir diesen Sprachen hinzufügen müssen, sondern was wir entfernen müssen.
Mein Hauptanliegen bei Python ist nicht, dass es keine probabilistische Algebra hat oder dass es keine relationale Algebra eingebaut hat. Meine Hauptkritik ist, dass es eine vollständig fähige, generische Programmiersprache ist und somit der Person, die den Code schreibt, alle möglichen Konzepte aussetzt, wie objektorientierte Programmierung für Python, die für die Lieferkette völlig belanglos sind. Das Problem bestand nicht so sehr darin, eine Sprache zu nehmen und etwas hinzuzufügen, sondern eine Sprache zu nehmen und versuchen, tonnenweise Dinge zu entfernen. Das Problem ist jedoch, dass sobald Sie Dinge aus einer vorhandenen Programmiersprache entfernen, alles kaputt geht.
Zum Beispiel wurde die erste Version von Python im Jahr 1990 veröffentlicht, also ist es eine 30 Jahre alte Programmiersprache. Die Menge an Code in einem beliebten Stapel wie Python ist absolut gigantisch, und das aus gutem Grund. Ich kritisiere es nicht; es ist ein sehr solider Stapel, aber auch ein enormer. Also haben wir am Ende verschiedene Optionen bewertet: eine Programmiersprache nehmen, tonnenweise Dinge abziehen, bis wir mit dem zufrieden sind, was wir haben, oder berücksichtigen, dass all diese Programmiersprachen ihre eigenen Altlasten haben.
Wir haben bewertet, wie viel Aufwand es war, eine brandneue Sprache zu erstellen, und am Ende sprach sehr viel dafür, eine neue Sprache zu erstellen. Die Entwicklung einer neuen Programmiersprache ist ein etabliertes Gebiet, also ist es, obwohl es unglaublich klingen mag, nicht so. Es gibt Hunderte von Büchern, die Ihnen Rezepte geben, und es ist jetzt sogar für Informatikstudenten zugänglich. Es gibt sogar Professoren in Informatikabteilungen, die ihren Studenten in einem Semester die Aufgabe geben, einen Compiler für eine neue Programmiersprache zu erstellen.
Am Ende haben wir beschlossen, dass die Lieferketten groß genug sind, um einen dedizierten Aufwand zu rechtfertigen. Ja, Sie können immer Dinge wiederverwenden, die nicht für Lieferketten entwickelt wurden, aber Lieferketten sind eine weltweite, massive Industrie und ein Satz von Problemen. Also dachten wir, angesichts des Maßstabs, den wir betrachten, macht es Sinn, das Richtige zu tun und etwas direkt für die Lieferkette zu erstellen, anstatt zufällig zu recyceln.
Frage: Für die Optimierung der Lieferkette ist Envision geeignet, da es SQL, Python usw. umfasst. Wie können Sie jedoch den Compiler und die Programmiersprache für WMS, ERP, bewerten, bei denen der Prozessfluss wichtiger ist als die mathematische Optimierung?
Das ist eine sehr gute Frage. Ich habe persönlich mit der Idee gespielt, dass es Akteure in dieser Branche gibt, die tatsächlich eigene Programmiersprachen entwickelt haben, nur um etwas vollständig transaktionales, workfloworientiertes zu implementieren. Die Lieferkette, so wie ich sie sehe, geht im Wesentlichen um vorausschauende Optimierung. Herr Nannani hat jedoch völlig recht; was ist mit dem gesamten Managementbereich, wie ERP, WMS usw.?
Es stellt sich heraus, dass es viele Unternehmen in diesem Bereich gibt, die ihre eigene Programmiersprache entwickelt haben. Ich habe SAP erwähnt, das ABAP hat, das genau dafür entwickelt wurde. Leider ist ABAP meiner Meinung nach nicht sehr gut gealtert. Es gibt viele Dinge in ABAP, die im 21. Jahrhundert nicht wirklich Sinn ergeben. Man kann wirklich sehen, dass dieses Ding 1983 entworfen wurde, und das merkt man. Zum Beispiel hat das ERP von Microsoft Dynamics eine eigene Programmiersprache. Dynamics AX hat seine eigene Programmiersprache, und es gibt viele ERP-Projekte, die in großem Umfang ihre eigene Programmiersprache mitbringen. Also existiert es.
Sind diese Sprachen wirklich der Höhepunkt dessen, was wir in Bezug auf moderne, hochmoderne Programmiersprachen im Jahr 2021 tun können? Ich glaube nicht, und das ist auch das Problem, von dem ich gesprochen habe: Unternehmenssoftwareanbieter erfinden immer wieder Programmiersprachen, aber in der Regel machen sie dabei einen sehr schlechten Job. Es ist einfach eine planlose Ingenieursarbeit. Sie nehmen sich nicht einmal die Zeit, die vielen Bücher zu lesen, die auf dem Markt erhältlich sind, und dann gibt es arme Ingenieure, die mit einem Haufen Mist feststecken.
Zurück zu Ihrer Frage, ich habe mit dem Gedanken gespielt, dass Lokad in diesem Bereich tätig wird und eine Sprache entwickelt, die nicht für die Optimierung, sondern für die Unterstützung des Workflows konzipiert ist. An diesem Punkt ist das Wachstum von Lokad jedoch so groß, dass wir uns nicht abspalten und uns mit den Workflows befassen können. Ich bin absolut sicher, dass dies genau richtig ist und dass neue Akteure entstehen werden, die einen sehr guten Job für den Managementteil des Problems machen werden. Lokad kümmert sich nur um den Optimierungsteil der Lieferketten; es gibt auch den Managementteil.
Frage: Python wird derzeit als Standardprogrammiersprache angesehen. Gibt es laufende Entwicklungen auf dem Markt?
Das ist eine sehr gute Frage. Wenn mir Leute “die Standards” nennen, bin ich schon lange genug dabei, um zu sehen, wie Standards kommen und gehen. Ich bin nicht sehr alt, aber als ich auf der High School war, war der Standard C++. In den 90er Jahren war C++ der Standard. Warum sollte man es anders machen? Dann kam um das Jahr 2000 Java und die Kombination aus Java und XML war der Standard.
Die Leute sagten sogar, dass die Universitäten zu dieser Zeit zu “Java-Schulen” geworden waren. Das war wörtlich der Begriff des Tages um das Jahr 2000 herum; die Leute sagten: “Das ist keine Informatikuniversität mehr, das ist nur noch eine Java-Schule.” Ein paar Jahre später, als ich Lokad gründete, war die Programmiersprache für alles, was mit Statistik zu tun hatte, immer noch R. Python war immer noch sehr marginal und R dominierte das Feld in Bezug auf statistische Analysen absolut.
Mit dem Fortschritt der Programmiersprachen ist C++ in den Hintergrund getreten. Microsoft führte 2002 C# und die .NET-Plattform ein, die einen erheblichen Teil des C++-Ökosystems kannibalisierte. Ein großer Teil der C++-Entwickler weltweit war bei Microsoft, einem sehr großen Unternehmen. Der Punkt, den ich anspreche, ist, dass es eine fortlaufende Entwicklung gegeben hat und dass jedes Jahr die Leute dies als Standard betrachten, aber dieser Standard ändert sich ständig.
JavaScript existierte seit 20 Jahren, aber es war nichts Bedeutendes. Dann wurde um 2009 oder 2012 ein Buch mit dem Titel “JavaScript: The Good Parts” veröffentlicht, das zeigte, dass JavaScript nicht völlig verrückt war. Man konnte JavaScript für ein echtes Projekt verwenden, ohne den Verstand zu verlieren; man musste sich nur an die guten Teile halten. Plötzlich war JavaScript der letzte Schrei und die Leute begannen, es serverseitig mit einem System namens Node.js zu verwenden.
Python ist erst vor einigen Jahren in den Vordergrund gerückt, nachdem die Python-Community ein mühsames Upgrade von Version 2.7 auf Version 3.x durchlaufen hatte. Am Ende dieses Upgrades wurde das Interesse an Python erneuert. Es gibt jedoch viele Gefahren, die Python bevorstehen. Es ist keine sehr gute Sprache nach den Standards des 21. Jahrhunderts. Es ist eine 30 Jahre alte Sprache und man merkt ihr ihr Alter an. Wenn man etwas Besseres in jeder Dimension außer Reife haben möchte, könnte man sich Julia ansehen. Julia ist in fast jeder Hinsicht Python für Data Science überlegen, außer in Bezug auf Reife, wo Julia noch Jahre hinterherhinkt.
Es gibt viele laufende Entwicklungen und es ist leicht, den Zustand der Branche für etwas zu halten, das ein Standard sein soll, der Bestand hat. Zum Beispiel gab es im Apple-Ökosystem Objective-C und dann entschied sich Apple, Swift als Ersatz zu produzieren, das jetzt Objective-C ersetzt. Die Programmiersprachenlandschaft entwickelt sich immer noch sehr stark und obwohl es Zeit braucht, werden wir in zehn Jahren wahrscheinlich eine signifikante Entwicklung sehen. Python wird möglicherweise nicht als dominierende Programmiersprache hervorgehen, da es viele konkurrierende Optionen gibt, die bessere Antworten liefern.
Frage: Lebensmittelunternehmen und E-Commerce-Startups denken oft, dass sie den Kampf mit Data-Science-Teams und allgemeinen Programmiersprachen gewinnen können. Was wäre Ihr wichtigstes Verkaufsargument, um sie dazu zu bringen, diesen Ansatz zu überdenken und zu erkennen, dass sie etwas spezifischeres für ihre Probleme benötigen?
Wie gesagt, das ist das Problem des Dunning-Kruger-Effekts. Man gibt einem Softwareingenieur ein Mixed-Integer-Linear-Programming-System zur ganzzahligen Programmierung und eine Woche später denkt diese Person, sie sei plötzlich ein Experte für diskrete Optimierung geworden. Also, wie gewinne ich den Kampf? Um ehrlich zu sein, gewinnen wir ihn normalerweise nicht. Was ich tue, ist, den Weg zu beschreiben, auf dem sich die Katastrophen entfalten werden.
Es ist einfach, wenn man mit generischen Technologieblöcken fantastische Prototypen erstellt. Diese Prototypen funktionieren aufgrund der Star-Wars-Illusion brillant - man hat nur seine Technologie in Isolation. Wenn diese Unternehmen versuchen, diese Dinge in die Produktion zu bringen, werden sie meistens aufgrund sehr banaler Probleme kämpfen. Sie werden mit fortlaufenden Integrationsproblemen konfrontiert sein, nicht wie Google oder Microsoft oder Amazon, die es sich leisten können, tausend Ingenieure zu haben, die sich um die gesamte Infrastruktur kümmern.
TensorFlow zum Beispiel ist eine Herausforderung bei der Integration. Google hat die 1000 Ingenieure, die erforderlich sind, um TensorFlow in ihre Datenpipelines und Anwendungen für ihre Zwecke einzubinden. Aber die Frage ist, können Startups oder E-Commerce-Unternehmen es sich leisten, so viele Mitarbeiter für die gesamte Infrastruktur zu haben? In der Regel lautet die Antwort nein. Die Leute stellen sich vor, dass sie nur diese Tools auswählen müssen, um Dinge auszuwählen und sie zusammenzusetzen, und magischerweise funktioniert es. Aber das ist nicht der Fall. Es erfordert eine enorme Menge an Ingenieurarbeit.
Übrigens leiden einige Anbieter von Unternehmenssoftware unter dem genau gleichen Problem. Sie haben viel zu viele Komponenten in ihrer Lösung, und das erklärt, warum die Bereitstellung einer Lösung, ohne jegliche Anpassung, bereits Monate dauert, weil es so viele instabile Teile im System gibt, die nur lose integriert sind. Es wird sehr schwierig.
Ich denke, das war die letzte Frage. Bis zum nächsten Mal.
