Langages et compilateurs pour la supply chain - Cours 4.5

00:05 Introduction
02:50 Deux illusions
09:09 Un pipeline de compilation
14:23 L’histoire jusqu’à présent
18:49 Connaissement
19:40 Conception de langage
23:52 Le futur
30:35 Le passé
35:57 Choisir les combats
39:45 Grammaires 1/3
42:41 Grammaires 2/3
49:02 Grammaires 3/3
53:02 Analyse statique 1/2
58:50 Analyse statique 2/2
01:04:55 Système de types
01:11:59 Internes du compilateur
01:27:48 Environnement d’exécution
01:33:57 Conclusion
01:36:33 Prochain cours et questions du public

Description

La majorité des supply chains sont encore gérées via des feuilles de calcul (c’est-à-dire Excel), alors que des systèmes d’entreprise sont en place depuis un, deux, voire trois décennies - censés les remplacer. En effet, les feuilles de calcul offrent une expressivité programmatique accessible, tandis que ces systèmes ne le font généralement pas. Plus généralement, depuis les années 1960, il y a eu un développement constant de l’industrie du logiciel dans son ensemble et de ses langages de programmation. Il existe des preuves que la prochaine étape de la performance de la supply chain sera largement influencée par le développement et l’adoption de langages de programmation, ou plutôt d’environnements programmables.

Transcription complète

Bienvenue dans cette série de cours sur la supply chain. Je suis Joannes Vermorel et aujourd’hui je vais présenter “Langages et compilateurs pour la supply chain”. Je ne me souviens pas avoir déjà vu des compilateurs discutés dans un manuel de supply chain, et pourtant le sujet est d’une importance primordiale. Nous avons vu dans le tout premier chapitre de cette série, dans le cours intitulé “Livraison orientée produit”, que la programmation est la clé pour capitaliser sur le temps investi par les experts de la supply chain. Sans programmation, nous ne pouvons pas capitaliser sur leur temps et nous traitons les experts de la supply chain comme des personnes interchangeables.

De plus, dans ce quatrième chapitre même, à travers les deux cours précédents “Optimisation mathématique pour la supply chain” et “Apprentissage automatique pour la supply chain”, nous avons vu que ces deux domaines - l’optimisation et l’apprentissage - sont devenus guidés par des paradigmes de programmation au cours de la dernière décennie, au lieu de rester un ensemble d’algorithmes et de modèles comme c’était le cas par le passé. Tous ces éléments soulignent l’importance primordiale des langages de programmation, et cela soulève donc la question d’un langage de programmation et d’un compilateur conçus pour répondre aux défis de la supply chain.

Le but de ce cours est de démystifier la conception d’un tel langage de programmation destiné à la supply chain. Votre entreprise ne va probablement jamais concevoir un tel langage de programmation. Néanmoins, avoir une certaine compréhension du sujet est fondamental pour être en mesure d’évaluer l’adéquation des outils que vous avez et l’adéquation des outils que vous avez l’intention d’acquérir afin de relever les défis de la supply chain auxquels votre entreprise est confrontée. De plus, ce cours devrait également vous aider à éviter certaines des grandes erreurs que les personnes qui n’ont aucune connaissance de ce sujet ont tendance à commettre dans ce domaine.

Commençons par dissiper deux illusions qui ont prévalu dans les cercles des logiciels d’entreprise depuis les trois dernières décennies environ. La première est l’illusion de la “programmation Lego”, où la programmation est considérée comme quelque chose qui peut être entièrement contourné. En effet, la programmation est difficile, et il y a toujours des fournisseurs qui promettent que grâce à leur produit et à leur technologie fantastique, la programmation peut être transformée en une expérience visuelle accessible à tous, éliminant ainsi toute la difficulté de la programmation elle-même, de sorte que l’expérience devient essentiellement similaire à l’assemblage de Lego, quelque chose qu’un enfant peut faire.

Cela a été tenté d’innombrables fois au cours des deux dernières décennies et a toujours échoué invariablement. Au mieux, les produits destinés à offrir une expérience visuelle se sont transformés en langages de programmation réguliers qui ne sont pas particulièrement plus faciles à maîtriser par rapport à d’autres langages de programmation. C’est d’ailleurs anecdote la raison pour laquelle, par exemple, dans la série de produits Microsoft, il y a la série “Visual”, comme Visual Basic for Application et Visual Studio. Tous ces produits visuels ont été introduits dans les années 90 avec l’espoir de transformer la programmation en une expérience purement visuelle avec des concepteurs où il suffirait de faire glisser-déposer. La réalité est que tous ces outils ont finalement atteint un degré de succès très significatif, mais ce sont juste des langages de programmation assez réguliers de nos jours. Il ne reste plus grand-chose des parties visuelles qui étaient à l’origine de ces produits.

L’approche Lego a échoué parce que fondamentalement, le goulot d’étranglement n’est pas l’obstacle de la syntaxe de programmation. C’est un obstacle, mais c’est un obstacle minimal, surtout par rapport à la maîtrise des concepts qui sont impliqués chaque fois que vous voulez déployer n’importe quel type d’automatisation sophistiquée. Votre esprit devient le goulot d’étranglement, et votre compréhension des concepts en jeu est beaucoup plus importante que la syntaxe.

La deuxième illusion est l’illusion de la “technologie Star Wars”, qui consiste à penser qu’il est facile de brancher et d’utiliser des technologies fantastiques. Cette illusion est très attrayante pour les fournisseurs et les projets internes. Essentiellement, il devient très tentant de dire qu’il existe cette fantastique base de données NoSQL que nous pouvons simplement intégrer, ou qu’il existe cette fantastique pile d’apprentissage profond que nous pouvons utiliser, ou cette base de données graphique, ou ce framework actif distribué, etc. Le problème avec cette approche est qu’elle traite la technologie comme elle est traitée dans Star Wars. Lorsque vous avez une main mécanique, le héros peut simplement prendre la main mécanique et ça fonctionne. Mais en réalité, ce sont les problèmes d’intégration qui dominent.

Star Wars contourne le fait qu’il y aurait une série de problèmes : d’abord, vous auriez besoin d’antibiotiques, puis d’une longue rééducation de la main pour pouvoir l’utiliser. Vous auriez également besoin d’un programme de maintenance pour la main car elle est mécanique, et qu’en est-il de la source d’alimentation, etc. Tous ces problèmes sont simplement contournés. Vous branchez simplement la fantastique technologie et ça fonctionne. Ce n’est pas le cas dans la réalité. Ce sont les problèmes d’intégration qui dominent, et par exemple, dans les grandes entreprises de logiciels, la plupart des ingénieurs en logiciel ne travaillent pas sur des technologies fantastiquement cool. La majeure partie de la main-d’œuvre d’ingénierie de la grande majorité de ces grands fournisseurs de logiciels est dédiée à l’intégration de toutes les parties.

Lorsque vous avez des modules, des composants ou des applications, vous avez besoin d’une petite armée d’ingénieurs pour simplement assembler toutes ces choses et faire face à tous les problèmes qui surviennent lorsque vous essayez de les réunir. Même une fois que vous avez franchi tous les obstacles de l’intégration, vous avez encore besoin d’une grande main-d’œuvre d’ingénierie pour faire face au fait que lorsque vous modifiez une partie du système, vous avez tendance à créer des problèmes dans d’autres parties du système. Vous avez donc besoin de cette main-d’œuvre d’ingénierie pour résoudre ces problèmes.

Au fait, une autre problème que j’ai constaté avec des technologies cool est l’effet Dunning-Kruger qu’elles créent chez les ingénieurs. Vous introduisez une technologie cool dans votre pile, et soudainement les ingénieurs, simplement parce qu’ils ont commencé à jouer avec une technologie qu’ils comprennent à peine, pensent qu’ils sont soudainement des experts en IA ou quelque chose du genre. C’est un cas typique de l’effet Dunning-Kruger et est très fortement lié au nombre de technologies cool que vous intégrez dans votre solution. En conclusion, avec ces deux illusions, nous voyons que nous ne pouvons pas contourner le problème de la programmation. Nous devons l’aborder de manière fonctionnelle, y compris les parties difficiles.

Maintenant, cela étant dit, la chose intéressante à propos des langages de programmation est que les fournisseurs de logiciels d’entreprise réinventent accidentellement des langages de programmation tout le temps. En effet, dans la supply chain, il y a un besoin féroce de configurabilité. Comme nous l’avons vu dans les conférences précédentes, le monde de la supply chain est diversifié et les problèmes sont nombreux et variés. Ainsi, lorsque vous avez un produit logiciel de supply chain, il y a un besoin extrêmement intense de configurabilité. Anecdotiquement, c’est pourquoi la configuration d’un logiciel est généralement un projet de plusieurs mois, voire de plusieurs années. C’est parce qu’il y a une énorme complexité qui entre dans cette configuration.

Les paramètres de configuration sont souvent complexes, ce ne sont pas seulement des boutons ou des cases à cocher. Vous pouvez avoir des déclencheurs, des formules, des boucles et toutes sortes de blocs qui vont avec. Cela devient rapidement incontrôlable, et ce que vous obtenez à travers ces paramètres de configuration est un langage de programmation émergent. Cependant, étant donné que c’est un langage de programmation émergent, il a tendance à être très pauvre.

