マルチパラダイムプログラミング言語を設計します。パート1-それは何のためですか？

Habrは、アイデアを自由に共有できる素晴らしい場所です（たとえクレイジーに見えても）。 Habrは多くの自家製プログラミング言語を見てきました。この分野での私の実験についてお話します。しかし、私の話は他の話とは異なります。まず、それは単なるプログラミング言語ではなく、いくつかのプログラミングパラダイムを組み合わせたハイブリッド言語になります。第二に、パラダイムの1つはかなり珍しいものになります。これは、ドメインモデルの宣言的な説明を目的としています。そして第三に、宣言的モデリングツールと従来のオブジェクト指向または機能的アプローチを1つの言語で組み合わせることで、新しい独自のプログラミングスタイル、つまりオントロジー指向のプログラミングを生み出すことができます。主に理論上の問題や質問を開示する予定ですが、私が出会ったこと、そして結果だけでなく、そのようなデザインを作成するプロセスについても話します。技術や科学的アプローチ、そして哲学的な言説について多くのレビューがあります。たくさんの資料があります、あなたはそれを一連の記事全体に分解しなければならないでしょう。このような大規模で複雑なタスクに興味がある場合は、コンピュータロジックとハイブリッドプログラミング言語の世界を長く読んで没頭する準備をしてください。

主なタスクについて簡単に説明します

これは、ドメインモデルの記述と操作の両方に便利なプログラミング言語を作成することで構成されています。モデルの説明をできるだけ自然に、人間が理解できるようにし、ソフトウェアの仕様に近づけること。しかし同時に、それは本格的なプログラミング言語のコードの一部でなければなりません。このため、モデルはオントロジーの形式を持ち、具体的な事実、抽象的な概念、およびそれらの間の関係で構成されます。事実は、主題分野の直接的な知識、およびそれらの間の概念と論理的関係、つまりその構造を説明します。



モデリングツールに加えて、言語には、モデルの初期データの準備、要素の動的な作成、クエリの結果の処理、アルゴリズム形式での記述に便利なモデル要素の作成のためのツールも必要になります。これはすべて、計算のシーケンスを明示的に記述することによって行うのがはるかに便利です。たとえば、OOPまたは機能的アプローチを使用します。



そしてもちろん、言語の両方の部分が密接に相互作用し、互いに補完し合う必要があります。それらを1つのアプリケーションに簡単に組み合わせて、最も便利なツールで各タイプの問題を解決できるようにします。



なぜそのような言語を作成するのか、なぜハイブリッド言語を作成するのか、そしてそれがどこで役立つのかという質問から話を始めます。次の記事では、宣言的なスタイルと必須または機能的なスタイルを組み合わせることができるテクノロジーとフレームワークの概要を簡単に説明する予定です。さらに、オントロジーを説明するための言語を確認し、新しいハイブリッド言語の要件と基本原則を策定し、まず第一に、その宣言コンポーネントを作成することが可能になります。最後に、その基本的な概念と要素について説明します。その後、宣言的パラダイムと必須パラダイムを一緒に使用したときにどのような問題が発生し、どのように解決できるかを検討します。また、推論アルゴリズムなど、言語実装のいくつかの問題についても分析します。最後に、そのアプリケーションの例の1つを見てみましょう。

適切なプログラミング言語スタイルを選択することは、コード品質にとって重要な条件です。

私たちの多くは、他の人々によって作成された複雑なプロジェクトのサポートに対処しなければなりませんでした。チームにプロジェクトコードに精通し、それがどのように機能するかを説明できる人がいて、ドキュメントがあり、コードがクリーンで理解しやすい場合は良いことです。しかし実際には、それは別の方法で発生することがよくあります。コードの作成者は、このプロジェクトに到達するずっと前に終了するか、ドキュメントがまったくないか、非常に断片的で古く、必要なコンポーネント、ビジネスアナリスト、またはプロジェクトのビジネスロジックについてです。 -マネージャーは一般的な言葉でしか言えません。この場合、コードのクリーンさとわかりやすさが重要です。

