[thread display] [new arrival display] [word search] [past log] [管理用]
| Subject | ： Re^3: SADのPython/JAVA等からの利用について |
| Date | ： 2007/10/03(Wed) 17:08:43 |
| Contributor | ： AKio Morita |
> 現状をかんがみると、
>
> 1) Python/JAVAをベースとし、SADシミュレーションの
> Input/OutputはFile I/O で処理してごまかす、
>
> あるいは、妥協して、
>
> 2) SADをベースとし、Python/JAVA などのクラスを SAD用クラスに
> 変換して用いる、
>
> というあたりが実現可能な解であるように察します。
> (SADで押し通す 2) のほうがストレートフォワードでしょうが)
>
> 1), まだは 2) でやるとしても、使いやすくなるようなインターフェース
> ができてくると嬉しいです。
>
外部の処理系との連携機能を実装出来る出来ないという点では実装可能です
(SAD/Tkinterや EPICS Channel Access自体が外部ライブラリの呼び出しですし)
が、一般ユーザーが直感的に操作できるインターフェースを任意の処理系に対して
無矛盾かつ可搬的に構築するのは困難だと思います
＃ってか、誰がそんなすごいコードを書くんだ？
1)は、JCEでやってるという話を聞きました(シミュレーションエンジンが未実装のため)
というか加速器制御ではよくやってる(制御系から BATCH的に MADを呼び出すとか)と思います
2)の場合、実装を作る上での懸念材料は
o 設計思想の違う処理系間でのライブラリを外部呼び出しすると運用上の制限が多くなる
低レベルAPIをマップする場合は、それほどひどいことに成らないはずですが、移植先に無い
データ型をどう表現するかが腕の見せ所です
> ポインタの概念が無い言語に、Cのポインタを使った未知の関数をどうマップするかとか
o 設計思想の違う処理系からコードを移植すると、移植先の実装が歪なものになりやすい
> 手続き言語に関数言語の高階関数を使ったライブラリを素直に移植するのは難しい
> ISO Cスタンダードだけだと、関数言語で使う「関数のカリー化」はたぶん実装できない
o 持ってくるコードベースによってはライセンスが問題になる場合がある
特に GPLやCreative Commons等のコピーレフトとSAD本体のライセンスが共存できないため
ライブラリの形でリンクするとライセンスを満たせなくなります
（再実装の場合、クリーンルーム開発でないと、派生物扱いでオリジナルライセンスに縛られる恐れが）
実現する上では、設計・実装上のトレードオフがいろいろ有るわけで
開発者は自分の思想や美意識の中で美しくかつ実用的なものを目指すので、
内部の実装を理解してるものにとって使いやすいインターフェースが
一般にユーザーに分かりやすいかどうかは疑問があります。
したがって、一番重要なことは
「真にユーザーに使いやすいインターフェースを作るには
実際に使うユーザーが開発にかかわる必要がある 」
ということでは無いでしょうか？