Concevoir un langage de programmation réel est une tâche d’ingénierie bien établie. Il existe des dizaines de livres sur les aspects pratiques de la conception d’un compilateur de qualité de production. Un compilateur est un programme qui convertit des instructions, généralement des instructions textuelles, en code machine ou en une forme d’instructions de niveau inférieur. Chaque fois qu’il y a un langage de programmation, il y a un compilateur impliqué. Par exemple, dans une feuille de calcul Excel, vous avez des formules, et Excel a son propre compilateur pour compiler ces formules et les exécuter. Il est très probable que l’ensemble du public utilise des compilateurs tout au long de sa carrière professionnelle sans le savoir.

Sur le diagramme, vous pouvez voir un pipeline typique, et cet archétype correspond à la plupart des langages de programmation dont vous avez probablement déjà entendu parler, tels que Python, JavaScript, Java et C#. Toutes ces langues ont un pipeline essentiellement similaire à celui décrit ici. Dans un pipeline de compilation, vous avez une série de transformations, et à chaque étape du processus, vous avez une représentation qui représente l’ensemble du programme. La façon dont un compilateur est conçu est d’avoir une série de transformations bien identifiées, et à chaque étape du processus, vous travaillez avec l’ensemble du programme. Il est simplement représenté différemment.

L’idée est que chaque transformation est responsable d’un ensemble de problèmes bien spécifiés. Vous résolvez ces problèmes, puis passez à la prochaine transformation qui abordera un autre aspect du processus. En général, à chaque étape, vous vous rapprochez du code de niveau machine. Le compilateur commence par le script, et il commence par des transformations qui sont très proches de la syntaxe du langage de programmation qui nous intéresse. Au cours de ces premières transformations, un compilateur typique détectera les erreurs syntaxiques qui empêchent le compilateur de transformer un script qui ne représente même pas un programme valide en quelque chose d’exécutable. Nous reviendrons plus tard dans cette conférence pour examiner de plus près un pipeline de compilation.

Cette conférence est la cinquième conférence du quatrième chapitre de cette série. Dans le premier chapitre, j’ai présenté mes points de vue sur la supply chain à la fois en tant que domaine d’étude et en tant que pratique. Dans le deuxième chapitre, j’ai étudié les méthodologies appropriées pour faire face aux situations rencontrées dans la supply chain. Comme nous l’avons vu, la plupart des situations de la supply chain sont assez adverses, nous avons donc besoin de stratégies et de méthodologies qui sont résilientes aux comportements adverses de toutes les parties au sein et en dehors des entreprises.

Le troisième chapitre est consacré au personnel de la supply chain, et il est entièrement dédié à l’étude des problèmes de la supply chain eux-mêmes. Nous devons être très prudents de ne pas mêler le problème que nous découvrons avec le type de solution que nous pouvons imaginer pour résoudre ce problème. Ce sont deux préoccupations distinctes : nous devons séparer le problème de la solution.

Le quatrième et présent chapitre de cette série de conférences est consacré aux sciences auxiliaires de la supply chain. Ces sciences auxiliaires ne sont pas la supply chain en soi, mais elles sont très utiles à la pratique de la supply chain moderne. Nous sommes actuellement en train de progresser dans l’échelle des abstractions. Nous avons commencé ce chapitre avec la physique de l’informatique, puis avec les algorithmes, nous sommes passés dans le domaine du logiciel. Nous avons introduit l’optimisation mathématique, qui présente un grand intérêt pour la supply chain et qui est également la base de l’apprentissage automatique.

Aujourd’hui, nous introduisons les langages et les compilateurs, essentiels pour mettre en œuvre tout type de paradigme de programmation. Bien que le sujet des langages et des compilateurs puisse surprendre le public, je pense qu’à ce stade, cela ne devrait pas être trop surprenant. Nous avons vu que l’optimisation mathématique et l’apprentissage automatique doivent aujourd’hui être abordés à travers des paradigmes de programmation, ce qui soulève la question de la manière de mettre en œuvre ces paradigmes de programmation. Cela nous amène à la conception d’un langage de programmation et de son compilateur de soutien, qui est précisément le sujet d’aujourd’hui.

Ceci est un résumé du reste de cette conférence. Nous commencerons par des observations de haut niveau sur l’histoire et le marché des langages de programmation. Nous passerons en revue des industries qui représentent, selon moi, à la fois l’avenir et le passé de la supply chain. Ensuite, nous nous plongerons progressivement dans la conception des langages de programmation et des compilateurs, en abordant des préoccupations de plus bas niveau et les aspects techniques liés à la conception d’un compilateur.

Depuis les années 1950, des milliers de langages de programmation ont été mis en production. Les estimations varient, mais le nombre de langages de programmation qui ont été utilisés à des fins de production se situe probablement entre mille et dix mille. Beaucoup de ces langages ne sont que des variations ou des cousins les uns des autres, parfois même simplement la base de code du compilateur bifurquée dans une direction légèrement différente. Il est notable que plusieurs très grandes entreprises de logiciels d’entreprise se sont considérablement développées grâce à l’introduction de langages de programmation qu’elles ont créés. Par exemple, SAP a introduit ABAP en 1983, Salesforce a introduit Apex en 2006, et même Microsoft a commencé avant Windows en concevant l’Altair BASIC en 1975.

Historiquement, ceux d’entre vous dans le public qui se souviennent des années 90 se rappelleront que les fournisseurs de l’époque faisaient la promotion de langages de programmation de troisième et quatrième génération. La réalité est qu’il y avait une série bien identifiée de générations - première, deuxième, troisième, quatrième, etc. - qui ont conduit à la cinquième, où essentiellement la communauté a cessé de compter en termes de générations. Au cours des trois ou quatre premières décennies, tous ces langages de programmation suivaient une progression agréable vers des niveaux d’abstraction plus élevés. Cependant, à la fin des années 90, il y avait déjà beaucoup plus de directions que simplement avoir un degré d’abstraction plus élevé, en fonction du cas d’utilisation.

La création d’un nouveau langage de programmation a été réalisée de nombreuses fois. C’est un domaine bien établi de l’ingénierie, et il existe des livres entiers dédiés à ce sujet d’un point de vue très pratique. L’ingénierie d’un nouveau langage de programmation est une pratique beaucoup plus concrète et prévisible que, disons, la réalisation d’une expérience de science des données. Il est presque certain que vous obtiendrez le résultat souhaité si vous faites l’ingénierie adéquate, en tenant compte de ce qui est connu aujourd’hui et de ce qui est facilement disponible en termes de connaissances.

Tout cela soulève vraiment la question : qu’en est-il d’un langage de programmation spécifiquement conçu pour les besoins de la supply chain ? En effet, il peut y avoir des avantages significatifs en termes de productivité, de fiabilité et même de performance de la supply chain.

Pour répondre à cette question, nous devons jeter un coup d’œil vers l’avenir. Heureusement pour nous, la manière la plus simple de regarder vers l’avenir est d’examiner une industrie qui a été systématiquement une décennie en avance sur tout le monde au cours des trois dernières décennies environ, à savoir l’industrie du jeu vidéo. Il s’agit aujourd’hui d’une très grande industrie, et juste pour vous donner une idée de l’échelle, l’industrie du jeu vidéo représente maintenant les deux tiers de l’industrie aérospatiale dans le monde en termes de taille comparative, et elle croît beaucoup plus rapidement que l’aérospatiale. Dans une décennie, les jeux vidéo pourraient même être plus importants que l’aérospatiale.

Ce qui est intéressant dans l’industrie du jeu vidéo, c’est qu’elle a une structure très bien établie. Tout d’abord, nous avons les moteurs de jeu, les deux leaders étant Unity et Unreal. Ces moteurs de jeu comprennent les composants de bas niveau qui sont intéressants pour des graphismes 3D raffinés super intensifs, et ils définissent le paysage pour le niveau d’infrastructure de votre code. Il existe quelques entreprises qui conçoivent des produits très complexes appelés moteurs de jeu, et ces moteurs sont utilisés par toute l’industrie.

Ensuite, nous avons les studios de jeu, qui développent le code du jeu pour chaque jeu. Le code du jeu va être une base de code qui est généralement spécifique au jeu en cours de développement. Le moteur de jeu nécessite des ingénieurs logiciels très pointus qui sont très techniquement compétents mais ne connaissent pas nécessairement grand-chose aux jeux. Le développement du code du jeu n’est pas aussi intensif en termes de compétences techniques brutes. Cependant, les ingénieurs logiciels qui développent le code du jeu doivent comprendre le jeu sur lequel ils travaillent. Le code du jeu établit la plateforme pour les mécanismes du jeu, mais il ne spécifie pas les détails précis.

Cette tâche est généralement gérée par des concepteurs de jeux, qui ne sont pas des ingénieurs logiciels, mais qui écrivent du code dans les langages de script qui leur sont mis à disposition par l’équipe d’ingénierie chargée du code du jeu. Nous avons ces trois étapes : les moteurs de jeu, qui impliquent des ingénieurs logiciels super techniques et pointus créant des blocs de construction de base ; les studios, qui ont des équipes d’ingénierie, généralement une par jeu, développant le jeu en tant que plateforme pour les mécanismes du jeu ; et enfin, les concepteurs de jeux, qui ne sont pas des ingénieurs logiciels mais sont des spécialistes des jeux, mettant en œuvre le comportement qui rendra les joueurs, les clients à la fin du processus, heureux.