コードの品質には多くの側面があります。そのうちの1つは、プログラミング言語の正しい選択です。これは、解決される問題に対応する必要があります。開発者が自分のアイデアをコードに簡単かつ自然に実装できるほど、問題をより早く解決でき、ミスを減らすことができます。現在、かなり多くのプログラミングパラダイムから選択でき、それぞれに独自のアプリケーション領域があります。たとえば、機能プログラミングは、データに対して操作を実行する関数を構造化、結合、および再利用するための柔軟性が高いため、計算に重点を置いたアプリケーションに適しています。オブジェクト指向プログラミングカプセル化、継承、多態性を通じて、データと関数からの構造の作成を簡素化します。 OOPは、データ指向のアプリケーションに適しています。ロジックプログラミングは、ツリーやグラフなどの複雑で再帰的に定義されたデータタイプを処理する必要があるルールベースの問題に便利であり、組み合わせの問題を解決するのに適しています。また、リアクティブなイベント駆動型のマルチエージェントプログラミングにもスコープがあります。



最新の汎用プログラミング言語は、複数のパラダイムをサポートできます。機能パラダイムとOOPパラダイムの組み合わせは長い間主流でした。



ハイブリッド機能論理プログラミングにも長い歴史がありますが、それは学術界を超えることはありませんでした。論理的および必須のOOPプログラミングの組み合わせには、ほとんど注意が払われていません（これらについては、次の出版物の1つで詳しく説明する予定です）。私の意見では、論理的なアプローチは、OOPの従来の分野である企業情報システムのサーバーアプリケーションで非常に役立つ可能性があります。少し違う角度から見る必要があります。

宣言的なプログラミングスタイルが過小評価されている理由

私は自分の見解を実証しようと思います。



これを行うには、ソフトウェアソリューションが何であるかを検討します。その主なコンポーネントは次のとおりです。クライアント部分（デスクトップ、モバイル、Webアプリケーション）。サーバー側（個別のサービス、マイクロサービス、またはモノリシックアプリケーションのセット）。データ管理システム（リレーショナル、ドキュメント指向、オブジェクト指向、グラフデータベース、キャッシングサービス、検索インデックス）。ソフトウェアソリューションは、人だけでなくユーザーと対話する必要があります。 APIを介して情報を提供する外部サービスとの統合は一般的なタスクです。また、データソースには、オーディオおよびビデオドキュメント、自然言語のテキスト、Webページのコンテンツ、イベントログ、医療データ、センサーの読み取り値などがあります。



一方では、サーバーアプリケーションは1つ以上のデータベースにデータを格納します。一方、APIエンドポイントからの要求に応答し、着信メッセージを処理し、イベントに応答します。メッセージとクエリの構造は、データベースに保存されている構造とほとんど一致しません。入力/出力データ形式は、外部で使用するように設計されており、この情報の利用者向けに最適化されており、アプリケーションの複雑さを隠しています。保存されたデータ形式は、リレーショナルデータモデルなどのストレージシステム用に最適化されています。したがって、アプリケーションの入力/出力をデータストレージシステムと組み合わせることができる概念の中間層が必要です。通常、このミドルウェアレイヤーはビジネスロジックレイヤーと呼ばれ、ドメインオブジェクトの動作に関するルールと原則を実装します。



データベースコンテンツをアプリケーションオブジェクトにリンクする作業も簡単ではありません。ストレージ内のテーブルの構造がアプリケーションレベルの概念の構造に対応している場合は、ORMテクノロジを使用できます。ただし、プライマリキーおよびCRUD操作によるレコードへのアクセスよりも複雑なケースでは、データベースを操作するためのロジックの個別のレイヤーを割り当てる必要があります。通常、データベーススキーマは可能な限り一般的であるため、さまざまなサービスで使用できます。それぞれがこのデータスキーマを独自のオブジェクトモデルにマップします。アプリケーションが1つのデータストアではなく、他のサービスのAPIを介してサードパーティのソースからデータをロードする、さまざまなタイプの複数のデータストアで動作する場合、アプリケーションの構造はさらに混乱します。この場合、統合ドメインモデルを作成し、さまざまなソースからのデータをそれにマップする必要があります。

