応募トーク
これは応募されたトークです。聞きたいと思うトークをSNSで拡散しましょう。選考時に参考にさせていただきます。
talk
複数の言語からなるプロジェクトを作るということ(ja)
スピーカー
Kosuke Kusano
対象レベル:
中級
カテゴリ:
Best Practices/Patterns
説明
1つのプロジェクトが1つのプログラミング言語で完結することが少なくなっています。言語的にキメラ(chimera)なプログラミング技法についてこれまであまり議論されてきませんでした。PythonとRustを用いたmulti-threaddingについて取り上げながら、Pythonの不得意とする処理を他の言語に委譲する方法論を議論し、chimeraに対する議論を深めようと思います。
目的
chimera projectという概念, 別の言語とPythonの違いを発見し両者の長所を活かす方法論
概要
### intro
私の研究の中でNP困難な問題を解く必要がでてきました。並列計算をする必要がありGILのあるPythonのみでは困難でした。これまでの研究はすべてPythonとIPython notebook上で行っており、これまでの資産がありました。この資産を捨て、Python以外の言語で再実装するのはナンセンスです。そのため、NP困難な問題のソルバーをRust・C++/Cythonを用いて構築し、Pythonから実行可能にすることを考えます。
より抽象的に考えた際に、プログラミング言語の仕様・ライブラリ・文化に対し、得意な処理/不得意な処理があるということです。先の例では、Pythonの不得意な処理(並列計算)に対し、並列計算の得意なRustで実装するという手段を取りました。同様に分散処理をactor modelで組もうと考えた際は、Pythonよりerlangのほうで実装したくなります。そのような状況では、あるコンポーネントはある言語で書きたいが別のコンポーネントは違う言語で書きたいという欲求がでてきます。
この1つのプロジェクトに対し複数の言語が混ざった(この状態をchimeraと命名)場合に考えるべきことを、実際に実装を行った上で議論します。
### 事例
- numpy
- CORBA
### 実際にchimeraでいくつかのプログラムを実装する
- Python,Rust
- Python,C++,Cython
- Python,erlang
### 設計上の考慮点
- コンポーネント間の関係(対等/所有)
- host/process/thread?
- コンポーネントのインターフェイス
- 結合度
- 基本的に従来の設計と考えることは変わらない
- 各言語仕様や文化を考慮する必要はあるが
### 実装上の考慮点
- コンポーネント依存グラフのrootをだれにするか(人?setup.py?)
- build toolはどうするか?
- 依存しているライブラリの数が言語により爆発する、debugの難しさ
- dockerによる環境の固定化
- serializeは如何にするか
- protocol buffers
- json
- 通信手段は如何にするか(host/process/thread間?)
- zmq
- shared memory
### 保守上の考慮点
- 全員がすべての言語を理解する必要があるのか
- 現状では十分なノウハウがない
### 現状の問題点
- ノウハウがない(best practice, anti-pattern)
- 議論してる人が居ない(ようにみえる)
- 本当の意味でのglue言語
- build tool(no setup.py)
### (chimeraから見た)Pythonの今後
- Pythonの長所/短所を把握する必要性
- 如何にPythonの資産を活かすか
- 容易にPythonの短所を委任できるようにできるか