De nos jours, le code du jeu est souvent rendu accessible à la base de fans, ce qui signifie que les concepteurs de jeux peuvent écrire des règles et potentiellement modifier le jeu, mais les fans, qui ne sont que des consommateurs réguliers des jeux, peuvent également le faire. Il y a des anecdotes intéressantes dans l’industrie. Par exemple, le jeu Dota 2, qui est incroyablement réussi, a commencé comme une modification d’un jeu existant. La première version, simplement appelée Dota, était une modification pure de la base de fans du jeu World of Warcraft 3. On peut voir que ce degré de configurabilité et de programmabilité au niveau des règles du jeu est très étendu car il était possible, à partir d’un jeu commercial existant, World of Warcraft 3, de créer un tout nouveau jeu, qui est ensuite devenu un énorme succès commercial grâce à la deuxième version. Maintenant, c’est intéressant, et nous pouvons commencer à réfléchir, en regardant l’industrie du jeu, à ce que cela signifie pour l’industrie de la supply chain.

Eh bien, nous pourrions réfléchir à quel genre de parallèle nous pourrions établir. Nous pourrions avoir un moteur de supply chain qui s’occupe des parties algorithmiques très difficiles, de l’infrastructure de bas niveau et des blocs de construction technologiques de base, tels que l’optimisation mathématique et l’apprentissage automatique. L’idée est que, pour chaque supply chain, vous auriez besoin d’une équipe d’ingénierie pour rassembler toutes les données pertinentes et intégrer l’ensemble du paysage applicatif.

Dans un premier temps, nous aurions besoin de l’équivalent des concepteurs de jeux, qui seraient des spécialistes de la supply chain. Ces spécialistes ne sont pas des ingénieurs logiciels, mais ce sont les personnes qui écriront, à travers un code simplifié, toutes les règles et mécanismes nécessaires pour mettre en œuvre l’optimisation prédictive d’intérêt pour la supply chain. L’industrie du jeu fournit un exemple vivant de ce qui est susceptible de se produire dans l’espace de la supply chain au cours de la prochaine décennie.

Jusqu’à présent, l’approche de l’industrie du jeu dans la supply chain relève de la science-fiction, à l’exception de quelques entreprises. Je crois que la plupart de ces entreprises se trouvent être des clients de Lokad. Revenons au sujet d’aujourd’hui, nous avons vu dans les conférences précédentes qu’Excel reste le langage de programmation numéro un dans cette industrie. En passant, en termes de langage de programmation, Excel est un langage de programmation réactif fonctionnel, donc il est même sa propre classe.

Vous entendez peut-être aujourd’hui des fournisseurs proposant de mettre à niveau les supply chains à l’aide d’une sorte de configuration de data science. Cependant, mon observation occasionnelle au cours de la dernière décennie est que la grande majorité de ces initiatives ont échoué. C’est déjà du passé, et pour comprendre pourquoi, nous devons commencer à regarder la liste des langages de programmation impliqués. Si nous regardons Excel, nous voyons qu’il implique essentiellement deux langages de programmation : les formules Excel et VBA. VBA n’est même pas une exigence ; vous pouvez aller loin avec seulement des VLOOKUP dans Excel. Typiquement, il n’y aura qu’un seul langage de programmation, et il est accessible aux non-ingénieurs logiciels.

D’autre part, la liste des langages de programmation nécessaires pour reproduire les fonctionnalités d’Excel avec une configuration de data science est assez étendue. Nous aurons besoin de SQL, et potentiellement de plusieurs dialectes de SQL, pour accéder aux données. Nous aurons besoin de Python pour implémenter la logique principale. Cependant, Python à lui seul a tendance à être lent, donc vous pourriez avoir besoin d’un sous-langage comme NumPy. À ce stade, vous ne faites toujours rien en termes d’apprentissage automatique ou d’optimisation mathématique, donc pour une analyse numérique hardcore, vous aurez besoin d’un autre langage de programmation à part entière, comme PyTorch, par exemple. Maintenant que vous avez tous ces éléments, vous avez déjà plusieurs éléments en mouvement, donc la configuration de l’application elle-même sera assez complexe. Vous aurez besoin d’une configuration, et cette configuration sera écrite avec un autre langage de programmation, comme JSON ou XML. On peut soutenir que ce ne sont pas des langages de programmation super complexes, mais cela ajoute encore à la liste.

Ce qui se passe lorsque vous avez autant d’éléments en mouvement, c’est que vous avez généralement besoin d’un système de construction, quelque chose qui peut exécuter tous les compilateurs et les recettes banales nécessaires pour produire le logiciel. Les systèmes de construction ont leurs propres langages. L’approche traditionnelle est un langage appelé Make, mais il en existe beaucoup d’autres. De plus, puisque Excel est capable d’afficher des résultats, vous avez besoin d’un moyen d’afficher des choses à l’utilisateur et de visualiser des choses. Cela se fera avec un mélange de JavaScript, HTML et CSS, ajoutant ainsi plus de langages à la liste.

À ce stade, nous avons une longue liste de langages de programmation, et une configuration de production réelle pourrait être encore plus complexe. Cela explique pourquoi la plupart des entreprises qui ont essayé d’adopter ce pipeline de data science au cours de la dernière décennie ont échoué de manière écrasante et sont restées pratiquement avec Excel. La raison en est qu’il faut maîtriser près d’une douzaine de langages de programmation au lieu d’un seul, comme dans le cas d’Excel. Nous n’avons même pas commencé à aborder les problèmes réels de la supply chain ; nous avons simplement discuté des aspects techniques qui empêchent de commencer réellement à faire quoi que ce soit.

Maintenant, réfléchissons à quoi ressemblerait un langage de programmation pour la supply chain. Tout d’abord, nous devons décider de ce qui est inclus dans le langage et de ce qui appartient au langage en tant que citoyen de première classe et de ce qui appartient aux bibliothèques. En effet, avec les langages de programmation, il est toujours possible de déléguer des fonctionnalités aux bibliothèques. Par exemple, regardons le langage de programmation C. Il est considéré comme un langage de programmation assez bas niveau, et C n’a pas de collecteur de déchets. Cependant, il est possible d’utiliser un collecteur de déchets tiers en tant que bibliothèque dans un programme C. Étant donné que la collecte des déchets n’est pas un citoyen de première classe dans le langage de programmation C, la syntaxe a tendance à être relativement verbeuse et fastidieuse.

Pour les besoins de la supply chain, il y a des préoccupations telles que l’optimisation mathématique et l’apprentissage automatique qui sont généralement traitées comme des bibliothèques. Ainsi, nous avons un langage de programmation, et toutes ces préoccupations sont essentiellement déléguées à des bibliothèques tierces. Cependant, si nous devions concevoir un langage de programmation pour la supply chain, il serait vraiment logique d’avoir ces préoccupations conçues comme des citoyens de première classe dans le langage de programmation lui-même. De plus, il serait logique d’avoir des données relationnelles faisant partie du langage en tant que citoyen de première classe. Dans la supply chain, le paysage applicatif, qui comprend de nombreux logiciels d’entreprise, dispose de données relationnelles sous forme de bases de données relationnelles, comme les bases de données SQL, partout. Pratiquement tous les produits logiciels d’entreprise qui existent de nos jours ont au cœur une base de données relationnelle, ce qui signifie que, pour les besoins de la supply chain, dès que nous voulons toucher les données, la réalité est que nous interagirons avec des données de nature relationnelle. Les données se présentent sous la forme d’une liste de tables extraites de toutes ces bases de données alimentant diverses applications, et chaque table a une liste de colonnes ou de champs.

Il est vraiment logique d’avoir des données relationnelles dans le langage. De plus, qu’en est-il de l’interface utilisateur (UI) et de l’expérience utilisateur (UX) ? L’un des points forts d’Excel est que tout cela est complètement intégré dans le langage, donc vous n’avez pas un langage de programmation, puis toutes sortes de bibliothèques tierces pour gérer la présentation, le rendu et l’interaction utilisateur. Tout cela fait partie du langage. Avoir tout cela en tant que citoyen de première classe serait également d’un intérêt très pertinent en ce qui concerne la supply chain, du moins si nous voulons être aussi performants qu’Excel peut l’être pour les supply chains.

Maintenant, dans la conception d’un langage, la grammaire représente la représentation formelle des règles qui définissent un programme valide selon votre langage de programmation nouvellement introduit. Essentiellement, vous commencez par un morceau de texte, et d’abord, vous appliquez un analyseur lexical, qui est une classe spécifique d’algorithmes ou un petit programme. L’analyseur lexical décompose votre morceau de texte, le programme que vous venez d’écrire, en une séquence de jetons. L’analyseur lexical isole toutes les variables et symboles en jeu dans votre langage de programmation. La grammaire aide à convertir la séquence de jetons en la sémantique réelle du programme, en définissant ce que le programme signifie et l’ensemble exact et non ambigu d’opérations qui doivent être effectuées pour l’exécuter.