場合によっては、ドメインモデルは複雑なマルチレベル構造を持つことができます。たとえば、分析レポートを編集するときに、他の指標に基づいていくつかの指標を作成できます。これは、3番目の指標などを作成するためのソースになります。また、入力データは半構造化された形式にすることができます。このデータには、たとえばリレーショナルデータモデルのような厳密なスキーマはありませんが、有用な情報を抽出できるようにする何らかのマークアップが含まれています。このようなデータの例としては、セマンティックWebリソース、Webページの解析結果、ドキュメント、イベントログ、センサーの読み取り、テキスト、ビデオ、画像などの非構造化データの前処理結果などがあります。これらのソースのデータスキーマは、アプリケーションレベルでのみ構築されます。コードもあります、ソースデータをビジネスロジックオブジェクトに変換します。



そのため、アプリケーションには、アルゴリズムと計算だけでなく、ドメインモデルの構造に関する大量の情報（概念の構造、それらの関係、階層、他の概念に基づいていくつかの概念を構築するための規則、アプリケーションの異なるレイヤー間で概念を変換するための規則など）も含まれます。ドキュメントやプロジェクトを作成するときは、この情報を宣言的に記述します-構造、図、ステートメント、定義、ルール、自然な言語での記述の形式で。このように考えると便利です。残念ながら、これらの説明をコードで同じ自然な方法で表現できるとは限りません。

小さな例を考えて、さまざまなプログラミングパラダイムを使用してその実装がどのように見えるかを推測してみましょう

2つのCSVファイルがあるとしましょう。最初のファイル：



最初の列にはクライアントIDが含まれています。

2番目には日付が含まれています。

3番目の-請求額、

4番目の-支払い額。

2番目のファイル：

最初の列にはクライアントIDが格納されます。

2番目に-名前。

3番目はメールアドレスです。

いくつかの定義を紹介しましょう

。請求書には、クライアントのID、日付、請求額、支払い額、およびファイル1

の1行のセルからの負債が含まれます。負債額は、請求額と支払い額の差です。

顧客は、ファイル2の1行のセルにある顧客ID、名前、および電子メールアドレスを使用して記述されます。

未払いの請求書は、正の債務請求書です。

アカウントは、顧客ID値によって顧客にリンクされます。

債務者とは、未払いの請求書が少なくとも1つあり、その日付が現在の日付より1か月古い顧客のことです。

悪意のある不履行者とは、3つ以上の未払いの請求書を持っている顧客です。

さらに、これらの定義を使用して、すべての債務者にリマインダーを送信する、永続的な不履行者に関するデータをコレクターに送信する、債務額のペナルティを計算する、さまざまなレポートを編集するなどのロジックを実装できます。機能プログラミング



言語このようなビジネスロジックは、変換のための一連のデータ構造と関数を使用して実装されます。さらに、データ構造は基本的に機能から分離されています。その結果、モデル、特にエンティティ間の関係などのコンポーネントは、一連の関数内に隠され、プログラムコードに塗り付けられます。これにより、モデルの宣言的な記述とそのソフトウェア実装の間に大きなギャップが生じ、その理解が複雑になります。特にモデルのボリュームが大きい場合。オブジェクト指向の



プログラムの構造化スタイルはこの問題を軽減するのに役立ちます。各ドメインエンティティは、データフィールドがエンティティの属性に対応するオブジェクトによって表されます。また、エンティティ間の関係は、オブジェクト間の関係の形式で実装されます。一部はOOPの原則（継承、データ抽象化、多態性）に基づいており、一部は設計パターンを使用しています。ただし、ほとんどの場合、関係はオブジェクトメソッドでエンコードして実装する必要があります。また、エンティティを表すクラスを作成することに加えて、それらを順序付けるためのデータ構造、これらの構造を埋め、それらの情報を検索するためのアルゴリズムも必要になります。



