無差別に技術をついばむ鳥

今回は、アクセス修飾子の記事で複数の技術者とやり取りして気付いた話題を取り上げます。言語仕様を追加すると言う行為は、一般的なプログラマが考えているよりも複雑で厄介なものです（参考資料：C++の設計と進化）大まかに言うと、時間・環境・実装の三つの要素が絡み合って発生する様々な困難さが付きまとうのです。この手の問題について知らない人もいるかと思いますので、先ずはそれらの問題について簡潔に書きます。
一つ目は実装について書きます。普通の人の感覚では実装は関係ないと考えるでしょう。しかし、実際にコンパイラを作ってみるとわかりますが、言語に構文を追加すると思わぬ問題が生じます。例えば、演算子を言語仕様に追加したとします。この時よく考えないと、想像もつかないほどの問題が生じます。演算子を追加すると言う事は、過去のプログラムの演算結果が変化してはならないことを意味します。そうしないと、再コンパイル時にテスト済みのソフトがバグってしまいます！嗚呼、何ということでしょう！匠に相談しなければなりません。
二つ目の要素は時間です。言語仕様は時間が経てば経つほど、過去のしがらみが発生します。何故ならば、仕様策定後に世界中でソフトウェアが作られているからです。それら既存のプログラムに対する重大な責任がありますので、過去のプログラムが動かなくなるようなものは仕様として追加できません！
最後の要素は環境です。これはOSやプロセッサをイメージしてもらえばいいかと思います。今のところ、SQLの様にレベルわけされている言語もありますが、基本的に多くの言語は環境を特定していません。という事は、PC用のOSも、パームトップ型のプロセッサも、さらには医療用ナノマシン用にもその言語は使えなくてはなりません。言語仕様に関わる人は大変ですね。
これはあくまでも大まかな問題です。もっとマイナーなAPIやABIに関わる問題もありますし、ヒューマン的な問題もあります。この互換性的な問題の影響は非常に大きく、多くの人が使っているx86の仕様が複雑なのもそれが原因です。x86は評判どおり汚い部分もありますので、口が悪い人達は「知恵遅れまで継承している」なんて酷評されています。しかし、プロセッサの仕様を変えてしまえばOSすらも動かなくなる事を考えると私はIntelを責められません。
このように言語一つ拡張するのも大変ですが現実はどうでしょうか？「最近の若い者は言葉使いがなっとらん！」と古代エジプト時代から言われておりますが、人間同士は何とか通じ合っています。その差は一体何なのでしょう？私が思うに抽象度が影響しているのではないでしょうか？ハードウェアとソフトウェアが変更に弱いのは予め動的なものとして考えられていないのが原因だと思います。言語は決して静的なものではありません。使えば使うほど進化していきます。これを考慮して、ビャーネ氏は出来るだけライブラリ（語彙）を追加する方向を勧めているのでしょう。過去の情報処理技術を考えるとそれは合理的な考え方です。しかし今のままでは不便な点が数多く存在しますので、情報処理技術を愛し無限の進化を求める私としては不満です。
ではどうすればいいのかと申しますと、これはあくまでも未熟な私の個人的見解なのですが、言語のライフサイクルそのものを一つの情報集合として考え直すしかないでしょう。これは複雑な問題であり、昨日今日解決できる問題はありません。言語策定プロセスそのものを分析してプログラミングするべき時期に来ているのではないでしょうか？

　一つの言語にこだわる必要がないというのもあるんですよね。C言語の不満をC++で解消してさらにJavaやC#が生まれているように次の言語に進化してしまえばいいと思います。結局拡張すること自体よりもどの様なベネフィットを提供できるかですよね。
　まあ新しい言語を作ったあとの政治を無視しての発言ですが。

　特定の言語に言語拡張を施す前提で言うなら追加されるものはオプショナルであるべきで、それはC++がこだわる部分でもありますね。
　ただC++にはテンプレートと言うメタ構文があるので何かしらのDSELを上に乗せると言う手がありますね。(via FC++/LC++)
＃無節操にやるとあの悪しき#define BEGIN { と同じことになる気がｗ

　言語の動的性に関してはC系言語は割りと静的に物事を解決する方向に進化してますよね。これは変化を少なくすることで問題の発生を最小化する考えからですよね。動的なものをいかに静的にモデリングするかと言う問題なので難しいんですよね。
　かといって動的言語で何でもやればいいかというとそうでもなくて、動的な側面の多いシステムには合うんでしょうが、動的な側面の少ないシステムなら静的言語のほうが有利ですよね。
　結局適材適所というかある問題に対して適したものがあると言うだけの話なんですよね。今回のエントリ的にいえば純粋関数型言語なんかは関数の定義が言語拡張と捉えることも出来るので言語拡張に適した言語と言えますよね。
　だからまず作りたい (作るべき) システムにとって今後の言語拡張が重要かを考えるのが先ではないでしょうか？　その結果言語拡張が重要であると判断されるなら言語拡張が難しい言語を選ばない。がスマートなのかなと思いました。
＃でも言語拡張が重要なシステムって思いつかないです。。。

あおいたん、貴重な意見を有難う♪
そうなんですよね・・・
この問題が難しいのはその辺の事情もありますよね・・・

>動的言語について
これは非常に頭の痛い問題ですね。
確かに言語拡張が可能かどうかを考えて言語を選ぶのが現在取り得る最良の手段ですね。
私もシステムという視点から考えると同じく思いつきません。
唯一考え付くのは開発環境だけです。
でもかといって、プログラミング人生から考えたら言語拡張は重要なテーマですし・・・
うーん難しい！

トラックバックURL

FC2ブログユーザー専用トラックバックURLはこちら