La grammaire elle-même est généralement abordée comme un compromis entre les préoccupations que vous souhaitez internaliser dans votre langage et les concepts que vous souhaitez externaliser. Par exemple, si nous considérons les données relationnelles comme une préoccupation externe, le programmeur devrait introduire de nombreuses structures de données spécialisées telles que des dictionnaires, des recherches et des tables de hachage pour effectuer manuellement à l’intérieur du langage de programmation toutes ces opérations. Si la grammaire veut internaliser l’algèbre relationnelle, cela signifie que le programmeur peut généralement écrire toute la logique relationnelle directement sous sa forme relationnelle. Cependant, cela signifie que soudainement, toutes ces contraintes relationnelles et toute cette algèbre relationnelle deviennent une partie de la charge que la grammaire doit porter.

D’un point de vue de la supply chain, étant donné que les données relationnelles sont très répandues dans les logiciels d’entreprise, il est logique d’avoir une grammaire qui s’occupe de toutes les préoccupations relationnelles directement au niveau de la grammaire dans le langage.

Les grammaires en informatique sont un sujet extrêmement étudié. Elles existent depuis des décennies et pourtant, c’est probablement le seul domaine où les fournisseurs de logiciels d’entreprise échouent le plus. En effet, ils finissent invariablement par créer des langages de programmation accidentels qui émergent naturellement chaque fois qu’il y a des paramètres de configuration complexes en jeu. Lorsque vous avez des conditions, des déclencheurs, des boucles et des réponses, vous devez généralement vous occuper de ce langage au lieu de le laisser émerger de lui-même.

Ce qui se passe, c’est que lorsque vous n’avez pas de grammaire, chaque fois que vous apportez des modifications à l’application, vous vous retrouvez avec des conséquences désordonnées sur le comportement réel du système. D’ailleurs, cela explique également pourquoi la mise à niveau d’une version d’un logiciel d’entreprise vers une autre est généralement très complexe. La configuration est censée être la même, mais lorsque vous essayez réellement d’exécuter la même configuration dans la version suivante du logiciel, vous obtenez des résultats complètement différents. La cause profonde de ces problèmes est le manque de grammaire et de sémantique formalisée établie pour ce que la configuration va signifier.

La façon typique de représenter une grammaire est de manière formelle en utilisant la Forme de Backus-Naur (BNF), qui est une notation spéciale. À l’écran, ce que vous pouvez voir est un mini langage de programmation qui représente les adresses postales américaines. Chaque ligne avec un signe égal représente une règle de production. Ce que vous avez à gauche est un symbole non terminal, et à droite du signe égal se trouve une séquence de symboles terminaux et non terminaux. Les symboles terminaux sont en rouge et représentent des symboles qui ne peuvent pas être dérivés davantage. Les symboles non terminaux sont entre crochets et peuvent être dérivés davantage. Cette grammaire ici n’est pas complète ; il faudrait ajouter beaucoup plus de règles de production pour une grammaire complète. Je voulais juste garder cette diapositive raisonnablement concise.

Une grammaire est quelque chose de très simple à définir en termes de syntaxe pour votre langage de programmation, et elle garantit également qu’elle sera non ambiguë. Cependant, ce n’est pas parce qu’elle est écrite avec la Forme de Backus-Naur qu’elle va être une grammaire valide ou même une bonne grammaire. Pour avoir une bonne grammaire, nous devons faire un peu plus que cela. La manière mathématique de caractériser une bonne grammaire est d’avoir une grammaire sans contexte. Une grammaire est dite sans contexte si les règles de production peuvent être appliquées pour n’importe quel symbole non terminal, indépendamment des symboles que vous trouvez à droite et à gauche. L’idée est qu’une grammaire sans contexte est quelque chose où vous pouvez appliquer les règles de production dans n’importe quel ordre, et dès que vous voyez une correspondance ou une dérivation, vous l’appliquez simplement.

Ce que vous obtenez d’une grammaire sans contexte est une grammaire qui, si vous modifiez quelque chose dedans et que ce changement crée une ambiguïté, le compilateur ne pourra pas compiler le programme où l’ambiguïté se produit. Cela est d’un intérêt primordial lorsque vous avez l’intention de maintenir une configuration pendant une longue période de temps. Dans les chaînes d’approvisionnement, la plupart des logiciels d’entreprise ont une durée de vie très longue. Il n’est pas rare de voir des morceaux de logiciels d’entreprise fonctionner pendant deux ou trois décennies. Chez Lokad, nous servons plus de 100+ entreprises, et il est assez courant que nous extrayions des données de systèmes qui sont en place depuis plus de trois décennies, en particulier avec les grandes entreprises.

Avec une grammaire sans contexte, vous avez la garantie que s’il y a un changement à apporter à ce langage (et rappelez-vous, quand je dis “langage”, je peux signifier quelque chose d’aussi basique que des paramètres de configuration), vous serez en mesure d’identifier les ambiguïtés qui apparaissent lorsque vous appliquez ce changement. Cela évite d’avoir ces ambiguïtés qui se produisent sans que vous vous rendiez compte que vous avez un problème, ce qui peut entraîner des difficultés lors de la mise à niveau d’un système à un autre.

Que se passe-t-il lorsque les gens ne connaissent rien aux grammaires ? Ils écrivent manuellement un analyseur syntaxique. Si vous n’avez jamais entendu parler d’une grammaire, un ingénieur en logiciel écrirait un analyseur syntaxique, qui est un programme qui crée de manière aléatoire une sorte d’arbre qui représente la version analysée de votre programme. Le problème avec cela est que vous vous retrouvez avec une sémantique pour votre programme qui est incroyablement spécifique à la version du programme que vous avez. Donc, si vous changez ce programme, vous changez la sémantique, et vous obtiendrez des résultats différents, ce qui signifie que vous pouvez avoir la même configuration mais un comportement différent pour votre chaîne d’approvisionnement.

Heureusement, en 2004, il y a eu une petite percée introduite par Brian Ford avec un article intitulé “Parsing Expression Grammars: A Recognition-Based Syntactic Foundation”. Avec ce travail, Ford a fourni à la communauté un moyen de formaliser le genre d’analyseur syntaxique ad hoc accidentel qui existe sur le terrain. Par exemple, ces grammaires sont appelées Parsing Expression Grammars (PEGs), et avec les PEGs, vous pouvez convertir ces analyseurs empiriques semi-accidentels en véritables grammaires formelles d’une certaine sorte.

Python, par exemple, n’a pas exactement une grammaire contextuelle libre mais a un PEG. Les PEG sont plutôt bien si vous disposez d’un ensemble étendu de tests automatisés car, dans ce cas, vous pouvez gérer la préservation de la sémantique au fil du temps. En effet, avec les PEG, vous avez une formalisation de votre grammaire, donc vous êtes dans une meilleure situation par rapport à ne pas avoir de grammaire du tout et simplement avoir un analyseur syntaxique. Cependant, en termes d’évolution de la sémantique, avec un PEG, vous ne détecterez pas automatiquement que vous avez un changement de sémantique si vous modifiez la grammaire elle-même. Ainsi, vous devez disposer d’un ensemble étendu de tests automatisés sur votre PEG, ce que la communauté Python fait d’ailleurs. Ils disposent d’un ensemble de tests automatisés très robuste et étendu. Maintenant, d’un point de vue de la supply chain, je pense que les grammaires ont non seulement un intérêt à vous faire réaliser leur importance, mais constituent également un test décisif. Vous pouvez réellement tester les fournisseurs de logiciels d’entreprise lors de la discussion d’un logiciel présentant une complexité significative. Vous devriez demander au fournisseur quelle grammaire il utilise pour la configuration complexe. Si le fournisseur répond “qu’est-ce qu’une grammaire ?”, alors vous savez que vous êtes en difficulté et que la maintenance sera probablement lente et coûteuse.

La programmation est très difficile et les gens feront beaucoup d’erreurs. Si c’était facile, nous n’aurions même pas besoin de programmation en premier lieu. Un bon langage de programmation minimise le temps nécessaire pour identifier une erreur et la corriger. Il s’agit là d’un des aspects les plus critiques d’un langage de programmation, garantissant une productivité décente pour quiconque écrit du code.

Prenons en compte la situation suivante : lorsque vous écrivez du code, si l’erreur peut être détectée pendant que vous tapez, comme une faute de frappe soulignée en rouge dans Microsoft Word, alors la boucle de rétroaction pour corriger l’erreur peut être aussi courte que 10 secondes, ce qui est idéal. Si l’erreur ne peut être détectée que lorsque vous commencez à exécuter le programme, la boucle de rétroaction sera d’au moins 10 minutes. En supply chain, nous avons souvent de grands ensembles de données à traiter et nous ne pouvons pas nous attendre à ce que le programme commence à parcourir toutes les données en quelques secondes. Par conséquent, si le problème se produit uniquement à l’exécution, la boucle de rétroaction sera de 10 minutes ou plus.

Si l’erreur ne peut être détectée qu’après l’exécution du script, c’est-à-dire si le programme présente une erreur mais ne se bloque pas, la boucle de rétroaction prendra environ 10 heures ou plus. Nous sommes passés de 10 secondes de rétroaction en temps réel à 10 minutes si nous devons exécuter le programme, puis à 10 heures si nous devons inspecter les résultats numériques et les KPI produits par le programme.