債務者の例では、「アカウント」と「クライアント」の概念の構造を説明するクラスを説明できます。ただし、オブジェクトを作成し、アカウントオブジェクトと顧客オブジェクトを相互にリンクするロジックは、多くの場合、ファクトリクラスまたはメソッドで個別に実装されます。債務者と未払いの請求書の概念については、個別のクラスはまったく必要ありません。それらのオブジェクトは、必要な場所でクライアントと請求書をフィルタリングすることによって取得できます。その結果、モデルの概念の一部は、オブジェクトレベルで明示的に、一部は暗黙的にクラスとして実装されます。概念間の関係のいくつかは、対応するクラスのメソッドにあり、いくつかは別個のものです。モデルの実装は、クラスやメソッド全体にまみれ、ストレージ、検索、処理、フォーマット変換の補助ロジックと混合されます。コード内でこのモデルを見つけて理解するには、ある程度の努力が必要です。



説明に最も近いのは、知識表現言語での概念モデルの実装です。そのような言語の例は、Prolog、Datalog、OWL、Floraなどです。私はこれらの言語について3番目の出版物で話す予定です。それらは、一次ロジックまたはそのフラグメント、たとえば記述ロジックに基づいています。これらの言語では、宣言形式で問題の解決策の仕様を指定し、モデル化されたオブジェクトまたは現象の構造と期待される結果を記述することができます。また、組み込みの検索エンジンは、指定された条件を満たすソリューションを自動的に見つけます。そのような言語でのドメインモデルの実装は、非常に簡潔で理解しやすく、自然な言語での説明に近いものになります。



たとえば、Prologでの債務者に関する問題の実装は、例の定義に非常に近くなります。これを行うには、テーブルセルをファクトとして表す必要があり、例の定義をルールとして提示する必要があります。アカウントと顧客を比較するには、ルールでそれらの間の関係を指定するだけで十分であり、それらの特定の値が自動的に表示されます。



まず、テーブルの内容を次の形式でファクトを宣言します：テーブルID、行、列、値：

cell(“Table1”,1,1,”John”). 

次に、各列に名前を付けます。

clientId(Row, Value) :- cell(“Table1”, Row, 1, Value).

次に、すべての列を1つの概念に組み合わせることができます。

bill(Row, ClientId, Date, AmountToPay, AmountPaid) :- clientId(Row, ClientId), date(Row, Date), amountToPay(Row, AmountToPay), amountPaid(Row, AmountPaid).
unpaidBill(Row, ClientId, Date, AmountToPay, AmountPaid) :- bill(Row, ClientId, Date, AmountToPay, AmountPaid),  AmountToPay >  AmountPaid.
debtor(ClientId, Name, Email) :- client(ClientId, Name, Email), unpaidBill(_, ClientId, _, _, _).

等。



モデルを操作するとき、メッセージの送信、他のサービスへのデータの転送、複雑なアルゴリズム計算のロジックを実装するときに、問題が発生します。Prologの弱点は、一連のアクションの説明です。それらの宣言的な実装は、単純な場合でも、非常に不自然に見える可能性があり、多大な労力とスキルを必要とします。さらに、Prologの構文はオブジェクト指向モデルにあまり近くなく、多数の属性を持つ複雑な複合概念の説明を理解するのは非常に困難です。

主流の機能的またはオブジェクト指向の開発言語を、ドメインモデルの宣言的な性質とどのように調和させるのでしょうか。

最もよく知られているアプローチは、オブジェクト指向の設計（ドメイン駆動型設計）です。この方法により、複雑なドメインモデルの作成と実装が容易になります。これは、すべてのモデルの概念がビジネスロジックレイヤーで明示的にコードで表現されることを示しています。モデルの概念とそれを実装するプログラムの要素は、可能な限り互いに近く、プログラマーと主題の専門家の両方が理解できる単一の言語に対応している必要があります。



債務者を含む例のリッチドメインモデルには、「未払いの請求書」と「債務者」の概念のクラス、アカウントと顧客の概念を組み合わせるための集約クラス、オブジェクトを作成するための工場が追加で含まれます。このようなモデルの実装とサポートには時間がかかり、コードは煩雑です。以前は1行で実行できたものが、豊富なモデルで複数のクラスを必要とします。その結果、実際には、このアプローチは、大規模なチームが複雑なスケールモデルで作業している場合にのみ意味があります。



