Matzにっき

_ 竹内郁雄 教授 最終講義

「Lispの神様」とも呼ばれる東京大学、竹内郁雄 教授の最終講義が開かれます。 特に予約などは必要ないそうですので、ふるってどうぞ。

こういう時だけは東京近辺が便利だと思う。

竹内郁雄 教授  最終講義のご案内  2010年3月3日 (水)


東京大学大学院情報理工学系研究科創造情報学専攻竹内郁雄教授におかれまして
は，2010年3月31日をもちまして東京大学を退職されることになりました．

つきましては，下記のとおり最終講義が開催されますので，ご案内申し上げま
す．御多用の折とは存じますが，ご臨席賜わりますようお願い申し上げます．

東京大学大学院情報理工学系研究科創造情報学専攻
専攻長　石川正俊

1. 最終講義
日時: 2010年3月3日(水)　　（16:30 - 18:00）
会場: 東京大学本郷キャンパス (工学部2号館1階213講義室)
(東京都文京区本郷7-3-1)
講義題目　研究・開発は楽しく

2. お問い合わせ
竹内郁雄教授最終講義運営委員会事務局
final-lecture@ci.i.u-tokyo.ac.jp

　なお，最終講義のあと，工学部2号館3階 電気系会議室1A - 1C (部屋番号:33A)
 において，竹内先生を囲んだ懇親会も予定してございます．

竹内先生とは、最近お会いする機会が多かったのだが、印象に残ったエピソードをいくつか。

昨年9月のRubyWorld Conferenceで、Evan PhoenixがVM高速化の話をしていたのだが、 そのベンチマークがtak(竹内関数)だったこと。Evanはその場に竹内先生その人がいたことを 知らなかったろうなあ。

和田英一先生が、竹内先生の最終講義に関して、Twitterで「竹内くん」と呼んでおられたこと。 和田先生から見れば、たいていの人は後輩になっちゃうよなぁという、ある意味あたりまえの話。

退官後はサッカー三昧なのでしょうか。

_ [言語] The Go Programming Language

もう知っている人は知っているGoogleからのシステムプログラミング新言語Go。

すっかり祭りには乗り遅れた感があるけど、少しだけコメントをつけておこう。

目次

• 言語仕様
• 言語実装
• 技術的でない話
• まとめ

言語仕様

総合的に見て、非常にバランスを考えているように思える。 JavaやC++のような複雑さを排して、シンプルに徹する一方、 言語好きを刺激するような新しいアイディアをそこかしこに配置している。

特徴である「コンパイルが高速」というのも、 このシンプルな言語仕様が寄与していると思われる。

個人的に、注目したのはオブジェクト指向機能と、並列機能。

interfaceによる、継承のないオブジェクト指向(duck typing)は、かなり私好みである。 昔からこういう言語が欲しかった。interfaceのみ動的結合を許すというのも Satherを思い起こさせて好印象。

ただし、私が見た範囲内では、実装の継承(共有)は提供されないみたいなので、 Javaのinterface同様、コンポジションを強制されることになるので、 そこは残念。

それから、goroutineなる並列実行機能。 Erlangを意識してるのかな。でも、それ以上に使いやすそうな印象。

go 式

だけで並列実行が開始できるのは大胆である。 ほとんどのオブジェクトが値渡し(コピーされる)とあいまって、 効率よく並列実行できそう。

あと、多値を活用しているもの面白い。 成功したかどうかを2番目の値で返すところとかもErlangを思い起こさせる。

「逆転した型宣言」は、はじめはギョッとしたけど、 慣れたら結構良いかもしれない。

言語実装

コマンド名！ 8cとかなんだよって感じ。

ソースコードを眺めたが、正直、一番興味があるランタイムの部分は よくわからなかった。だいぶ慣れないとなにがどこにあるのかよくわからない。

GCはシンプルなマーク・スイープだった。

goroutineのsegmented stackの実装に興味があったのだが、 まだみつからず。たぶん、そこはランタイムじゃなくて、 コンパイラそのものを見ないとわかんないんだろうな。

技術的でない話

「Goが登場したからには(Java/C++/Python)はお払い箱」みたいな エントリをいくつか見かけたけど、まだまだそういうレベルではないと思う。

Goは非常に興味深い言語だし、当面いろいろと話題を提供してくれるとは思うけど、 これが定着するか、成功した言語になるかどうかは、長い目で見ないとわからないと思う。

GoogleやRob PikeやKen Thompsonのネームバリューのおかげで、 普通なら10年かかるプログラミング言語のブランド確立を一瞬で達成してしまった Goだけど、成熟度としてはまだまだなので、当分はそのギャップに苦しむ(？)ことに なるんじゃないかな。