Il y a même un scénario encore pire : si la plateforme sur laquelle vous opérez n’est pas strictement déterministe, c’est-à-dire qu’avec la même entrée et les mêmes données, elle peut vous donner des résultats différents. Ce n’est pas aussi étrange que cela puisse paraître, car dans la supply chain, nous pouvons avoir des simulations de Monte Carlo en cours. S’il y a une quelconque aléatoire dans les résultats, nous pouvons avoir quelque chose qui échoue seulement de temps en temps, et dans cette situation, la boucle de rétroaction est généralement plus longue que 10 jours. Ainsi, nous sommes passés de 10 secondes à 10 jours, et il y a d’énormes enjeux à resserrer cette boucle de rétroaction. L’analyse statique représente un ensemble de techniques qui peuvent être appliquées pour détecter des problèmes, des erreurs ou des échecs sans même exécuter le programme en premier lieu. Avec l’analyse statique, l’idée est que vous n’exécuterez même pas le programme, ce qui signifie que vous pouvez signaler l’erreur en temps réel pendant que les gens tapent, tout comme un soulignement rouge pour les fautes de frappe dans Microsoft Word. Plus généralement, il y a un fort intérêt à transformer chaque problème de manière à le faire remonter dans une classe antérieure de rétroaction, en transformant des problèmes qui prendraient des jours à identifier en minutes ou des minutes en secondes, et ainsi de suite.

Du point de vue de la supply chain, nous avons vu dans l’un des cours précédents que les supply chains peuvent s’attendre à beaucoup de chaos. Nous ne pouvons pas avoir des cycles de mise en production classiques où vous attendez la prochaine version de votre logiciel. Parfois, il y a des événements extraordinaires, comme un changement de tarif, un navire porte-conteneurs bloqué dans un canal ou une pandémie. Ces situations d’urgence nécessitent des corrections d’urgence, et la quantité d’analyse statique que vous pouvez effectuer sur votre langage de programmation définit pratiquement le niveau de chaos que vous obtiendrez en production en raison d’erreurs non détectées en temps réel lors de la saisie du code. Les événements extraordinaires peuvent sembler rares, mais en pratique, les surprises dans la supply chain sont assez courantes.

Il existe des preuves mathématiques qu’il n’est pas possible de détecter toutes les erreurs avec un langage de programmation général dans une situation générale. Par exemple, il n’est même pas possible de prouver que le programme se terminera, ce qui signifie qu’il n’est pas possible de garantir que ce que vous avez écrit ne continuera pas à s’exécuter indéfiniment.

Avec l’analyse statique, vous obtenez généralement trois catégories : certaines parties du code sont probablement bonnes, certaines parties sont probablement mauvaises, et pour beaucoup de choses entre les deux, vous ne savez tout simplement pas. L’idée est que plus vous vous déplacez de “ne pas savoir” à “mauvais code”, plus vous aurez besoin d’efforts en termes de conception de langage pour convaincre le compilateur que votre programme est valide. Ainsi, nous devons trouver un équilibre entre l’effort que vous souhaitez investir pour convaincre le langage de programmation que votre code est correct et le nombre de garanties que vous souhaitez avoir sur le programme au moment de la compilation, même avant que le programme ne s’exécute réellement. C’est une question de productivité.

Maintenant, une liste rapide des erreurs typiques détectées par l’analyse statique comprend les erreurs de syntaxe, telles que les virgules ou les parenthèses oubliées. Certains langages de programmation ne peuvent même pas signaler les erreurs de syntaxe avant l’exécution, comme Bash, le langage shell sur Linux. L’analyse statique peut également détecter les erreurs de type, qui se produisent lorsque vous avez le mauvais type ou le mauvais nombre d’arguments pour une fonction que vous appelez.

Le code inaccessible peut également être détecté, ce qui signifie que le code est correct, mais il ne s’exécutera jamais car le programme entier peut s’exécuter sans jamais atteindre cette partie de code. C’est comme du code mort ou une connexion logique oubliée. Le code insignifiant est un autre problème qui peut être identifié, où le code s’exécute mais n’a aucun impact sur la sortie finale. C’est une variante du code inaccessible.

Le code de dépassement de budget peut également être détecté, ce qui fait référence à un code qui s’exécuterait, sauf que la quantité de ressources informatiques nécessaires dépasse largement ce que vous pouvez vous permettre pour votre programme. Un programme consomme des ressources informatiques telles que la mémoire, le stockage et le CPU. Grâce à l’analyse statique, vous pouvez prouver qu’un bloc de code consomme beaucoup plus de ressources que vous ne pouvez vous permettre, en tenant compte de vos contraintes telles que la réalisation du calcul dans un délai spécifique. Vous voudriez que cela échoue lors de la compilation plutôt que d’exécuter votre programme pendant une heure pour qu’il échoue en raison d’un délai d’attente, ce qui entraînerait une très faible productivité.

Cependant, il y a une subtilité en ce qui concerne l’analyse statique. Pendant que vous tapez, vous travaillez avec un programme qui est toujours invalide. À mesure que vous tapez caractère par caractère, vous transformez un programme valide en un programme invalide. Une solution de qualité industrielle pour cette situation s’appelle un protocole de serveur de langage. Cet outil est livré avec un langage de programmation et représente l’état de l’art en matière de rétroaction d’erreur en temps réel pour les programmes que vous tapez.

Grâce à un protocole de serveur de langage, vous pouvez accéder à des fonctionnalités telles que “aller à la définition” lorsque vous cliquez sur une variable. Le protocole de serveur de langage est fondamentalement étatique, se souvenant de la dernière version de votre programme qui était correcte, ainsi que des annotations et des sémantiques disponibles. Il conserve ces annotations et ces petits détails supplémentaires lorsqu’il traite votre programme cassé simplement parce que vous avez appuyé sur une touche supplémentaire et que ce n’est plus un programme valide. C’est un changement de paradigme en termes de productivité, et chaque fois qu’il y a un certain degré d’urgence, cela fait une grande différence pour les besoins de la supply chain.

Maintenant, plongeons dans le système de types. En première approximation, un système de types est un ensemble de règles qui utilise la catégorisation des objets dans votre programme, ou la catégorisation des éléments que vous manipulez, pour clarifier si certaines interactions sont autorisées ou interdites. Par exemple, les types courants incluent les chaînes de caractères, les entiers et les nombres à virgule flottante, qui sont tous des types très basiques. Il définira que l’addition de deux entiers est valide, mais l’addition d’une chaîne de caractères et d’un entier n’est pas valide, sauf en JavaScript car les sémantiques sont différentes là-bas.

Les systèmes de types, en général, sont un problème de recherche ouvert et peuvent devenir incroyablement abstraits. Pour éclairer un peu les choses, nous devons préciser qu’il existe deux types de types, qui sont souvent confondus. Premièrement, il y a les types de valeurs, qui n’existent qu’au moment de l’exécution lorsque le programme est réellement en cours d’exécution. Par exemple, en Python, si nous considérons une fonction qui renvoie le premier élément d’un tableau d’entiers, alors le type de la valeur renvoyée par cette fonction sera un entier. De ce point de vue, tous les langages de programmation ont des types - ils sont tous typés.

Deuxièmement, il y a les types de variables, qui n’existent qu’au moment de la compilation, lorsque le programme est en cours de compilation et n’est pas encore en cours d’exécution. Le défi avec les types de variables est d’extraire autant d’informations que possible sur ces variables au moment de la compilation. Si nous revenons à l’exemple précédent, en Python, il peut être possible ou non d’identifier le type de la valeur de retour renvoyée par la fonction, car Python n’est pas entièrement fortement typé au moment de la compilation.

D’un point de vue de la supply chain, nous recherchons un système de types qui prend en charge ce que nous avons l’intention de faire pour le bénéfice de la supply chain. Nous voulons être aussi restrictifs que possible pour détecter les problèmes et les bugs tôt, mais aussi aussi flexibles que possible pour permettre toutes les opérations qui pourraient être intéressantes. Par exemple, considérons l’addition d’une date et d’un entier. Dans un langage de programmation classique, vous diriez probablement que ce n’est pas légitime, mais d’un point de vue de la supply chain, si nous avons une date et que nous voulons ajouter sept jours, il serait logique d’écrire “date + 7”. Il existe de nombreuses opérations de planification de la supply chain qui impliquent le décalage des dates d’un certain nombre de jours, il serait donc utile d’avoir une algèbre où il est possible d’effectuer une addition entre une date et un nombre.

En termes de types, voulons-nous autoriser l’addition d’une date à une autre ? Probablement pas. Cependant, voulons-nous autoriser la soustraction entre deux dates ? Pourquoi pas ? Si nous soustrayons une date d’une autre qui se produit avant elle, nous obtenons le delta, qui peut être exprimé en jours. Cela a beaucoup de sens pour les calculs liés à la planification.

Poursuivant avec le sujet des dates, il existe également des caractéristiques qui pourraient être intéressantes lorsque l’on pense à ce que devrait faire un système de types pour nous en termes de préoccupations de la supply chain. Par exemple, que diriez-vous de restreindre la plage de temps acceptable ? Nous pourrions dire que les dates en dehors de la période de 20 ans dans le passé et de 20 ans dans le futur ne sont tout simplement pas valides. Il est fort probable que si nous effectuons une opération de planification et qu’à un moment donné du programme nous manipulons une date qui est plus de 20 ans dans le futur, il est très peu probable que ce soit une planification valide pour la plupart des industries. Dans la plupart des cas, vous ne planifiez pas des opérations à un niveau quotidien plus de 20 ans à l’avance. Ainsi, nous pouvons non seulement prendre les types habituels, mais les redéfinir de manière plus restrictive et plus appropriée aux besoins de la supply chain.

