『Dr.WEB メールデーモン』、MTA 用迷惑メール対策製品です！
_ [言語] the 0.8 true languageあらゆることに使える完璧な言語(the one true language)が存在しないことは明らかである。
たとえば、Rubyがどんなにすばらしい言語でも、Ruby自身はRubyでは記述されていない。 また、OSなどRubyで記述するには向かない分野はいくらでもある。 そもそもRubyが向かないプログラマーもいるようだが、その点には今回は触れない。
しかし、100%を考えるから、完璧な言語は存在しないわけだが、 仮に80:20則にしたがって「80%の領域をカバーする言語」について 考えると、そのような言語はどのような性質を持つのが望ましいだろうか。
100%(=one)でなくて、80%(=0.8)だから、名づけて「the 0.8 true language」。
今回は言語そのものの性質を考えるために、 「コンピュータは十分な性能を持つ」ことを仮定する。 つまり、「この機能がないと性能が...」とかは考えないということだ。 世の中がどんなに進んでもコンピュータが十分な性質を持つことはないわけで(性能が向上するほど仕事が増えるので)、ある意味、現実的仮定ではないわけだが、あくまでも思考実験であると考える。
一方、人間の性質はそんなに変化しないので、現代の人間がもつ特性は考慮に入れる。 たとえば、100年後の人間はもしかしたら誰でも「物事を宣言的にとらえてプログラミングする」ことが なんでもないことになってるかもしれないけど、現代ではそのような人は少数派だ。
まず、80%の領域をカバーするためには、 その言語は汎用言語でなければならないだろう。 特定目的言語(DSL)や特殊なモデルを持つ言語(論理型言語とか、一部の関数型言語とか)では、 80%の領域をカバーできないからだ。 いや、PrologでOSまで書いた人たちがいるのはもちろん知ってるけど、 やっぱ普通のプログラマには難しいよねえ。
一方、広い領域で十分な生産性を提供するためには、 高度な抽象化能力を持つ必要がある。 現代のプログラマにはBASICや(古い)FORTRAN程度の抽象化能力では不十分だろう。 現在までに知られている抽象化機能で有効なものは、 オブジェクト指向プログラミングと、関数型プログラミングがある。 the 0.8 true languageはその両方を何らかの形で持つ必要があるだろう。 具体的には「オブジェクトとメッセージ(or 動的結合)」と 「高階関数(とクロージャ)」が必要だ。
また、言語の簡潔さも重要になる。 詳しくは『簡潔さは力なり---Succinctness is Power---』を参照のこと。
それから言語の動的性質も。 これは、Java業界でDIが注目されていることからもわかる。 DIやXMLを使った設定ファイルってのは、結局硬直したJavaアプリケーションを なんとかして柔軟に、動的にしようという試みにしか見えない。 最初から動的な言語を使っていれば、両者ともほとんど必要になることはない。
私は一時DIについて関心を持って、いろいろ調べてみたし、 自分でDIコンテナを実装してみたりもした。 でも、RubyでならDIコンテナがわずか20行で記述できる上、 よく考えてみたら、その20行も、なくてもほぼ同じことが簡単に実現できることに気がついた時、 DIってのは硬直した言語のための技術なんだと気がついた。
ここまでは当たり前の話。ここから未来予想が入ってくる。
個人的に将来性のある技術トレンドのひとつとして考えているのが、 「内部DSLの台頭」である。特定目的の言語であるDSLを 既存言語の拡張として実現することにより、
などを一度に実現できる、一粒で何度もおいしい技術だ。 で、その内部DSLを実現するために、言語が備えるべき性質は、 「柔軟で拡張性がある」ことと「乱用しやすい文法」とであると考える。
ここで意見が分かれると思うのだが、 私はLispは「内部DSLには向いていない」と思う。 より正確に表現するならば、「LispのS式とマクロはDSLを実装するのに最適だが、 拡張性がありすぎて、すぐに外部DSLの領域に到達してしまう」という意味だ。
ま、「そんなことたいしたことじゃない」と思う人も多いかもしれないけど。
いずれにしても、the 0.8 true languageはなんらかの形で内部DSLを支援するべきだと思う。 その解決策は一つではなくて、ちょっと考えただけでも
などが考えられる。最後のはちょっと違う気がするけど。
最後の要素はスケーラビリティ。
「スケーラビリティ」と言ってもいろいろなことを意味するけど、 ここで考えている重要なことは、以下のもの。
いずれも、現在から近い将来にかけてのコンピュータ事情を反映しているので、 最初の「マシンのことは考慮しない」という前提には反しているな。でも、大事なことなので。
ここはRubyがちょっと(いや、だいぶ)弱いところなので、今後力を入れないといけないだろう。
というわけで、the 0.8 true languageを備えるべき特質について考えてみた。 私の見解だとLispやRubyはけっこういい線行ってると思う。 Pythonはいい言語だけど、ちょっと文法が融通きかないので、内部DSLには向かないかな。 ここは違うアプローチを使うのだろう。
この考察から考えると、今後Java方面では、ますますのXMLの活用とJVM上のJavaでない言語の台頭が予想される。 というか、もうかなり出てきてるよね。JRubyとかGroovyとかScalaとかClojureとか。
あまり有効な結論もないまま終わる。
This work is licensed under a Creative Commons License.
ずれている質問かもしれませんが、「正規表現」というのは内部DSLの一種とみなせるものでしょうか？（みなせない、みなせる、みなしたほうがいい、みなさないほうがいい、無関係） <br>
言語に要求される機能を整理して機能階層ごとに分離してゆくということでよろしいのでしょうか。その観点から見れば、クラウドコンピューティングというのも一つの方向性だと思います。 <br>それから、Lispが自由すぎて、理想の言語とは成り得ないという点は同意です。
結城さんへ、 <br>正規表現は「外部DSL」だと思います。ホスト言語の文法をそのまま流用して、DSL化するのが内部DSLですから、独自の文法を持つ正規表現は、言語の一部として組み込まれていても、外部DSLでしょう。同様の理屈でSQLも外部DSLです。 <br>
DSLをたくさん作っている者です。内部DSLについては昔からいろいろ考えて実験してきました。 <br> <br>C++なんかで、カンマやキャストの振る舞いを定義したり、マクロ駆使したりして、内部DSLをやったことがあります。 <br>そのときに分かったことですが、内部DSLでの記述ミスが型検査のエラーとして報告されてしまい、内部DSLの概念だけ理解していても使えませんでした。 <br>特定ドメインの仕様をC++を理解している人が簡潔に記述するという場合にはこれでもよいのですが。 <br>C++を理解していない特定ドメインの専門家に仕様を書かせる目的でDSLを使う場面が多いので内部DSLは今のところあきらめています。 <br>理想を言えば内部DSLをサポートした言語でなんとかしたいですね。 <br>
まつもとさん、お返事ありがとうございます。 <br>正規表現は「外部DSL」は理解しました。 <br>では、正規表現の文法(notation?)を、ホスト言語の文法に合わせようとする試みは意味があるでしょうか？（読みにくい正規表現の可読性を上げるためにホスト言語の文法を利用するということを想定した質問です）
横からスミマセン。例えばRubyのSequelやS2JDBCのようにホスト言語の文法を利用して、外部DSLを生成するようなものがあり、この試みには一定の価値があると思います。 <br>ですから正規表現をホスト言語の文法で表現する試みも十分価値があるとおもいますよ。
Haskellは、「100%の領域をカバーする」のではないでしょうか?
KTさん、 <br>そう思われる人もいらっしゃるでしょうね。 <br>ただ、少なくとも私は「すべての開発をHaskellで」と言われたら、「勘弁して」と思います。むしろ100%より0.01%くらいですか。
いいおくれましたが、私もRubyでDSL実装し、万能性を確保する為に、DSL内にRubyの命令を埋め込み可能として、そのDSLとうまくデータ連携するようにして、毎日鬼のようにそのDSLを使って仕事をしています。