00:05 イントロダクション
02:50 2つの妄想
09:09 コンパイラパイプライン
14:23 これまでの話
18:49 輸送貨物の明細書
19:40 言語設計
23:52 未来
30:35 過去
35:57 戦いの選択
39:45 文法 1/3
42:41 文法 2/3
49:02 文法 3/3
53:02 静的解析 1/2
58:50 静的解析 2/2
01:04:55 型システム
01:11:59 コンパイラ内部
01:27:48 ランタイム環境
01:33:57 結論
01:36:33 今後の講義と視聴者の質問
説明
ほとんどのサプライチェーンはスプレッドシート（Excelなど）を介して実行されていますが、エンタープライズシステムは1年、2年、3年という長い期間にわたって導入されてきました。スプレッドシートはアクセス可能なプログラム表現性を提供しますが、それらのシステムは一般的には提供しません。一般的に、1960年代以来、ソフトウェア業界全体とそのプログラミング言語の共同開発が続いてきました。次の段階のサプライチェーンのパフォーマンスが、プログラミング言語の開発と採用、あるいはプログラム可能な環境の開発と採用によって主に推進されるという証拠があります。
フルトランスクリプト
このサプライチェーン講義シリーズへようこそ。私はジョアネス・ヴェルモレルです。今日は「サプライチェーンのための言語とコンパイラ」を紹介します。私はサプライチェーンの教科書でコンパイラについて議論されたことを覚えていませんが、このトピックは非常に重要です。このシリーズの最初の章である「製品指向のデリバリー」という講義で、プログラミングがサプライチェーンの専門家の投資した時間を活用する鍵であることを見てきました。プログラミングがなければ、彼らの時間を活用することはできず、サプライチェーンの専門家を使い捨ての存在として扱います。
さらに、この第4章では、前の2つの講義「サプライチェーンの数理最適化」と「サプライチェーンの機械学習」を通じて、これら2つの分野、最適化と学習は、過去のようにアルゴリズムとモデルの集まりであるのではなく、過去10年間でプログラミングパラダイムによって推進されるようになったことを見てきました。これらすべての要素がプログラミング言語の主要性を指摘しており、したがって、サプライチェーンの課題に対応するために設計されたプログラミング言語とコンパイラの問題が浮かび上がります。
この講義の目的は、サプライチェーンの目的に適したプログラミング言語の設計を解説することです。おそらく、貴社は独自のプログラミング言語を開発することはないでしょう。しかし、このトピックに対する洞察を持つことは重要です。それによって、お持ちのツールの適切さを評価し、貴社が直面するサプライチェーンの課題に対処するために取得するツールの適切さを評価することができます。さらに、この講義は、このトピックに対してまったく洞察を持たない人々がしばしばこの分野で犯す大きなミスを避けるのにも役立つでしょう。
まず、過去30年ほどの間、エンタープライズソフトウェアの世界で広まっている2つの誤解を解消しましょう。1つ目は、「レゴプログラミング」という誤解です。プログラミングは完全にバイパスできると考えられています。確かに、プログラミングは難しいものであり、製品や素晴らしいテクノロジーを通じて、プログラミング自体の難しさを完全に取り除き、子供でもできるような視覚的な体験に変えることができると約束するベンダーが常に存在します。
これは過去数十年間で何度も試みられ、常に失敗してきました。最良の場合、視覚的な体験を提供することを目的とした製品は、他のプログラミング言語と比較して特に簡単にマスターできるものではありませんでした。実際、たとえばMicrosoftの製品シリーズには、Visual Basic for ApplicationやVisual Studioなどの「Visual」シリーズがあります。これらの視覚的な製品は、90年代にプログラミングを純粋に視覚的な体験に変えることを目指して導入されました。しかし、これらのツールは非常に大きな成功を収めましたが、現在ではほとんど普通のプログラミング言語です。当初の視覚的な要素からはほとんど残っていません。
レゴアプローチが失敗したのは、根本的にはプログラミング構文のハードルではないからです。確かに、それはハードルですが、特に高度な自動化を展開する際に関与する概念をマスターすることと比較して、それは最小限のハードルです。ボトルネックはあなたの思考であり、プレイされている概念の理解が構文よりもはるかに重要です。
2つ目の誤解は、「スターウォーズテック」という誤解であり、素晴らしいテクノロジーを簡単にプラグアンドプレイできると考えるものです。この誤解は、ベンダーや社内プロジェクトにとって非常に魅力的です。実際には、素晴らしいNoSQLデータベースを導入するだけで済む、または素晴らしいディープラーニングスタックを取り入れることができる、またはグラフデータベースや分散アクティブフレームワークなどがあると考えることが非常に誘惑されます。しかし、このアプローチの問題は、テクノロジーをスターウォーズのように扱っていることです。機械の手があれば、主人公は単に機械の手を手に入れて使えるようになります。しかし、現実では、統合の問題が支配的です。
スターウォーズは、抗生物質が必要であり、手を使えるようにするためには長い再教育が必要であるという事実を無視しています。また、機械的なので手のメンテナンスプログラムも必要ですし、電源の問題はどうなるのでしょうか。これらの問題はすべて無視されます。素晴らしいテクノロジーをプラグインするだけでうまくいくわけではありません。統合の問題が支配的であり、たとえば大規模なソフトウェア企業では、ほとんどのソフトウェアエンジニアが素晴らしいクールなテクノロジーに取り組んでいるわけではありません。ほとんどの大規模ソフトウェアベンダーのエンジニアリングチームの大部分は、すべてのパーツの統合に専念しています。
モジュール、コンポーネント、またはアプリがある場合、それらをすべて結びつけ、それらを結びつけようとすると問題が発生するため、多くのエンジニアが必要です。統合のすべてのハードルを乗り越えた後でも、システムの任意の部分を変更すると、システムの他の部分に問題が発生する傾向があるため、多くのエンジニアリングチームが問題を修正するために追いかける必要があります。
ちなみに、興味深いことに、クールなテクノロジーに関連するもう1つの問題は、エンジニアの間で作られるダニング・クルーガー効果です。クールなテクノロジーをスタックに導入すると、エンジニアはほとんど理解していないテクノロジーをいじくり回すだけで、突然AIの専門家のように思い込むようになります。これはダニング・クルーガー効果の典型的な例であり、それはソリューションにドロップされるクールなテクノロジーの数と非常に強く関連しています。結論として、これらの2つの妄想を持っていることから、プログラミングの問題を本当に回避することはできないことがわかります。困難な部分を含めて、機能的に対処する必要があります。
さて、それを言ったとしても、プログラミング言語について興味深いことは、エンタープライズソフトウェアベンダーがプログラミング言語を偶然にも繰り返し再発明していることです。実際に、サプライチェーンでは、設定可能性への猛烈なニーズがあります。前の講義で見たように、サプライチェーンの世界は多様であり、問題は数多くあります。したがって、サプライチェーンソフトウェア製品では、設定可能性への非常に強いニーズがあります。逸話的に言えば、これがなぜソフトウェアの設定が通常数ヶ月または数年のプロジェクトになるのかです。これは、この設定には非常に複雑な要素が含まれているためです。
設定は、ボタンやチェックボックスだけでなく、トリガー、数式、ループ、およびそれに付随するさまざまなブロックを持つことがあります。すぐに制御を失い、これらの設定を通じて得られるものは、新興のプログラミング言語です。ただし、新興のプログラミング言語であるため、非常に劣ったものになる傾向があります。
実際のプログラミング言語のエンジニアリングは、確立されたエンジニアリングタスクです。実際、プロダクショングレードのコンパイラのエンジニアリングについての本は数十冊あります。コンパイラは、通常テキスト命令を機械語またはより低レベルの命令に変換するプログラムです。プログラミング言語が存在する場合、コンパイラが関与します。たとえば、Excelスプレッドシート内では、数式があり、Excelにはそれらの数式をコンパイルして実行するための独自のコンパイラがあります。おそらく、ほとんどの聴衆は、自分のプロフェッショナルな人生全体でコンパイラを使用してきたでしょうが、それに気づいていないかもしれません。
図では、典型的なパイプラインが示されており、おそらく聞いたことのあるほとんどのプログラミング言語（Python、JavaScript、Java、C#など）にこの原型が当てはまります。これらの言語は、ここで概説されているものと本質的に似たパイプラインを持っています。コンパイラパイプラインでは、一連の変換があり、プロセスの各段階でプログラム全体を表す表現があります。コンパイラのエンジニアリングは、一連の明確に識別された変換を持ち、プロセスの各段階でプログラム全体で作業していることが特徴です。ただし、表現方法が異なります。
アイデアは、各変換が特定の問題に対応する責任を持つことです。それらの問題に対処し、次の変換に移ることができます。通常、各段階で、マシンレベルのコードに近づいていきます。コンパイラはスクリプトから始まり、関心のあるプログラミング言語の構文に非常に近い変換で開始します。これらの初期の変換では、コンパイラが実行不可能な有効なプログラムを表さないスクリプトを変換することを防ぐ構文上のミスをキャプチャします。この講義の後半でコンパイラパイプラインを詳しく見ていきます。
この講義は、このシリーズの第4章の第5回目の講義です。第1章では、私はサプライチェーンを研究対象とした視点と実践としてのサプライチェーンについて述べました。第2章では、サプライチェーンで見られる状況に対処するための適切な方法論を調査しました。私たちは見てきたように、ほとんどのサプライチェーンの状況はかなり敵対的な性質を持っているため、企業内外のすべての関係者からの敵対的な行動に対応するための戦略と方法論が必要です。
第3章はサプライチェーンの人材に捧げられており、サプライチェーンの問題自体の研究に完全に捧げられています。私たちは、私たちが明らかにしている問題と、この問題に対処するために想像できる解決策の種類を混同しないように非常に注意する必要があります。これらは2つの異なる関心事です：問題を解決策から分離する必要があります。
このシリーズの講義の第4章である現在の章は、サプライチェーンの補助科学に捧げられています。これらの補助科学はサプライチェーンそのものではありませんが、現代のサプライチェーンの実践に非常に役立ちます。私たちは現在、抽象化の段階を進んでいます。この章では、コンピューティングの物理学から始め、アルゴリズム、ソフトウェアの領域に移りました。サプライチェーンに非常に興味深い数学的最適化を紹介しました。また、これは機械学習の基礎でもあります。
今日は、プログラミングパラダイムを実装するために必要な言語とコンパイラを紹介します。言語とコンパイラのトピックは、聴衆にとって驚きかもしれませんが、私はこの時点でそれほど驚くことではないと思います。数学的最適化と機械学習は、現在ではプログラミングパラダイムを通じてアプローチする必要があることを見てきました。それがどのように実装されるかという問題につながり、それが今日のトピックです。
これはこの講義の残りの要点のまとめです。まず、プログラミング言語の歴史と市場に関する高レベルな観察から始めます。サプライチェーンの将来と過去を代表する産業を見直します。その後、プログラミング言語とコンパイラの設計に徐々に入り、コンパイラの設計に関わる低レベルの問題や技術的な詳細について進んでいきます。
1950年代以来、数千のプログラミング言語が製品化されてきました。推定にはばらつきがありますが、製品化のために使用されたプログラミング言語の数はおそらく1000から10000の範囲になるでしょう。それらの言語の多くは、単なるバリエーションや相互関係にあるものであり、時にはコンパイラのコードベースがわずかに異なる方向に分岐しただけのものです。非常に大きなエンタープライズソフトウェア企業のいくつかは、独自のプログラミング言語を導入することでかなり成長しました。たとえば、SAPは1983年にABAPを導入し、Salesforceは2006年にApexを導入し、Microsoftも1975年にAltair BASICを開発することでWindowsの前にスタートしました。
歴史的には、90年代を覚えている聴衆の方々は、当時のベンダーが第3世代や第4世代のプログラミング言語をマーケティングしていたことを思い出すかもしれません。実際には、第1世代、第2世代、第3世代、第4世代など、世代ごとによく識別されたシリーズがあり、第5世代に至るまで、本質的には世代の数え方をやめていました。最初の3〜4十年間、これらのプログラミング言語はすべて、より高い抽象化レベルに向けた素晴らしい進化を遂げていました。しかし、90年代末には、抽象化の度合い以上の方向性が既に多く存在していました。それは使用ケースによって異なります。
新しいプログラミング言語の作成は、何度も行われてきました。それは確立されたエンジニアリングの分野であり、非常に実践的な観点からこの主題に捧げられた本が数冊存在します。新しいプログラミング言語のエンジニアリングは、非常に確実性が高く予測可能な実践です。今日知られていることや利用可能な知識を考慮に入れる適切なエンジニアリングを行えば、望む結果を得ることがほぼ確実です。
そうしたことから、供給チェーンの目的に特化したプログラミング言語はどうでしょうか？実際には、生産性、信頼性、さらには供給チェーンのパフォーマンスの面で大きなメリットがあります。
この問いに対応するためには、未来を見る必要があります。幸いなことに、未来を見る最も簡単な方法は、過去30年ほどの間、常に他の業界よりも10年進んでいる業界を調べることです。それがビデオゲーム業界です。現在、これは非常に大きな産業であり、規模の比較として、ビデオゲーム業界は世界の航空宇宙産業の2/3に相当し、航空宇宙産業よりもはるかに速い成長を遂げています。10年後には、ビデオゲームは実際には航空宇宙産業よりも大きくなるかもしれません。
ビデオゲーム業界の興味深い点は、非常に確立された構造を持っていることです。まず、ゲームエンジンがあり、その2つのリーダーはUnityとUnrealです。これらのゲームエンジンには、超高度なリファインド3Dグラフィックスに興味のある低レベルのコンポーネントが備わっており、コードのインフラストラクチャのレベルを示しています。いくつかの企業が非常に複雑な製品であるゲームエンジンを開発し、これらのエンジンは業界全体で使用されています。
次に、ゲームスタジオがあり、すべてのゲームに対してゲームコードを開発します。ゲームコードは通常、開発中のゲームに固有のコードベースになります。ゲームエンジンには、非常にハードコアなソフトウェアエンジニアが必要であり、彼らは非常に技術的に熟練していますが、ゲームについてはあまり詳しく知りません。ゲームコードの開発は、純粋な技術的なスキルにおいてはあまり集中的ではありません。ただし、ゲームコードを開発するソフトウェアエンジニアは、自分たちが取り組んでいるゲームを理解する必要があります。ゲームコードはゲームメカニクスのプラットフォームを確立しますが、詳細な仕様は指定しません。
このタスクは、通常、ゲームデザイナーが管理します。彼らはソフトウェアエンジニアではありませんが、ゲームコードに関わるエンジニアリングチームから提供されるスクリプト言語でコードを書きます。これらの3つのステージがあります。ゲームエンジンでは、超技術的なハードコアなソフトウェアエンジニアがコアのビルディングブロックを作成します。スタジオでは、ゲームメカニクスのプラットフォームとして、通常1つのゲームごとにエンジニアリングチームがゲームコードを開発します。最後に、ゲームデザイナーはソフトウェアエンジニアではありませんが、ゲームの専門家であり、パイプラインの最後のクライアントであるゲーマーを満足させるための動作を実装します。
現在、ゲームコードは頻繁にファンベースに公開されており、ゲームデザイナーはルールを書いたり、ゲームを変更したりすることができますが、ゲームの一般的な消費者であるファンも同様にそれを行うことができます。業界には興味深い逸話があります。たとえば、非常に成功したゲームであるDota 2は、既存のゲームの改変として始まりました。最初のバージョンであるDotaは、ゲームWorld of Warcraft 3の純粋なファンベースの改変でした。ゲームルールのレベルでのこの程度の設定可能性とプログラム可能性は非常に広範であり、既存の商業ゲームであるWorld of Warcraft 3から完全に新しいゲームを作成し、それが2番目のバージョンを通じて独自の大規模な商業的成功になることが可能でした。これは興味深いことであり、ゲーム業界を見ることで、供給チェーン業界にとって何を意味するのか考えることができます。
さて、私たちはどのような類似点を見つけることができるでしょうか。非常に困難なアルゴリズムの部分、低レベルのインフラストラクチャ、数学的最適化や機械学習などの核となる技術的なビルディングブロックを担当する供給チェーンエンジンを考えることができます。アイデアは、各供給チェーンに対して、関連するすべてのデータをまとめ、アプリケーション全体を統合するためのエンジニアリングチームが必要になるということです。
最初の段階として、供給チェーンの専門家であるゲームデザイナーの相当物が必要になります。これらの専門家はソフトウェアエンジニアではありませんが、供給チェーンの予測的最適化を実装するために必要なすべてのルールとメカニズムを簡略化されたコードを通じて書く人々です。ゲーム業界は、今後の数十年間における供給チェーン業界で起こりそうなことの生き生きとした例を提供しています。
これまでのところ、供給チェーンにおけるゲーム業界のアプローチは、一部の企業を除いてまだSFの域を出ていません。私は、それらの企業のほとんどがLokadのクライアントであると考えています。今日の話題に戻りますが、以前の講義でExcelがこの業界でのナンバーワンのプログラミング言語であることを見てきました。ちなみに、プログラミング言語としてのExcelは、関数型リアクティブプログラミング言語であり、独自のクラスです。
最近、データサイエンスのセットアップを使用して供給チェーンをアップグレードすると提案しているベンダーから聞いたことがあるかもしれません。しかし、過去10年間の私の簡単な観察から、これらのイニシアチブの大部分は失敗しているということがわかります。これは既に過去のことであり、なぜ失敗したのかを理解するために、関与するプログラミング言語のリストを見る必要があります。Excelを見てみると、基本的に2つのプログラミング言語が関与していることがわかります：Excelの数式とVBAです。VBAは必須ではありません。ExcelのVLOOKUPだけで十分な場合もあります。通常、1つのプログラミング言語だけで済みますし、ソフトウェアエンジニアでない人でもアクセスできます。
一方、Excelの機能をデータサイエンスのセットアップで再現するために必要なプログラミング言語のリストは非常に広範です。データにアクセスするためにSQLと、複数のSQLの方言が必要になるかもしれません。コアロジックを実装するためにPythonが必要です。ただし、Python単体では遅い傾向があるため、NumPyのようなサブ言語が必要になるかもしれません。この時点では、機械学習や数学的最適化についてはまだ何も行っていません。真のハードコアな数値解析のためには、PyTorchなどの別のプログラミング言語が必要です。これらの要素がすべて揃ったら、すでに多くの動くパーツがありますので、アプリケーション自体の構成はかなり複雑になります。構成が必要で、この構成はJSONやXMLなどの別のプログラミング言語で書かれます。これらは非常に複雑なプログラミング言語ではないと言えるかもしれませんが、プレートに追加するためのものです。
動くパーツが多い場合、通常はソフトウェアを生成するために必要なすべてのコンパイラや単調な手順を実行できるビルドシステムが必要です。ビルドシステムには独自の言語があります。従来のアプローチはMakeという言語ですが、他にも多くの言語があります。さらに、Excelは結果を表示できるため、ユーザーに表示する方法と視覚化する方法が必要です。これにはJavaScript、HTML、CSSの組み合わせが使用され、リストにさらに言語が追加されます。
この時点で、プログラミング言語の長いリストがあり、実際のプロダクションセットアップはさらに複雑になる可能性があります。これが、過去10年間にこのデータサイエンスパイプラインに取り組もうとしたほとんどの企業が圧倒的に失敗し、実際にはExcelにとどまっている理由です。その理由は、Excelの場合とは異なり、ほぼ12のプログラミング言語を習得する必要があるからです。実際の供給チェーンの問題にはまだ触れていないのに、何かを始めるための技術的な問題について議論しているだけです。
さて、供給チェーン向けのプログラミング言語はどのようなものになるでしょうか。まず、言語の内部に何が含まれ、何がライブラリに属するかを決める必要があります。実際、プログラミング言語では、機能をライブラリにオフロードすることが常に可能です。例えば、Cプログラミング言語を見てみましょう。Cは比較的低レベルのプログラミング言語とされており、Cにはガベージコレクターがありません。しかし、Cプログラム内でサードパーティのガベージコレクターをライブラリとして使用することは可能です。ガベージコレクションがCプログラミング言語の第一級の要素ではないため、構文は比較的冗長で煩雑になりがちです。
供給チェーンの目的には、数理最適化や機械学習などの懸念事項があり、通常はライブラリとして扱われます。したがって、プログラミング言語があり、それらの懸念事項は基本的にサードパーティのライブラリにオフロードされます。しかし、供給チェーン向けのプログラミング言語を設計する場合、それらの懸念事項をプログラミング言語自体の第一級の要素として設計することは非常に意味があります。また、リレーショナルデータを言語の一部として第一級の要素として持つことも意味があります。供給チェーンでは、エンタープライズソフトウェアの一部であるアプリケーションランドスケープには、SQLデータベースなどのリレーショナルデータベースがあります。現在存在するほとんどのエンタープライズソフトウェア製品は、そのコアにリレーショナルデータベースを持っているため、供給チェーンの目的においてデータに触れたいと思った時点で、実際のデータはリレーショナルな性質を持つデータとのやり取りになるという現実があります。データは、さまざまなアプリケーションを駆動するためのさまざまなデータベースから抽出されたテーブルのリストとして表れ、各テーブルには列またはフィールドのリストがあります。
これは、言語内にリレーショナルデータを持つことが非常に意味があるということです。さらに、ユーザーインターフェース（UI）とユーザーエクスペリエンス（UX）についてはどうでしょうか？Excelの強力な点の1つは、それらすべてが言語に完全に組み込まれていることです。つまり、プログラミング言語とその後にさまざまなサードパーティのライブラリを扱う必要はありません。それらすべてが言語の一部です。それらすべてが第一級の要素として作られることも、供給チェーンにとって非常に関心があることです。少なくとも、Excelが供給チェーンにとってどれだけ優れているかについて考える場合はそうです。
さて、言語設計では、文法は、新しく導入したプログラミング言語に従って有効なプログラムを定義するルールの形式的表現を表します。基本的に、テキストの一部から始めて、最初にレクサーを適用します。レクサーは、特定のアルゴリズムまたは小さなプログラムの特定のクラスです。レクサーは、書いたプログラムのテキストの一部をトークンのシーケンスに分解します。レクサーは、プログラミング言語内で使用されるすべての変数とシンボルを分離します。文法は、トークンのシーケンスをプログラムの実際の意味に変換し、実行するために必要な正確で曖昧性のない操作のセットを定義します。
文法自体は、言語内に内部化したい関心事と外部化したい概念の間のトレードオフとして一般的にアプローチされます。例えば、リレーショナルデータを外部の関心事としてアプローチする場合、プログラマは、プログラミング言語内でそれらの操作を手動で実行するために、辞書、ルックアップ、ハッシュテーブルなどの専門のデータ構造を導入する必要があります。文法がリレーショナル代数を内部化することを望む場合、プログラマは通常、リレーショナルロジックをそのままリレーショナル形式で直接書くことができます。しかし、それは、文法が負担として持つ必要があるすべてのリレーショナル制約とリレーショナル代数が急に負担の一部になることを意味します。
供給チェーンの観点からは、エンタープライズソフトウェアでリレーショナルデータが非常に一般的であるため、文法が言語の文法レベルで直接リレーショナル関心事を処理することは重要です。
コンピュータ科学において、文法は非常に研究されている主題です。数十年前から存在しており、それでも、エンタープライズソフトウェアベンダーが最も苦労する分野です。実際、複雑な設定が関与する場合には、自然に発生する偶発的なプログラミング言語が必ず現れます。条件、トリガー、ループ、および応答がある場合、それ自体が言語を扱う必要があります。
文法がない場合、アプリケーションに変更を加えると、システムの実際の動作に無秩序な結果が生じます。ところで、これはなぜエンタープライズソフトウェアのバージョンをアップグレードするのが通常非常に複雑なのかも説明しています。設定は同じであるはずですが、実際に次のバージョンのソフトウェアで同じ設定を実行しようとすると、まったく異なる結果が得られます。これらの問題の根本原因は、設定の意味を定義する文法と確立された形式化された意味論の欠如です。
文法を表現する典型的な方法は、Backus-Naur形式（BNF）を使用して形式的に行うことです。画面上に表示されているのは、米国の郵便住所を表すミニプログラミング言語です。等号を持つ各行は生成規則を表します。左側には非終端記号があり、等号の右側には終端および非終端記号のシーケンスがあります。終端記号は赤色で表示され、これ以上派生できない記号を表します。非終端記号は角かっこ内にあり、さらに派生できます。この文法は完全ではありません。完全な文法には追加の生成規則が必要です。このスライドを比較的簡潔に保つために、ここでは省略しました。
文法は、プログラミング言語の構文に関して非常に明確に定義するものであり、曖昧さがないことも保証します。ただし、Backus-Naur形式で書かれているからといって、それが有効な文法であるか、さらには良い文法であるとは限りません。良い文法を持つためには、それ以上のことを行う必要があります。良い文法を特徴づける数学的な方法は、文脈自由文法を持つことです。文脈自由文法とは、生成規則が左右にあるシンボルに関係なく、任意の非終端記号に適用できると言われています。アイデアは、文脈自由文法では、生成規則を任意の順序で適用し、一致または派生が見つかったらすぐに適用することです。
文脈自由文法から得られるものは、その文法に変更を加え、その変更が曖昧さを生む場合、コンパイラは曖昧さが発生するプログラムをコンパイルできなくなるという文法です。これは、長期間にわたって設定を維持する意図がある場合に特に重要です。サプライチェーンでは、ほとんどのエンタープライズソフトウェアが非常に長寿です。2〜3十年間運用されているエンタープライズソフトウェアのデータを抽出することは珍しくありません。Lokadでは、100以上の企業にサービスを提供しており、特に大企業では30年以上稼働しているシステムからデータを抽出することが非常に一般的です。
文脈自由文法を使用すると、この言語に変更を加える必要がある場合（そして、ここで「言語」と言うと、設定のような基本的なものを指すことができます）、この変更を適用する際に生じる曖昧さを特定することができる保証が得られます。これにより、システムを別のシステムにアップグレードする際に困難が生じることを防ぐことができます。
文法について何も知らない場合、人々は手動でパーサーを作成します。文法について聞いたことがない場合、ソフトウェアエンジニアはプログラムの解析バージョンを表すツリーのようなものを無秩序に作成するプログラムを作成します。その問題は、プログラムのセマンティックが、持っているプログラムのバージョンに非常に特化したものになることです。したがって、このプログラムを変更すると、セマンティックが変わり、異なる結果が得られます。つまり、同じ設定でも、サプライチェーンの動作が異なる可能性があります。
title: “文法の重要性と静的解析”
幸いなことに、2004年にBrian Fordが「Parsing Expression Grammars: A Recognition-Based Syntactic Foundation」という論文を発表し、小さな突破口が生まれました。この研究により、Fordはフィールドに存在する種類の偶発的なアドホックパーサーを形式化する方法をコミュニティに提供しました。例えば、これらの文法はParsing Expression Grammars（PEGs）と呼ばれ、PEGsを使用することで、これらの半偶発的な経験的なパーサーを実際の形式文法に変換することができます。
プログラミングは非常に難しいものであり、人々は多くのことを間違えます。もし簡単なら、最初からプログラミングは必要ありませんでした。良いプログラミング言語は、エラーを特定し修正するのにかかる時間を最小限に抑えます。これはプログラミング言語の最も重要な側面の一つであり、コードを書く人にとって生産性を確保するために重要です。
次の状況を考えてみましょう。コードを書く際に、タイプミスのようなエラーが入力時に検出できる場合、Microsoft Wordの赤い下線のようなものであれば、エラーを修正するためのフィードバックループは最短で10秒になります。これは理想的な状況です。もしエラーがプログラムを実行する際にのみ検出できる場合、フィードバックループは少なくとも10分になります。サプライチェーンでは、処理するデータセットが大きいことがよくあり、プログラムがすべてのデータを処理するのに数秒かかることは期待できません。その結果、問題がランタイムでのみ発生する場合、フィードバックループは10分以上になります。
もしスクリプトが完了した後にエラーが検出される場合、つまりプログラムにエラーがあるが失敗しない場合、フィードバックループは約10時間以上かかります。プログラムを実行してから数値結果やKPIを検査する必要があるため、10秒から10分、そして10時間になりました。
さらに悪いシナリオがあります。操作するプラットフォームが厳密に決定論的ではない場合、つまり同じ入力とデータでも異なる結果が得られる場合があります。これは奇妙なことではありません。サプライチェーンでは、モンテカルロシミュレーションなどが行われることがあります。結果にランダム性がある場合、一部の場合のみ失敗することがあります。このような状況では、フィードバックループは通常10日以上かかります。つまり、10秒から10日になり、このフィードバックループを短縮することには非常に大きな利益があります。静的解析は、プログラムを実行せずに問題、エラー、または障害を検出するために適用できる技術の一連を表します。静的解析では、プログラムを実行する必要すらなく、Microsoft Wordのタイプミスのように、人々が入力中にエラーをリアルタイムで報告できます。より一般的には、問題をより早いフィードバッククラスに移動させるために、問題を特定するのに数日かかるものを数分または数秒に変えることに強い関心があります。
供給チェーンの観点からは、以前の講義の1つで供給チェーンは多くの混乱を予想できることがわかりました。ソフトウェアの次のバージョンを待つ従来のリリースサイクルは持てません。時には関税の変更、運河に閉じ込められたコンテナ船、パンデミックなどの非常事態が発生します。これらの緊急事態では、緊急の修正が必要であり、プログラミング言語上で行うことができる静的解析の量が、コードを入力する際にリアルタイムでキャプチャされなかったミスによる本番環境での混乱の程度をほぼ定義します。非常事態は珍しいように思えるかもしれませんが、実際には供給チェーンでの驚きは非常に一般的です。
一般的なプログラミング言語では一般的な状況ですべてのエラーを検出することは不可能であるという数学的な証明があります。たとえば、プログラムが完了することを証明することさえ不可能であり、自分が書いたものが単に無限に実行され続けることを保証することはできません。
静的解析では、通常、3つのカテゴリが得られます。コードの一部はおそらく良いものであり、一部はおそらく悪いものであり、中間の多くのものについてはわかりません。アイデアは、「わからない」から「悪いコード」に移行するほど、プログラムが有効であることをコンパイラに納得させるために必要な努力が増えるということです。したがって、コンパイル時にプログラムが実際に実行される前に、プログラミング言語にコードが正しいことを納得させるためにどれだけの努力を投資するかと、プログラムにどれだけの保証を持ちたいかとのバランスを取る必要があります。これは生産性の問題です。
さて、静的解析で検出される典型的なエラーのクイックリストには、カンマや括弧の忘れなどの構文エラーが含まれます。Bash（Linuxのシェル言語）のような一部のプログラミング言語では、実行前に構文エラーを明示的に示すことさえできません。静的解析では、関数の呼び出し時に不正な型や不正な引数のエラーも検出できます。
アクセスできないコードも検出できます。つまり、コード自体は問題ありませんが、そのコードの一部に到達することなくプログラム全体が実行される可能性があります。これは、未使用のコードや忘れられたロジックの接続のようなものです。無関係なコードは、コードが実行されますが最終的な出力に影響を与えない問題です。これは到達できないコードのバリエーションです。
コンピューティングリソースの過剰消費も検出できます。これは、プログラムの実行に必要な計算リソース（メモリ、ストレージ、CPUなど）が、プログラムに許容できる範囲を大幅に超えるコードを指します。静的解析を通じて、特定の時間枠内で計算を完了するという制約を考慮して、コードブロックが必要なリソースよりもはるかに多くのリソースを消費することを証明することができます。プログラムを1時間実行してタイムアウトにより失敗するよりも、コンパイル時に失敗させたいのです。これは非常に低い生産性につながります。
ただし、静的解析には注意が必要です。入力するたびに、常に無効なプログラムを扱っています。キーストロークごとに、有効なプログラムを無効なものに変換しています。この状況のための業界レベルのソリューションは、Language Server Protocolと呼ばれています。このツールはプログラミング言語とともに提供され、入力中のプログラムに対するリアルタイムのエラーフィードバックにおいて最先端の技術です。
Language Server Protocolを介して、変数をクリックすると「定義に移動」という機能にアクセスできます。Language Server Protocolは基本的に状態を保持し、最後に正しいバージョンのプログラムと利用可能な注釈やセマンティクスを記憶します。これらの注釈や追加の情報は、追加のキーストロークを押したために無効なプログラムになった場合でも、壊れたプログラムを扱う際に保持されます。これは生産性の観点からは画期的な変化であり、緊急性の程度に関係なく、供給チェーンの目的において大きな違いを生み出します。
さて、型システムについて詳しく見てみましょう。大まかに言えば、型システムは、プログラム内のオブジェクトまたは操作する要素の分類を活用して、特定の相互作用が許可されるか禁止されるかを明確にするためのルールのセットです。たとえば、一般的な型には文字列、整数、浮動小数点数などがありますが、これらはすべて非常に基本的な型です。これにより、2つの整数を足すことが有効であることが定義されますが、文字列と整数を足すことは、JavaScriptを除いては有効ではありません（JavaScriptでは意味が異なるため）。
一般的に、型システムは研究課題であり、非常に抽象的になることがあります。明確にするために、混同されることがよくある2種類の型が存在します。まず、値の型は、プログラムが実際に実行されているときにのみ存在します。たとえば、Pythonでは、整数の配列の最初の要素を返す関数を考えてみましょう。この関数が返す値の型は整数になります。この観点から、すべてのプログラミング言語には型があります-すべての型が付いています。
次に、変数の型は、プログラムがコンパイルされて実行される前のコンパイル時にのみ存在します。変数の型に関する課題は、コンパイル時に変数に関する情報をできるだけ多く抽出することです。前の例に戻ると、Pythonでは、関数によって返される戻り値の型を特定することが可能であるかどうかは、コンパイル時には完全に強力に型付けされていないため、可能であるかどうかはわかりません。
サプライチェーンの観点からは、サプライチェーンの利益のために意図したことをサポートする型システムを探しています。問題やバグを早期に捕捉するためにできるだけ制約を設けたい一方で、興味のあるすべての操作を許可するためにできるだけ柔軟性を持たせたいと考えています。たとえば、日付と整数の加算を考えてみましょう。通常のプログラミング言語では、これは正当ではないと言うかもしれませんが、サプライチェーンの観点からは、日付があり、7日を追加したい場合、“date + 7"と書くことは意味があります。サプライチェーン計画には、日付を特定の日数だけシフトする多くの操作が含まれるため、日付と数値の間で加算を実行することが許可される代数を持つことが有用です。
型の観点からは、1つの日付を別の日付に追加することを許可したいですか？おそらくそうではないでしょう。しかし、2つの日付の差を引くことを許可したいですか？なぜでしょうか？それが前に発生する日付から別の日付を引くと、日数で表現されるデルタが得られます。これは計画に関与する計算に非常に適しています。
日付のトピックを続けると、サプライチェーンの観点での型システムが行うべきことについて考えると、興味深い特性もあります。たとえば、受け入れ可能な時間範囲を制限することはどうでしょうか？過去20年と未来20年の範囲外の日付は無効と言えます。プログラムのある時点で20年以上先の日付を操作する場合、ほとんどの業界では有効な計画ではない可能性が非常に高いです。ほとんどの場合、20年以上先の日常レベルでの操作を計画しません。したがって、通常の型だけでなく、サプライチェーンの目的により制約が厳しく、適切な方法でそれらを再定義することができます。
また、不確実性の側面もあります。サプライチェーン管理では常に先を見越していますが、残念ながら未来は常に不確かです。不確実性を受け入れる数学的な方法は、ランダム変数を介して行われます。不確かな将来の需要、リードタイム、顧客の返品などを表すために、言語にランダム変数を組み込むことは意味があります。
Lokadでは、サプライチェーンの予測最適化に特化したプログラミング言語Envisionを開発しています。Envisionは、SQL、Python、数理最適化、機械学習、ビッグデータの機能をすべて組み合わせたものであり、言語自体に組み込まれた第一級の市民として提供されています。この言語には、Webベースの統合開発環境（IDE）が付属しており、Webからスクリプトを書いて、すべての最新のコード編集機能を利用することができます。これらのスクリプトは、Lokad環境に統合された分散ファイルシステム上で動作するため、データレイヤーがプログラミング言語に完全に統合されています。
Envisionスクリプトは、クラウド全体を活用するために設計された複数のマシンで実行されます。スクリプトが実行されると、より高速に実行するために多くのマシンに広がります。画面上では、Envisionが使用するコンパイラパイプラインが表示されています。今日はこのプログラミング言語については議論しませんが、今日の講義の興味の対象はコンパイラパイプラインです。
まず、Envisionスクリプトを含むテキストから始めます。これは、ソフトウェアエンジニアではなく、サプライチェーンの専門家によって書かれたプログラムを表しています。このプログラムは、何を生産するか、何を補充するか、何を移動するか、価格を上げるか下げるかを決定するためのものです。これらのユースケースでは、何を生産するか、補充するか、移動するか、価格を調整するかについての意思決定が含まれます。スクリプトのテキストには、指示が含まれており、このスクリプトを処理し、Lossless Syntax Tree（LST）を取得することが目的です。 LSTは非常に特定の表現であり、1文字も破棄しません。意味のない空白も保持されます。これは、プログラムの自動的な書き換えが既存のコードを変更しないようにするためです。このアプローチにより、ツールがコードをシャッフルしたり、インデントを移動したり、コードを認識しにくくする他の混乱を引き起こす状況を避けることができます。
たとえば、基本的なリファクタリング操作では、変数の名前を変更し、プログラム内のすべての出現箇所を他の部分に触れずに変更することがあります。 LSTからAbstract Syntax Tree（AST）に移動すると、木を単純化します。この段階では、括弧は必要ありません。なぜなら、木構造がすべての操作の優先順位を定義しているからです。さらに、エンドプログラマーの利益のために提供された構文を削除するために、一連のデサグリング操作を実行します。
ASTからAbstract Syntax Graph（ASG）に移ると、木を平坦化します。このプロセスでは、高度にネストされた式を持つ複雑な文を基本的な文のシーケンスに分解します。たとえば、「a = b + c + d」という文は、2つの文に分割され、それぞれに1つの加算が含まれます。これがASTからASGへの移行中に正確に行われることです。
ASGから最適化グラフ（OG）に移ると、リレーショナル代数に関連する型整形とブロードキャストを実行します。前述のように、Envisionは言語内にリレーショナル代数を組み込んでいます。以前に何度も示唆されているように、Envisionはリレーショナル代数をリレーショナルデータベースやSQLデータベースのような第一級の市民として組み込んでいます。多くのリレーショナル操作があり、これらのリレーショナル操作が操作しているテーブルのスキーマに従って有効であることを確認します。これはASGからOGへの移行時に行われます。最適化グラフ（OG）は、コンパイラフロントエンドの最後のステップを表し、プログラムに適用される純粋で基本的なリレーショナル操作で構成されています。これらの要素は、SQLのようにリレーショナルな性質を持っています。
最適化グラフは「最適化」と呼ばれています。なぜなら、OGからOGへの変換が多数行われるからです。これらの変換は、リレーショナル代数を扱う際に、特定の方法で操作を組織化することでプログラムをより高速に実行できるからです。たとえば、SQLでは、フィルターと操作、または操作とフィルターの順序によって、データをまずフィルタリングしてから操作を適用する方がはるかに効率的です。これにより、操作が必要なデータにのみ適用されるようになり、効率が向上します。
Lokadでは、フロントエンドコンパイラの最後のステップはHigh Intermediate Representation（HIR）です。HIRは、コンパイラパイプラインのフロントエンドとバックエンドの間のクリーンで安定したドキュメント化された境界です。最適化グラフ（OG）がヒューリスティックによって常に変化するのに対して、HIRは安定しており、コンパイラのバックエンドに一貫した入力を提供します。さらに、HIRはシリアライズ可能であり、バイトのパックに簡単に変換できるため、計算を複数のマシンに分散するためには重要な特性です。
High Intermediate Representationから、私たちは「funcs」に移ります。Funcsは、まだ評価されていない値であり、分散実行内の計算の原子的なブロックを表します。たとえば、数十億行のテーブルから2つの巨大なベクトルを追加する場合、これらのベクトルのさまざまな部分を表す一連のfuncsがあります。各funcsは、2つのベクトルの一部を追加する責任を持ち、1つのマシンで実行されます。大規模な計算は、ワークロードを複数のCPUと複数のマシンに分散するため、この程度の分散が必要な場合にのみ、多くのfuncsに分割されます。Funcsは「遅延」呼ばれるのは、最初に評価されないためです。必要な時に評価されます。いくつかのfuncsが実際に計算される前に多くの計算が行われ、funcが計算されると、func自体はその結果に置き換えられます。
funcの中には、func内で実行される命令形の低レベルロジックを表す低レベル中間表現が含まれています。たとえば、ループや辞書アクセスを含むことがあります。最後に、この低レベル中間表現はバイトコードにコンパイルされ、コンパイラパイプラインの最終的なターゲットを表します。Lokadでは、.NETバイトコード（MSILとも呼ばれる）をターゲットにしています。
サプライチェーンの観点から見ると、この複雑なコンパイラパイプラインを通じて、私たちはMicrosoft Excelで見つけられる統合度を再現しています。言語はデータレイヤーとUI/UXレイヤーと統合されており、ユーザーはプログラムの出力をExcelスプレッドシートのように表示して操作することができます。ただし、Excelとは異なり、私たちはサプライチェーン管理のためにリレーショナルな概念を第一級の市民として受け入れ、数学的最適化と機械学習も取り入れています。
このパイプラインでは、数学的最適化と機械学習の両方がパイプライン全体を通過します。単にどこかにあるライブラリを呼び出すのではなく、機械学習をパイプラインの第一級の市民として持つことで、より理解しやすいエラーメッセージが可能になり、サプライチェーンの専門家にとって生産性の向上に大きな違いをもたらします。
最後に、現代のコンパイラはほとんど常に仮想マシンをターゲットにしますが、これらの仮想マシン自体も別の仮想マシンにコンパイルされます。画面上では、サーバーベースのセットアップで見つかる典型的なVMレイヤーは、Envisionスクリプトと非常に似ています。私はちょうどコンパイラパイプラインを紹介しましたが、基本的には、Pythonスクリプトやサーバーから操作されるExcelスプレッドシートを考える場合とほぼ同じスタックになります。コンパイラを設計する際には、コードを注入するレイヤーを選択します。レイヤーが深いほど、対処しなければならない技術的な問題が増えます。レイヤーを選択するには、解決すべき一連の問題があります。
まず、セキュリティがあります。メモリをどのように保護し、プログラムがアクセスできるものとできないものは何ですか？一般的なプログラミング言語を使用している場合、オプションは限られます。ゲストオペレーティングシステムレベルで操作する必要があるかもしれませんが、それでも非常に安全ではないかもしれません。サンドボックス化する方法はありますが、非常にトリッキーですので、それ以下に行く必要があるかもしれません。
次に、興味がある低レベルの機能があります。たとえば、より高速な実行を実現するために、計算リソースの量を減らすことが重要な場合があります。メモリとスレッドを管理するために十分に低いレベルに行くことを選択することができます。ただし、このパワーには、実際にメモリとスレッドを管理する責任が伴います。
三番目に、ガベージコレクション、スタックトレース、デバッガ、プロファイラなどの便利な機能があります。通常、コンパイラ周りの計測は、コンパイラ自体よりも複雑です。利点を得ることができる便利な機能の量は過小評価されるべきではありません。
四番目に、リソースの割り当てに関する懸念事項があります。デスクトップ上でExcelスプレッドシートを操作している場合、Excelはワークステーションのすべての計算リソースを消費することができます。しかし、EnvisionやSQLの場合、複数のユーザーに対応する必要があり、リソースの割り当て方法を決定する必要があります。さらに、Envisionでは複数のユーザーだけでなく、複数の企業に対応する必要があります。これは、Lokadがマルチテナントであるためです。これは、ほとんどのサプライチェーンにとって、計算リソースの必要性が非常に断続的であるためです。
通常、半時間または1時間程度の非常に集中的な計算が必要であり、次の23時間は何も必要ありません。その後、毎日繰り返します。1つの企業にハードウェアの計算リソースを割り当てると、そのリソースは90％以上の時間、使用されないままになります。したがって、ワークロードを多くのマシンと多くの企業に分散できるようにしたいのです。それも、さまざまなタイムゾーンで運営される企業の可能性があるかもしれません。
最後に、エコシステムの懸念事項があります。特定のレイヤーと特定のVMを選択してコンパイラをターゲットにすると、コンパイラをターゲットにしているものとまったく同じ仮想マシンとの統合とインターフェースが非常に便利になるはずです。これにより、エコシステムの問題が浮上します。ターゲットと同じレベルで何が見つかるか、スタック全体に関与するすべての細かい部分を再発明する必要がないようにするために、何が必要ですか？これが最後で重要な懸念事項です。
結論として、サプライチェーンの講義シリーズでここまで進んだ皆さん、おめでとうございます。これはおそらくこれまでで最も技術的な講義の1つです。コンパイラはおそらく非常に技術的な要素ですが、現代のサプライチェーンの現実は、すべてがプログラミング言語を介して中継されるということです。もはや生の、直接観測可能なサプライチェーンというものはありません。サプライチェーンを観察する唯一の方法は、アプリケーションランドスケープを構成するすべてのエンタープライズソフトウェアによって生成される電子レコードを介してです。したがって、プログラミング言語が必要であり、デフォルトではExcelがそのプログラミング言語となります。
ただし、Excel以上のものを実現したい場合、サプライチェーンの観点から「より良い」とは何を意味するのか、プログラミング言語の観点から何を意味するのかを真剣に考える必要があります。企業が適切な戦略や文化を持っていない場合、どんな技術も救いません。ただし、戦略と文化が適切であれば、ツールが本当に重要です。ツール、プログラミング言語を含むツールは、実行する能力、サプライチェーンの専門家から期待できる生産性、マクロ戦略をサプライチェーンが日々の数千の平凡な意思決定に変える際のパフォーマンスを定義します。サプライチェーンの課題に対処するために使用するツール、プログラミング言語の適切さを評価できることは非常に重要です。評価できない場合、それは完全なカルゴカルトです。
次回の講義はソフトウェアエンジニアリングについてです。今日はツールについて話しましたが、次回はツールを使用する人々と、仕事をうまく行うために必要なチームワークについて話します。講義は同じ曜日の水曜日、午後3時、パリ時間に行われます。
さて、質問を見てみましょう。
質問: サプライチェーン向けのソフトウェアを選択する際、テクノロジーに詳しくない企業は、コンパイラとプログラミングが自分たちのニーズに適しているかどうかをどのように評価すればよいですか？
まあ、典型的なサプライチェーンを運営する典型的な企業が、自分たちのサプライチェーンや輸送の要件に適したトラックを購入するための資格を持っていないとは言えません。あなたが専門家ではなく、トラックを再構築したり再設計したりすることができないからといって、それがあなたの輸送ニーズに適した良いトラックであるかどうかについて非常に確固たる意見を持つことができないわけではありません。ですので、テクノロジーに詳しくない企業が飛躍的な進歩を遂げてコンパイラの設計の専門家になる必要はないと言っているわけではありません。ただし、私たちはたった1時間半でかなりの進歩を遂げました。もっと詳細でゆっくりとした導入の10時間を追加すれば、サプライチェーンの目的に合った言語設計に必要なすべてを学ぶことができるでしょう。
専門家であることと、人々がスクーターをトラックだと偽って売りつけるほどの無知であることとの違いがあります。私が企業ソフトウェア設計の観点で観察したこの種の無知を自動車産業に翻訳すると、人々はスクーターをセミトラックだと主張し、逃げることができるでしょう。
この講義シリーズは補助科学についてのものであり、サプライチェーンの実践者になりたい人々がこれらの領域で専門家になる意図はありません。それでも、初級レベルの知識を持つことで、評価するのに非常に遠くまで行くことができます。ほとんどの場合、厳しい質問をするために十分な知識を持つだけで十分です。ベンダーが無意味な回答をする場合、それは良い印象を与えません。どのような技術的な質問をするかさえ知らない場合、騙される可能性があります。
私の提案は、非常にテクノロジーに詳しくなる必要はないということです。あなたは、穴を探し、全体が崩壊するか、実際に中身があるかどうかを評価するための初級アマチュアであるだけで十分に賢くなる必要があります。数学的最適化、機械学習、CPUなども同様です。重要なのは、詐欺的なものと正当なものの違いを知ることです。
質問: 既存のプログラミング言語がサプライチェーン向けに設計されていないという問題に直接取り組みましたか？
これは非常に良い質問です。まったく新しいプログラミング言語を設計することは完全にばかげて見えるかもしれません。なぜ既に確立されているPythonなどのものを選ばず、必要な小さな修正を加えるのでしょうか？それも選択肢でした。問題は、これらの言語に何を追加する必要があるかではなく、何を削除する必要があるかです。
Pythonに対する私の主な懸念は、確率的代数や関係代数が組み込まれていないことではありません。私の一番の批判は、それが完全に能力のある汎用プログラミング言語であり、したがって、サプライチェーンに関係のないオブジェクト指向プログラミングなどの概念に書き込む人をさらすことです。問題は、言語を取って何かを追加することではなく、言語を取ってたくさんのものを削除しようとすることでした。ただし、問題は、既存のプログラミング言語からものを削除すると、すべてが壊れてしまうということです。
たとえば、Pythonの最初のリリースは1990年であり、30年前のプログラミング言語です。Pythonのような人気のあるスタックに含まれるコードの量は非常に膨大であり、その理由は十分にあります。私はそれを批判しているわけではありません。非常に堅牢なスタックですが、非常に巨大なスタックでもあります。ですので、最終的にはさまざまなオプションを評価しました。プログラミング言語を取って、満足のいくものになるまでたくさんのものを削除するか、それらのプログラミング言語にはそれぞれ独自の遺産がたくさんあると考えるかです。
私たちは新しい言語を作成するための努力がどれくらいかかるかを評価しましたが、最終的には新しい言語を作成することが非常に有利であるという結論に至りました。新しいプログラミング言語のエンジニアリングは、非常に確立された分野ですので、信じられないかもしれませんが、そうではありません。レシピを提供する数百冊の本があり、それは今ではコンピュータサイエンスの学生にもアクセス可能です。さらに、コンピュータサイエンスの学部には、新しいプログラミング言語のコンパイラを作成するための課題を学生に与える教授さえいます。
最終的に、私たちはサプライチェーンが非常に大規模であるため、専用の取り組みが必要であると判断しました。はい、サプライチェーンには設計されていないものを常にリサイクルすることができますが、サプライチェーンは世界中の巨大な産業であり、問題の集合です。ですので、私たちは、私たちが考えているスケールを考慮して、サプライチェーンに直接適したものを作成することが合理的だと考えました。偶然のリサイクルではなく、正しい方法を選ぶべきです。
質問: サプライチェーンの最適化には、SQL、Pythonなどを含むEnvisionが適しています。しかし、プロセスフローが数学的最適化よりも重要なWMS、ERPについては、そのコンパイラとプログラミング言語をどのように評価しますか？
それは非常に良い質問です。私はこの業界には、完全にトランザクショナルな性質、ワークフロー指向の実装の利点のために、独自のプログラミング言語を設計したアクターが実際に存在するという考えを遊んできました。私が見る限り、サプライチェーンは基本的に予測的最適化に関するものです。ただし、ナンナーニ氏は完全に正しいです。ERP、WMSなどのような管理部分はどうなのでしょうか？
実際、この分野には自社のプログラミング言語を作り上げた多くの企業が存在します。私はABAPを持つSAPを挙げましたが、それはそのために設計されたものです。残念ながら、ABAPは私の意見ではあまりうまくいっていません。ABAPには21世紀にはあまり意味のないものがたくさんあります。これは'83年に設計されたものであることがよくわかります。たとえば、Microsoft Dynamicsでは、ERPに独自のプログラミング言語があります。Dynamics AXには独自のプログラミング言語があり、多くのERPプロジェクトは、大部分が独自のプログラミング言語を持っています。ですので、それは存在します。
では、これらの言語は2021年の現代の最先端のプログラミング言語の頂点なのでしょうか？私はそうは思いませんし、それが私が言っている問題でもあります。エンタープライズソフトウェアのベンダーはプログラミング言語を何度も再発明していますが、通常、それを非常に下手な仕事をしています。それはただの無計画なエンジニアリング設計です。彼らは市場で利用可能な多くの本を読む時間さえ取りませんし、そして、不運なエンジニアたちは混乱の山に取り残されています。
質問に戻りますが、私はLokadが最適化ではなくワークフローのサポートのために設計された言語を開発するという考えを遊んできました。ただし、この時点でLokadの成長は非常に大きく、ワークフローに取り組む余裕はありません。私は絶対にこれが正しいと確信していますし、問題の管理部分には非常に優れた仕事をする新しいアクターが現れるでしょう。Lokadはサプライチェーンの最適化部分にのみ取り組んでいますが、管理部分もあります。
質問: Pythonは現在、標準的なプログラミング言語と見なされています。市場では進化が続いていますか？
それは非常に良い質問です。人々が私に「標準」と言うとき、私は標準が現れては消えていくのを長い間見てきました。私はあまり年をとっていませんが、高校にいたとき、標準はC++でした。90年代には、C++が標準でした。なぜ他の方法でやるのですか？そして、2000年ごろにJavaが登場し、JavaとXMLの組み合わせが標準でした。
その当時、人々は大学が「Javaの学校」になったとさえ言っていました。それは文字通り2000年ごろの用語であり、人々は「これはもはやコンピュータサイエンスの大学ではなく、ただのJavaの学校だ」と言っていました。数年後、私がLokadを設立したとき、統計に関連するすべてのプログラミング言語はまだRでした。Pythonはまだ非常にマージナルであり、Rは統計分析の分野で絶対的な支配力を持っていました。
プログラミング言語の進化が進むにつれて、C++は衰退しました。マイクロソフトは2002年にC#と.NETプラットフォームを導入し、C++エコシステムの大部分を食い潰しました。世界中のC++開発者の大部分はマイクロソフトに在籍していました。私が言いたいのは、完全な進化が続いており、毎年、人々はこれを標準と見なしていますが、この標準は常に変化しているということです。
JavaScriptは20年以上前から存在していましたが、それほど重要ではありませんでした。しかし、2009年または2012年に出版された「JavaScript: The Good Parts」という本が、JavaScriptが完全に狂気ではないことを明らかにしました。あなたは正気を失うことなく、実際のプロジェクトでJavaScriptを使用することができます。ただし、良い部分に固執する必要があります。突然、JavaScriptが大流行し、人々はNode.jsというシステムでサーバーサイドで使用し始めました。
Pythonは数年前にのみ脚光を浴びました。Pythonコミュニティはバージョン2.7からバージョン3.xへの厳しいアップグレードを経験しました。このアップグレードの終わりに、Pythonへの関心が再燃しました。ただし、Pythonには多くの危険が潜んでいます。21世紀の基準ではあまり優れた言語ではありません。Pythonは30年前の言語であり、その年齢を示しています。成熟度以外のあらゆる面で優れたものを求めるのであれば、Juliaを見ることができます。Juliaはデータサイエンスにおいてほぼすべての面でPythonよりも優れていますが、成熟度ではまだ数年遅れています。
進化はたくさんあり、業界の状態を持続するものと間違えることは簡単です。たとえば、Appleのエコシステムでは、Objective-Cがあり、その後、AppleはObjective-Cの代わりとしてSwiftを生み出しました。プログラミング言語の状況はまだ非常に進化し続けており、時間がかかるとしても、10年後のエコシステムを見れば、かなりの進化があるでしょう。Pythonは主要なプログラミング言語として浮上するかもしれませんが、より良い解答をもたらす多くの競合オプションが存在します。
質問: 食品会社やeコマースのスタートアップは、データサイエンスチームや汎用言語との戦いに勝てると考えています。彼らにこのアプローチを改善し、より問題特化のものが必要であると気づかせるための最も重要なセールスポイントは何ですか？
私が言ったように、これはダニング・クルーガー効果の問題です。ソフトウェアエンジニアに整数計画を行うための混合整数線形計画システムを与えると、1週間後、この人は離散最適化の専門家になったと思い込むでしょう。では、どうやって戦いに勝つのでしょうか？実を言うと、通常、私たちは勝ちません。私がすることは、災害がどのように展開されるかを説明することです。
一般的な技術のブロックを使用して素晴らしいプロトタイプを作成するのは簡単です。これらのプロトタイプは、スターウォーズの妄想によって素晴らしく機能します-あなたは単独で自分の技術を持っています。これらの企業がこれらのものを本番環境に持ち込もうとすると、非常に平凡な問題によってほとんどの場合苦労することになります。彼らは継続的な統合の問題に直面します。GoogleやMicrosoft、Amazonのように、すべての配管に対処するために1000人のエンジニアを雇う余裕があるわけではありません。
たとえば、TensorFlowを統合するのは難しいです。GoogleはTensorFlowをすべてのデータパイプラインやアプリケーションに組み込むために必要な1000人のエンジニアを持っています。しかし、スタートアップやeコマース企業は、そのような多くの人々がすべての配管を担当することを負担できるでしょうか？通常、答えはノーです。人々はこれらのツールを選ぶだけで、物事を選りすぐって組み合わせ、それが魔法のように機能すると想像しています。しかし、そうではありません。それには大量のエンジニアリングが必要です。
ところで、一部のエンタープライズソフトウェアベンダーも同じ問題に苦しんでいます。彼らのソリューションにはあまりにも多くのコンポーネントがあり、そのため、カスタマイズなしでソリューションを展開するだけでも数ヶ月かかります。システムには緩く統合された不安定な部分が非常に多くあり、非常に困難になります。
これが最後の質問でしたね。次回をお楽しみに。
