multilingual - マルチプログラミング言語プロジェクトのベスト プラクティス

Question

誰もこれを行った経験がありますか? 私は現在、C++ で Java デコンパイラーに取り組んでいますが、内部ツリーの実際の変換を行う高レベル言語が必要です。言語間でデータをマーシャリングするオーバーヘッドが、私が達成しようとしていることをより明確に表現するためのより表現力のある言語 (Haskell など) の利点に見合う価値があるかどうか、興味があります。これは実際に「現実の世界」で行われているのでしょうか、それともプロジェクトの開始時に言語を選択してそれを使い続けるのが一般的ですか? 試した人からのヒントはありますか？

Answer 1

私は、課題ごとに適切なプログラミング言語を常に選択することを強く支持しています。トリッキーなタスクを簡単に処理できる言語が他にある場合は、それを選びます。

それは現実の世界で起こりますか？はい。私は現在、PHP と Objective-C コードの両方で構成されるプロジェクトに取り組んでいます。

その秘訣は、ご指摘のとおり、2 つの言語間のコミュニケーションです。可能であれば、各言語を独自のドメインに固定し、2 つのセクションが可能な限り簡単な方法で通信できるようにします。私の場合、それは http 経由で送信された XML ドキュメントでした。あなたの場合、ある種のフォーマットされたテキストファイルが答えかもしれません。

Answer 2

マーシャリングのコストは、使用している言語とアーキテクチャによって異なります。たとえば、CLR または JVM を使用している場合は、低コストの相互運用ソリューションを利用できますが、おそらく管理されていない C++ を使用していると思います。

もう 1 つの方法は、組み込みのドメイン固有言語です。ツリー変換は、多くの場合、パターン マッチングと比較的少数の関数の適用によって表現できます。一致したサブツリーを変換する関数である関連するアクションを使用して、単純なツリー パターン マッチャ (たとえば、Lisp s-exprs のように見えますが、プレースホルダーを使用して変数をキャプチャするもの) を作成することを検討できます。

Answer 3

Tcl/Tkの発明者であるJohn Ousterhoutは、多言語プログラミングの強力な支持者であり、多言語プログラミングについて非常に広範囲に書いています。そのためには、使用している言語間の明確なインターフェース メカニズムが必要です。これにはかなりの数のメカニズムがあります。これを行うためのさまざまなメカニズムの例は次のとおりです。

• SWIG (Simplified Wrapper および Interface Generatorは、ac または c++ (または他のいくつかの言語) ヘッダー ファイルを使用して、API にアクセスできるようにする perl や python などの高レベル言語用のインターフェイスを生成できます。このアプローチを使用する他のシステムがあります。 .

• Java はJNIをサポートし、Python のctypes、VisualWorks DLL/C connectなどのさまざまなシステム は、下位レベルのサブシステムへの呼び出しを明示的に構築できるネイティブ メカニズムです。

• Tcl/Tk は組み込み用に明示的に設計されて おり、言語にフックを追加するための C ライブラリ用のネイティブ APIを備えています。この構造は、C の argv[] 構造に似ており、コマンドライン ベースの C プログラムを Tcl に接続するのが比較的簡単になるように設計されています。これは上記の例と似ていますが、反対方向から来ています。Python、Lua、Tcl などの多くのスクリプト言語は、このタイプのメカニズムをサポートしています。

• Pyrexなどの明示的なグルー メカニズム 。ラッパー ジェネレーターに似ていますが、インターフェイスを定義するための独自の言語があります。Pyrex は実際には完全なプログラミング言語です。COMや CORBAなどのミドルウェアを使用すると、一般的なインターフェイス定義をアプリケーションの外部で インターフェイス定義言語で構築し 、関係する言語が共通のインターフェイス メカニズムを使用できるように言語バインディングを行うことができます。