De plus, il y a toute la dimension de l’incertitude. En gestion de la supply chain, nous regardons toujours vers l’avenir, mais malheureusement, l’avenir est toujours incertain. La façon mathématique d’appréhender l’incertitude est par le biais de variables aléatoires. Il serait logique d’intégrer des variables aléatoires dans le langage pour représenter la demande future incertaine, les délais d’approvisionnement et les retours de clients, entre autres choses.

Chez Lokad, nous avons développé Envision, un langage de programmation dédié à l’optimisation prédictive des supply chains. Envision est un mélange de SQL, Python, d’optimisation mathématique, d’apprentissage automatique et de capacités de big data, le tout intégré en tant que citoyens de première classe au sein du langage lui-même. Ce langage est accompagné d’un environnement de développement intégré (IDE) basé sur le web, ce qui signifie que vous pouvez écrire un script depuis le web et bénéficier de toutes les fonctionnalités modernes d’édition de code. Ces scripts fonctionnent sur un système de fichiers distribué intégré qui fait partie de l’environnement Lokad, de sorte que la couche de données est entièrement intégrée dans le langage de programmation.

Les scripts Envision s’exécutent sur une flotte de machines conçues pour tirer parti de l’ensemble du cloud. Lorsque le script est exécuté, il se répartit sur de nombreuses machines afin de s’exécuter plus rapidement. À l’écran, vous pouvez voir le pipeline de compilation utilisé par Envision. Aujourd’hui, nous n’allons pas discuter de ce langage de programmation ; nous allons simplement discuter de son pipeline de compilation car c’est le sujet d’intérêt de la conférence d’aujourd’hui.

Tout d’abord, nous commençons par un morceau de texte qui contient le script Envision. Il représente un programme qui a été écrit par un expert en supply chain, pas par un ingénieur logiciel, pour résoudre un problème spécifique de supply chain. Ce défi pourrait consister à décider quoi produire, quoi réapprovisionner, quoi déplacer ou s’il faut ajuster un prix à la hausse ou à la baisse. Ces cas d’utilisation impliquent des décisions sur ce qu’il faut produire, réapprovisionner, déplacer ou si l’on doit ajuster les prix à la hausse ou à la baisse. Le texte du script contient les instructions, et l’idée est de traiter ce script et d’obtenir l’arbre de syntaxe sans perte (LST). L’arbre de syntaxe sans perte est intéressant car c’est une représentation très spécifique qui ne supprime aucun caractère. Même les espaces blancs non significatifs sont conservés. La raison en est de s’assurer que toute réécriture automatisée du programme n’altère pas le code existant. Cette approche évite les situations où les outils réorganisent le code, déplacent les indentations ou causent d’autres perturbations qui rendent le code difficile à reconnaître.

Une opération de refactoring de base, par exemple, pourrait consister à renommer une variable et toutes ses occurrences dans le programme sans toucher à autre chose. À partir de l’arbre de syntaxe sans perte, nous passons à l’arbre de syntaxe abstraite (AST), où nous simplifions l’arbre. Les parenthèses ne sont pas nécessaires à cette étape car la structure de l’arbre définit les priorités de toutes les opérations. De plus, nous effectuons une série d’opérations de désucre pour supprimer toute syntaxe fournie pour le bénéfice du programmeur final.

Passant de l’AST au graphe de syntaxe abstraite (ASG), nous aplatissions l’arbre. Ce processus consiste à décomposer des déclarations complexes avec des expressions fortement imbriquées en une séquence de déclarations élémentaires. Par exemple, une déclaration telle que “a = b + c + d” serait divisée en deux déclarations, chacune avec une seule addition. C’est précisément ce qui se passe lors de la transition de l’AST à l’ASG.

À partir de l’ASG, nous passons au graphe d’optimisation (OG), où nous effectuons un façonnage et une diffusion des types, en particulier en ce qui concerne l’algèbre relationnelle. Comme mentionné précédemment, Envision intègre une algèbre relationnelle dans le langage. Comme mentionné à plusieurs reprises auparavant, Envision intègre une algèbre relationnelle, comme dans les bases de données relationnelles ou les bases de données SQL, en tant que citoyen de première classe. Il existe de nombreuses opérations relationnelles, et nous vérifions que ces opérations relationnelles sont valides selon le schéma des tables avec lesquelles nous travaillons lors de la transition de l’ASG à l’OG. Le graphe d’optimisation (OG) représente la dernière étape de notre front-end de compilation et se compose d’opérations relationnelles pures et élémentaires qui s’appliquent au programme, représentant de petits morceaux de logique. Comme en SQL, ces éléments sont de nature relationnelle.

Le graphe d’optimisation est appelé “optimisation” car de nombreuses transformations se produisent de l’OG à l’OG. Ces transformations se produisent car, lorsqu’il s’agit d’algèbre relationnelle, organiser les opérations de certaines manières peut rendre le programme beaucoup plus rapide. Par exemple, en SQL, si vous avez un filtre puis une opération, ou une opération d’abord puis un filtre, il est préférable de filtrer d’abord les données, puis d’appliquer l’opération. Cela garantit que les opérations ne sont appliquées qu’aux données nécessaires, améliorant ainsi l’efficacité.

Chez Lokad, la dernière étape du compilateur front-end est la Représentation Intermédiaire Haute (HIR). Le HIR est une frontière propre, stable et documentée entre le front-end et le back-end du pipeline du compilateur. Contrairement au Graphique d’Optimisation (OG), qui change constamment en raison des heuristiques, le HIR est stable et fournit une entrée cohérente pour le back-end du compilateur. De plus, le HIR est sérialisable, ce qui signifie qu’il peut facilement être transformé en un ensemble d’octets pour être déplacé d’une machine à une autre. Cette propriété est essentielle pour distribuer les calculs sur plusieurs machines.

À partir de la Représentation Intermédiaire Haute, nous passons aux “funcs”. Les funcs sont des valeurs qui doivent encore être évaluées et représentent les blocs atomiques de calcul dans une exécution distribuée. Par exemple, lors de l’addition de deux vecteurs gigantesques à partir d’une table avec des milliards de lignes, il y aura une série de funcs représentant diverses parties de ces vecteurs. Chaque func est responsable de l’addition d’une partie des deux vecteurs et est exécuté sur une machine. Les calculs importants sont divisés en plusieurs funcs pour répartir la charge de travail sur plusieurs CPU et plusieurs machines si le calcul est suffisamment important pour justifier ce degré de distribution. Les funcs sont appelées “lazy” car elles ne sont pas évaluées au départ ; elles sont évaluées lorsque cela est nécessaire. De nombreux calculs peuvent se produire avant que certaines funcs ne soient réellement calculées, et une fois qu’une func est calculée, la func elle-même est remplacée par son résultat.

À l’intérieur de la func, vous trouverez la représentation intermédiaire basse, qui représente la logique impérative de bas niveau qui s’exécute à l’intérieur de la func. Elle peut, par exemple, inclure des boucles et des accès à des dictionnaires. Enfin, cette représentation intermédiaire de bas niveau est compilée en bytecode, qui représente l’objectif final de notre pipeline de compilation. Chez Lokad, nous ciblons le bytecode .NET, techniquement connu sous le nom de MSIL.

Du point de vue de la supply chain, ce qui est vraiment intéressant, c’est qu’à travers ce pipeline de compilation, nous reproduisons le degré d’intégration que l’on trouve dans Microsoft Excel. Le langage est intégré à la couche de données et à la couche UI/UX, ce qui permet aux utilisateurs de voir et d’interagir avec les sorties du programme, tout comme ils le feraient avec une feuille de calcul Excel. Cependant, contrairement à Excel, nous explorons des territoires beaucoup plus intéressants pour la gestion de la supply chain en adoptant les concepts relationnels en tant que citoyens de première classe, ainsi que l’optimisation mathématique et l’apprentissage automatique.

Tant l’optimisation mathématique que l’apprentissage automatique dans ce pipeline passent par l’ensemble du pipeline, au lieu d’appeler simplement une bibliothèque qui se trouve quelque part. Avoir l’apprentissage automatique en tant que citoyen de première classe dans le pipeline permet d’obtenir des messages d’erreur plus intelligibles, ce qui fait une grande différence en termes de productivité pour les experts de la supply chain.

Enfin, les compilateurs ciblent presque toujours une machine virtuelle de nos jours, mais ces machines virtuelles, à leur tour, sont compilées vers une autre machine virtuelle. À l’écran, les couches VM typiques que l’on trouve dans une configuration basée sur un serveur sont très similaires à ce que nous avons avec un script Envision. Je viens de présenter le pipeline de compilation, mais fondamentalement, ce serait à peu près la même pile si nous réfléchissions à un script Python ou à une feuille de calcul Excel exploitée à partir d’un serveur. Lors de la conception d’un compilateur, vous choisissez essentiellement la couche à laquelle vous allez injecter le code. Plus la couche est profonde, plus vous devez traiter de questions techniques. Pour choisir la couche, il y a une série de préoccupations qui doivent être prises en compte.