場合によっては、解決策は、基本的な機能またはオブジェクト指向のプログラミング言語と外部の知識表現システムの組み合わせである可能性があります。..。ドメインモデルは、PrologやOWLなどの外部ナレッジベースに転送でき、ドメインモデルへのクエリの結果はアプリケーションレベルで処理されます。しかし、このアプローチはソリューションを複雑にし、同じエンティティを両方の言語で実装する必要があり、それらの間の相互作用はAPIを介して設定する必要があり、知識表現システムなどによって追加でサポートされる必要があります。したがって、モデルが大きく複雑であり、論理的な推論が必要な場合にのみ正当化されます。ほとんどのタスクでは、これはやり過ぎです。さらに、このモデルは常にアプリケーションから簡単に切り離せるとは限りません。



ナレッジベースとOOPアプリケーションを組み合わせるためのもう1つのオプションは、オントロジー指向のプログラミングです。..。このアプローチは、オントロジー記述ツールとオブジェクトプログラミングモデルの類似性に基づいています。たとえばOWL言語で記述されたクラス、エンティティ、およびオントロジー属性は、クラス、オブジェクト、およびオブジェクトモデルのそれらのフィールドに自動的にマッピングできます。そして、結果のクラスをアプリケーションの他のクラスと一緒に使用できます。残念ながら、このアイデアの基本的な実装は範囲がかなり制限されます。オントロジー言語は非常に表現力があり、すべてのオントロジーコンポーネントを簡単かつ自然な方法でOOPクラスに変換できるわけではありません。また、本格的な推論を実装するには、クラスとオブジェクトのセットを作成するだけでは不十分です。彼は、オントロジーの要素に関する情報を、たとえばメタクラスの形式など、明示的な形式で必要としています。このアプローチについては、次のいずれかの出版物で詳しく説明する予定です。



モデル駆動型開発の ようなソフトウェア開発への極端なアプローチもあります。それによると、開発の主なタスクはドメインモデルの作成であり、そこからプログラムコードが自動的に生成されます。しかし実際には、このような根本的な解決策は、特にプログラムのパフォーマンスに関して、必ずしも十分に柔軟であるとは限りません。このようなモデルの作成者は、プログラマーとビジネスアナリストの両方の役割を組み合わせる必要があります。したがって、このアプローチでは、汎用プログラミング言語でモデルを実装するための従来のアプローチを混雑させることはできませんでした。



これらのアプローチはすべてかなり面倒であり、非常に複雑なモデルには意味があり、多くの場合、それらの使用のロジックとは別に説明されます。より軽く、より快適で自然なものが欲しいです。そのため、1つの言語の助けを借りて、宣言形式のモデルとその使用のためのアルゴリズムの両方を記述することが可能でした。そのため、オブジェクト指向または機能パラダイム（計算コンポーネントと呼びましょう）と宣言パラダイム（モデリングコンポーネントと呼びましょう）を単一のハイブリッドプログラミング言語内で組み合わせる方法を考えました。一見、これらのパラダイムは互いに反対に見えますが、試してみる方が興味深いです。



したがって、目標は、半構造化および断片化されたデータに基づく概念モデリングに便利な言語を作成することです。モデルの形式はオントロジーに近く、ドメインのエンティティとそれらの間の関係の説明で構成されている必要があります。言語の両方のコンポーネントは、セマンティックレベルを含め、緊密に統合する必要があります。



オントロジーの要素は、第1レベルの言語のエンティティである必要があります。引数として関数に渡したり、変数に割り当てたりすることができます。モデル-オントロジーはプログラムの主要な要素の1つになるため、プログラミングへのこのアプローチはオントロジー指向と呼ぶことができます。モデルの説明とその使用のためのアルゴリズムを組み合わせると、プログラムコードが人間にとってより理解しやすく自然になり、ドメインの概念モデルに近づき、ソフトウェアの開発と保守が簡素化されます。



初めてで十分です。次の投稿では、必須スタイルと宣言スタイルを組み合わせたいくつかの最新テクノロジー（PL / SQL、Microsoft LINQ、GraphQL）について説明したいと思います。Habréに関するすべての出版物のリリースを待ちたくない人のために、リンクで利用可能な英語の科学的なスタイルの全文があります：

半構造化データ処理のためのハイブリッドオントロジー指向プログラミング。