そこを乗り越えて、「一人前の言語」になっていくことを期待したい。

まとめ

• 言語の成功は長い目で見よう
• Goガンバレ(えらそう)

_ 日本経済新聞夕刊「拓くひと」

16日の日経夕刊に(恥ずかしい写真と共に)私を扱った記事が掲載されている。

検閲と戦ってきた歴史を持つからか、新聞記者はけっして事前に記事を見せてくれることはない。 間違いが訂正できないんだけどなあ、と不満を持つこともあるが、 まあ、「言論の自由」のために払うべきコストなのかもしれない。

というわけで、補足と訂正。

「松江発」

ご存じのように、私は現在松江に住んでいますが、Rubyを作り始めた時には浜松、 最初に公開した時には名古屋に住んでました。「松江発」はあまり真面目に受け取らないで。

「世界のウェブ言語」

ってなんだかよくわかりませんが、まあ、「Webアプリ開発によく使われる言語」程度の意味でしょう。

「(松江市は)情報産業の新たな名所になりつつある」

といいですね。かなり希望的観測を含んでますね。

「ルビー」

縦書きの新聞ではしょうがないのでしょう。地元紙でもいつも「ルビー」と表現されるので、そろそろあきらめてきました。

「天才プログラマ」

勘弁してください。

「効率良くウェブが書ける言語が必要と思った」

当然ですが、Rubyの開発を始めた1993年にはまだウェブは一般的ではないので、 最初からウェブを対象にしていたわけではありません。 効率良く書きたかったのは、ウェブ(アプリ)ではなく、プログラム全般、特にテキスト処理プログラムですね。

「教祖」

勘弁してください。

「無償ソフト」

まだこんな表現が残ってたんですね。「フリーソフトウェア」または「オープンソースソフトウェア」と読み替えてください。

「モルモン教徒」

間違いじゃないんですが、歴史的には「モルモン」は差別的に用いられてきたので、 自ら名乗る時には「末日聖徒」という単語を使います。一般人には伝わらないかもしれませんが。

「収入は仲間と設立したソフト会社の開発業務」

私は雇われで「仲間と設立した」わけではないです。 NaClの設立を計画する会合に出席はしていましたが。

補足の補足

このエントリを読んで、どこかで「日経の記事はひどい」と書いてた人がいるけど、 上の文章をちゃんと読んでもらえばわかるように、記事そのものは、やや不正確なところはあるものの、 そんなにひどくはない。明らかな間違いはないし。

記者の人の名誉にかかわるんで、 私が「日経はひどい」とか「この記事はひどい」とか まったく思ってないことは明確にしておく。

_ ロンドン地下鉄

旅行者用豆知識

ロンドンの地下鉄はOysterというプリペイドカードがないと、 どの区間も4ポンドなので、１日に２度以上乗るのなら、 乗り放題のワンデイトラベルカード(5.60ポンド)がおすすめ。

駅でチケット同様普通に買えます。

ちなみにカードでOK。今回も現金は一度も使わなかった。

_ [言語] 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を支援するべきだと思う。 その解決策は一つではなくて、ちょっと考えただけでも

• Lispのようなマクロを使った言語拡張性による支援
• Rubyのようなブロックと括弧などを省略できる文法(の乱用)による支援
• JavaのようなXMLによるDSL実現を支援するライブラリ(など)の提供

などが考えられる。最後のはちょっと違う気がするけど。

最後の要素はスケーラビリティ。

「スケーラビリティ」と言ってもいろいろなことを意味するけど、 ここで考えている重要なことは、以下のもの。

• マルチコア化が進むので、そのコアを活用できる並列実行技術
• データ量が1台のコンピュータで処理しきれなくなっているので、複数マシンを活用する分散技術

いずれも、現在から近い将来にかけてのコンピュータ事情を反映しているので、 最初の「マシンのことは考慮しない」という前提には反しているな。でも、大事なことなので。

ここはRubyがちょっと(いや、だいぶ)弱いところなので、今後力を入れないといけないだろう。

というわけで、the 0.8 true languageを備えるべき特質について考えてみた。 私の見解だとLispやRubyはけっこういい線行ってると思う。 Pythonはいい言語だけど、ちょっと文法が融通きかないので、内部DSLには向かないかな。 ここは違うアプローチを使うのだろう。

この考察から考えると、今後Java方面では、ますますのXMLの活用とJVM上のJavaでない言語の台頭が予想される。 というか、もうかなり出てきてるよね。JRubyとかGroovyとかScalaとかClojureとか。

あまり有効な結論もないまま終わる。