Tout d’abord, il y a la sécurité. Comment protégez-vous votre mémoire et qu’est-ce que le programme doit ou ne doit pas accéder ? Si vous avez un langage de programmation générique, vos options sont limitées. Vous devrez peut-être opérer au niveau du système d’exploitation invité, même si cela peut ne pas être très sécurisé. Il existe des moyens de sandbox, mais c’est très délicat, vous devrez peut-être même aller plus bas que ça.

Deuxièmement, il y a la préoccupation des fonctionnalités de bas niveau qui vous intéressent. Par exemple, cela pourrait être important si vous voulez obtenir une exécution plus performante, réduisant la quantité de ressources informatiques nécessaires pour terminer votre programme. Vous pouvez décider d’aller suffisamment bas pour gérer la mémoire et les threads. Cependant, avec ce pouvoir vient la responsabilité de gérer réellement la mémoire et les threads.

Troisièmement, il y a des fonctionnalités de commodité comme la collecte des déchets, la trace de la pile, le débogueur et le profileur. En général, tous les instruments autour du compilateur sont plus complexes que le compilateur lui-même. La quantité de fonctionnalités de commodité dont vous bénéficiez ne doit pas être sous-estimée.

Quatrièmement, il y a des préoccupations d’allocation des ressources. Si vous travaillez avec une feuille de calcul Excel sur votre ordinateur de bureau, Excel peut consommer toutes les ressources informatiques de votre poste de travail. Cependant, avec Envision ou SQL, vous avez plusieurs utilisateurs à servir, et vous devez décider comment allouer les ressources. De plus, avec Envision, il ne s’agit pas seulement de plusieurs utilisateurs, mais aussi de plusieurs entreprises à servir, car Lokad est multi-tenant. Cela a du sens dans la supply chain car le besoin en ressources de calcul est très intermittent pour la plupart des supply chains.

En général, vous avez seulement besoin d’une explosion très intense de calcul pendant une demi-heure ou peut-être une heure, puis plus rien pendant les 23 heures suivantes. Ensuite, rincez et répétez quotidiennement. Si vous deviez allouer des ressources informatiques matérielles à une entreprise, ces ressources resteraient inutilisées 90% du temps, voire plus. Vous voulez donc pouvoir répartir la charge de travail sur de nombreuses machines et sur de nombreuses entreprises, potentiellement des entreprises qui opèrent dans différents fuseaux horaires.

Enfin, il y a la préoccupation de l’écosystème. L’idée est que lorsque vous décidez d’une couche spécifique et d’une machine virtuelle spécifique à cibler pour votre compilateur, il sera assez pratique d’intégrer et d’interfacer votre compilateur avec tout ce qui cible également les mêmes machines virtuelles exactes. Cela soulève la question de l’écosystème : qu’est-ce que vous pouvez trouver au même niveau que ce que vous ciblez, afin de ne pas réinventer la roue pour chaque petit détail impliqué dans l’ensemble de votre pile ? C’est la dernière et importante préoccupation.

En conclusion, félicitations aux heureux élus qui sont arrivés si loin dans cette série de conférences sur la supply chain. C’est probablement l’une des conférences les plus techniques jusqu’à présent. Les compilateurs sont une pièce arguablement très technique ; cependant, la réalité des supply chains modernes est que tout passe par un langage de programmation. Il n’y a plus de supply chain brute et directement observable. La seule façon d’observer une supply chain est par le biais de l’enregistrement électronique produit par toutes les pièces du logiciel d’entreprise constituant le paysage applicatif. Ainsi, un langage de programmation est nécessaire, et par défaut, ce langage de programmation se trouve être Excel.

Cependant, si nous voulons faire mieux qu’Excel, nous devons réfléchir sérieusement à ce que “mieux” signifie même d’un point de vue de la supply chain et ce que cela signifie en termes de langages de programmation. Si une entreprise n’a pas la bonne stratégie ou la bonne culture, aucune technologie ne pourra la sauver. Cependant, si la stratégie et la culture sont solides, alors les outils sont vraiment importants. Les outils, y compris les langages de programmation, définiront votre capacité à exécuter, la productivité que vous pouvez attendre de vos experts en supply chain et les performances que vous obtiendrez de votre supply chain lorsque vous transformerez la stratégie macro en milliers de décisions quotidiennes banales que votre supply chain doit prendre. Être capable d’évaluer l’adéquation des outils, y compris les langages de programmation que vous avez l’intention d’utiliser pour relever les défis de la supply chain, est d’une importance primordiale. Si vous n’êtes pas capable d’évaluer, alors c’est juste du culte du cargo complet.

La prochaine conférence portera sur l’ingénierie logicielle. Aujourd’hui, nous avons discuté des outils ; cependant, la prochaine fois, nous discuterons des personnes qui utilisent les outils et du type de travail d’équipe nécessaire pour bien faire le travail. La conférence aura lieu le même jour de la semaine, le mercredi, à 15 heures, heure de Paris.

Maintenant, je vais jeter un coup d’œil aux questions.

Question : Lors de la sélection d’un logiciel pour les supply chains, comment les entreprises qui ne sont pas technophiles peuvent-elles évaluer si le compilateur et la programmation sont adaptés à leurs besoins ?

Eh bien, je suis assez sûr qu’une entreprise typique qui exploite une supply chain typique n’a pas les qualifications pour concevoir un véhicule, et pourtant elle parvient à acheter des camions qui conviennent à sa supply chain et à ses besoins de transport. Ce n’est pas parce que vous n’êtes pas un expert et que vous n’êtes pas capable de reconstruire et de réingénier un camion que vous ne pouvez pas avoir un avis très solide sur le fait que c’est un bon camion pour vos besoins de transport. Donc, je ne dis pas que les entreprises qui ne sont pas technophiles devraient faire un bond incroyable en avant et devenir soudainement des experts en conception de compilateurs. Cependant, je crois qu’en seulement une heure et demie, nous avons couvert pas mal de terrain. Avec 10 heures de plus pour une introduction plus détaillée et plus lente, vous apprendriez tout ce dont vous auriez jamais besoin de savoir en termes de conception de langage à des fins de supply chain.

Il y a une différence entre être un expert et être tellement incroyablement ignorant que les gens peuvent vous vendre un scooter en prétendant que c’est un camion. Si nous devions traduire ce genre d’ignorance que j’ai observée en termes de conception de logiciel d’entreprise à l’industrie automobile, les gens prétendraient qu’un scooter est un semi-remorque et vice versa, et s’en sortiraient.

Cette série de conférences porte sur les sciences auxiliaires, il n’y a donc pas d’intention pour les personnes qui veulent être des praticiens de la supply chain de devenir des experts dans ces domaines. Néanmoins, en ayant une certaine connaissance de base, vous pouvez aller très loin dans l’évaluation. La plupart du temps, vous n’avez besoin que d’avoir juste assez de connaissances pour poser des questions difficiles. Si le vendeur vous donne une réponse absurde, cela ne donne pas une bonne impression. Si vous ne savez même pas quelles questions techniques poser, vous pouvez être trompé.

Ma suggestion est que vous n’avez pas besoin de devenir incroyablement compétent en technologie ; vous avez juste besoin d’être suffisamment compétent pour être un amateur débutant qui peut trouver des failles et évaluer si tout s’effondre ou s’il y a une réelle substance derrière. Il en va de même pour l’optimisation mathématique, l’apprentissage automatique, les processeurs, etc. L’idée est de savoir suffisamment pour faire la différence entre quelque chose de frauduleux et quelque chose de légitime.

Question : Avez-vous directement abordé le problème des langages de programmation existants qui ne sont pas conçus pour la supply chain ?

C’est une très bonne question. Concevoir un tout nouveau langage de programmation peut sembler complètement fou. Pourquoi ne pas simplement opter pour quelque chose déjà bien établi, comme Python, et apporter les petites modifications dont nous avons besoin ? Cela aurait été une option. Le problème est que la principale préoccupation n’est pas vraiment ce que nous devons ajouter à ces langages, mais ce que nous devons supprimer.

Ma principale préoccupation avec Python n’est pas qu’il n’a pas d’algèbre probabiliste ou qu’il n’a pas d’algèbre relationnelle intégrée. Ma principale critique est que c’est un langage de programmation entièrement capable et générique, et qu’il expose donc la personne qui va écrire du code à toutes sortes de concepts, comme la programmation orientée objet pour Python, qui sont totalement insignifiants en ce qui concerne la supply chain. Le problème n’était pas tant de prendre un langage et d’ajouter quelque chose, mais de prendre un langage et d’essayer de supprimer des tonnes de choses. Cependant, le problème est que dès que vous supprimez des éléments d’un langage de programmation existant, tout se casse.

Par exemple, la première version de Python est sortie en 1990, donc c’est un langage de programmation de 30 ans. La quantité de code dans une pile populaire comme Python est absolument gigantesque, et pour de bonnes raisons. Je ne le critique pas ; c’est une pile très solide, mais c’est aussi une pile énorme. Donc, en fin de compte, nous avons évalué différentes options : prendre un langage de programmation, soustraire des tonnes de choses jusqu’à ce que nous soyons satisfaits de ce que nous avons, ou considérer que tous ces langages de programmation ont eux-mêmes des tonnes d’héritage.

