++C++; // 未確認飛行 C ブログ

http://ufcpp.net/

言語設計

leave a comment »

言語設計者たちが考えること」などという本を買って呼んでいるわけですけども。Anders Hejlsberg のところを主に。この本を読みつつ、自分的に思うところなどをまとめてみる。

フレームワーク

ここ2・30年ほどを見て、言語は大して進化してない。進化してるのはフレームワーク。

属性、イテレーター ブロック、LINQ や dynamic を導入している C# を基準に見てすら、それ以上にフレームワーク側の進化の方がはるかに大きい。LINQ や dynamic も、言語上は薄い構文糖衣で、多くの部分をフレームワーク側に寄せている。

今は、言語、フレームワーク、開発ツールが切り離せない。

新言語

新しい機能が欲しいんなら既存の言語の拡張でいい。新しい言語を作りたいのはむしろ機能を削りたい時(危険だったり誤用を招く機能をなくしたい時)。

汎用言語の新機能は、汎用であるべき。LINQ はデータ アクセスという domain specific ではあるけど、拡張メソッド、匿名型など、汎用な細々とした機能の組み合わせで実現している。単純に言語内に SQL 埋め込むだけのような実装方法だったら決して採用されていない。

DSL

外部 DSL だと「特殊な文法の中で、式だけは C# のものを流用したい」って要件が多すぎてつらい。言語の9割方はありふれてて使いまわせる要件で、残りの1割程度に domain specific が詰まってる。

逆に、内部 DSLで 困るのは、制限を掛けたい時。機能が多すぎるのが煩雑さ・誤用を招くから機能制限したいけど、内部 DSL だと元の言語の機能フルに使えてしまう。

多分、必要なのは、既存言語を部分的に流用する機能。

ここ10年ほど注目浴び続けてる domain っていうと並列処理だけども、immutable がいいとか、状態を共有したくないとか色々ある。で、immutable って機能を足す方は簡単。問題は、mutable な既存機能をどう制限するか。(言語全体で制限するのはかえってまずい。GUI 部分みたいに本質的に mutable な部分はやっぱ mutable にやった方が。)

動的

動的言語の良さはメタプログラミング。でも、そのためだけに型の静的チェックをなくすのはあまりにもデメリットが大きすぎる。

注意: 動的実行・動的コード生成をしてても、型チェックだけは静的にできる。

広告

Written by ufcpp

2010年10月2日 @ 07:38

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

%d人のブロガーが「いいね」をつけました。