Nous avons évalué l’effort nécessaire pour créer un tout nouveau langage, et au final, cela penchait très en faveur de la création d’un nouveau langage. L’ingénierie d’un nouveau langage de programmation est un domaine très établi, donc même si cela peut sembler incroyable, ce ne l’est pas. Il existe des centaines de livres qui vous donnent des recettes, et c’est maintenant accessible même aux étudiants en informatique. Il y a même des professeurs dans les départements d’informatique qui donnent à leurs étudiants un projet sur un semestre pour créer un compilateur pour un nouveau langage de programmation.

En fin de compte, nous avons décidé que les supply chains étaient suffisamment massives pour justifier un effort dédié. Oui, vous pouvez toujours recycler des choses qui n’ont pas été conçues pour les supply chains, mais les supply chains sont une industrie et un ensemble de problèmes mondiaux massifs. Nous avons donc pensé que compte tenu de l’échelle à laquelle nous nous intéressons, il est logique de faire les choses correctement et de créer quelque chose directement pour la supply chain plutôt que de recycler accidentellement.

Question : Pour l’optimisation de la supply chain, Envision est approprié car il comprend SQL, Python, etc. Cependant, pour les WMS, ERP, où le flux de processus est essentiel plutôt que l’optimisation mathématique, comment pouvez-vous évaluer son compilateur et son langage de programmation ?

C’est une très bonne question. J’ai personnellement joué avec l’idée qu’il existe des acteurs dans cette industrie qui ont réellement conçu leurs propres langages de programmation, uniquement dans le but de mettre en œuvre quelque chose de complètement transactionnel, axé sur le flux de travail. La supply chain, telle que je la vois, est essentiellement axée sur l’optimisation prédictive. Cependant, M. Nannani a tout à fait raison ; qu’en est-il de toute la partie gestion, comme l’ERP, le WMS, etc. ?

Il s’avère qu’il existe de nombreuses entreprises dans ce domaine qui ont créé leur propre langage de programmation. J’ai mentionné SAP, qui dispose de l’ABAP, conçu spécialement pour cela. Malheureusement, l’ABAP n’a pas très bien vieilli, à mon avis. Il y a beaucoup de choses dans l’ABAP qui n’ont pas vraiment de sens au XXIe siècle. On peut vraiment voir que cette chose a été conçue en ‘83, et ça se voit. Par exemple, dans Microsoft Dynamics, l’ERP dispose de son propre langage de programmation. Dynamics AX a son propre langage de programmation, et de nombreux projets ERP apportent en grande partie leur propre langage de programmation. Donc, ça existe.

Maintenant, est-ce que ces langages sont vraiment le summum de ce que nous pouvons faire en termes de langages de programmation modernes et de pointe en 2021 ? Je ne le pense pas, et c’est aussi le problème dont je parlais : les éditeurs de logiciels d’entreprise ne cessent de réinventer des langages de programmation, mais en général, ils font un très mauvais travail. C’est juste de l’ingénierie au hasard. Ils ne prennent même pas le temps de lire les nombreux livres disponibles sur le marché, et il y a de pauvres ingénieurs qui se retrouvent avec un tas de désordre.

Revenons à votre question, j’ai joué avec l’idée que Lokad se lance dans ce domaine et crée un langage conçu non pas pour l’optimisation mais pour soutenir le flux de travail. Cependant, à ce stade, la croissance de Lokad est telle que nous ne pouvons pas nous séparer et nous occuper des flux de travail. Je suis absolument certain que c’est exact, et de nouveaux acteurs émergeront et feront un très bon travail pour la partie gestion du problème. Lokad ne s’attaque qu’à la partie optimisation des supply chains ; il y a aussi la partie gestion.

Question : Python est actuellement considéré comme un langage de programmation standard. Y a-t-il des évolutions en cours sur le marché ?

C’est une très bonne question. Vous savez, quand les gens me parlent des “standards”, j’ai assez d’expérience pour voir les standards venir et partir. Je ne suis pas très vieux, mais quand j’étais au lycée, le standard était le C++. Dans les années 90, le C++ était la norme. Pourquoi feriez-vous autrement ? Puis est venu Java, vers l’an 2000, et la combinaison de Java et XML était la norme.

Les gens disaient même que les universités de l’époque étaient devenues des “écoles Java”. C’était littéralement le terme du jour vers l’an 2000 ; les gens disaient : “Ce n’est plus une université d’informatique, c’est juste une école Java.” Quelques années plus tard, lorsque j’ai fondé Lokad, le langage de programmation pour tout ce qui était pertinent pour les statistiques était encore R. Python était encore très marginal, et R dominait absolument le domaine en termes d’analyse statistique.

À mesure que nous progressons en termes de langages de programmation, le C++ a disparu. Microsoft a introduit C# en 2002 et la plateforme .NET, qui a cannibalisé une partie importante de l’écosystème C++. Une grande partie des développeurs C++ dans le monde travaillaient chez Microsoft, une entreprise très importante. Ce que je veux dire, c’est qu’il y a eu une évolution continue et chaque année, les gens considèrent cela comme s’il y avait une norme, mais cette norme change tout le temps.

JavaScript existait depuis 20 ans, mais ce n’était rien de significatif. Puis, un livre publié vers 2009 ou 2012 intitulé “JavaScript: The Good Parts” a révélé que JavaScript n’était pas complètement insensé. Vous pouviez utiliser JavaScript pour un vrai projet sans perdre la raison ; il vous suffisait de vous en tenir aux bonnes parties. Soudain, JavaScript était très populaire et les gens ont commencé à l’utiliser côté serveur avec un système appelé Node.js.

Python n’a pris de l’importance que récemment, après que la communauté Python ait effectué une mise à niveau difficile de la version 2.7 à la version 3.x. À la fin de cette mise à niveau, l’intérêt pour Python a été renouvelé. Cependant, Python présente de nombreux dangers à l’avenir. Ce n’est pas un très bon langage selon les normes du 21e siècle. C’est un langage vieux de 30 ans et il montre son âge. Si vous voulez quelque chose de meilleur dans tous les domaines, sauf la maturité, vous pouvez vous tourner vers Julia. Julia est supérieur à Python dans presque tous les domaines de la science des données, sauf en termes de maturité, où Julia est encore en retard de plusieurs années.

Il y a de nombreuses évolutions en cours et il est facile de confondre l’état de l’industrie avec quelque chose qui est censé être une norme durable. Par exemple, dans l’écosystème Apple, il y avait Objective-C, puis Apple a décidé de produire Swift comme remplacement, qui remplace maintenant Objective-C. Le paysage des langages de programmation est encore en pleine évolution et bien que cela prenne du temps, si nous regardons l’écosystème dans dix ans, il y aura probablement une quantité significative d’évolution. Python ne pourrait pas émerger comme le langage de programmation dominant, car il existe de nombreuses options concurrentes qui apportent de meilleures réponses.

Question : Les entreprises alimentaires et les startups du commerce électronique pensent souvent qu’elles peuvent remporter la bataille avec des équipes de science des données et des langages polyvalents. Quel serait votre argument de vente principal pour les amener à affiner cette approche et à leur faire réaliser qu’elles ont besoin de quelque chose de plus spécifique au problème ?

Comme je l’ai dit, c’est le problème de l’effet Dunning-Kruger. Vous donnez à un ingénieur logiciel un système de programmation linéaire en nombres entiers mixtes pour faire de la programmation entière, et une semaine plus tard, cette personne pensera qu’elle est devenue soudainement une experte en optimisation discrète. Alors, comment je remporte la bataille ? En vérité, nous ne les remportons généralement pas. Ce que je fais, c’est décrire la façon dont les catastrophes se dérouleront.

C’est simple lorsque vous utilisez des blocs génériques de technologie pour créer des prototypes fantastiques. Ces prototypes fonctionnent brillamment grâce à l’illusion de Star Wars - vous avez juste votre morceau de technologie en isolation. Mais lorsque ces entreprises commencent à essayer de mettre ces choses en production, elles rencontreront des difficultés, la plupart du temps en raison de problèmes très banals. Elles seront confrontées à des problèmes d’intégration continus, pas comme Google ou Microsoft ou Amazon, qui peuvent se permettre d’avoir mille ingénieurs pour gérer toute la plomberie.

TensorFlow, par exemple, est difficile à intégrer. Google dispose des 1000 ingénieurs nécessaires pour intégrer TensorFlow dans tous leurs pipelines de données et applications à des fins spécifiques. Mais la question est, les startups ou les entreprises de commerce électronique peuvent-elles se permettre d’avoir autant de personnes pour s’occuper de toute la plomberie ? En général, la réponse est non. Les gens imaginent qu’en choisissant simplement ces outils, ils pourront choisir les choses à la carte et les assembler, et que cela fonctionnera magiquement. Mais ce n’est pas le cas. Cela nécessite une énorme quantité d’ingénierie.

Au fait, certains éditeurs de logiciels d’entreprise souffrent du même problème exact. Ils ont beaucoup trop de composants dans leur solution, ce qui explique pourquoi le déploiement d’une solution, sans aucune personnalisation, prend déjà des mois car il y a tellement de parties fragiles dans le système qui ne sont que vaguement intégrées. Cela devient très difficile.

Je suppose que c’était la dernière question. À la prochaine fois.