Asianux Road Show 2007 まつもとゆきひろさん、基調講演のメモ

by tanabe on October 16, 2007

2007/10/16 Miracle Linux 社開催の Asianux Road Show 2007 へ行ってきた。そのうち、まつもとさんセッションのメモ書き。急いでメモったので、理解が違っているところや聞き漏れ、聞き間違いがありえる。読まれる方は、そこを理解したうえで読んでください。

タイトル
Ruby からのメッセージ

自己紹介
  • プログラマ
  • オープンソース開発者
  • 言語デザイナ

世に言語の種は尽きまじ
  • 一説には数千とも数万とも
  • ほとんどは消えていく
  • アイディアの具現化
  • いつか自分の言語を
  • 言語を作りたい人は一定数いる
  • Ruby という名の言語も3つ存在する
  • ただ、ほとんどは寿命が短く使われない
  • 作者しかユーザがいない、とか

先端言語と普及言語
  • 言語における対立軸
    • 一般向け/学術向け
    • 最新技術/枯れた技術

先端言語
  • 特定のアイディアに深く依存
  • 応用範囲が狭い
  • アイディアの実用性を証明(検証?不確か)

先端言語
  • 論理プログラミング: Prolog
  • 関数プログラミング: FP (functional programming/ジョンバッカス), huskell, erlang, ...
  • オブジェクト指向: Simula (Entity のデータ構造をADTで表現), Java, C++, Smalltalk, 各種Lisp, Perl, Python ...
  • イテレータ: CLU (繰り返しの抽象化 MITバーバラリスコフが開発, OOPに近い考え方)
  • ゴール指向: Icon (バックトラッキングが組み込まれている)
  • 玉石混交で他の言語の礎となることが多い
  • 概念が形を変えながら取り込まれる

例外的先端言語
  • Lisp
  • Smalltalk
熱狂的ファンを獲得。実用性もある。が、広まることはない

普及言語
  • 先端から学ぶ
  • 枯れた機能優先
  • 実用的
  • だが、面白みは少ない # 言語で冒険しないから
Java でOOPを知った人は多いだろうが、実際は60年代に考え方は発生している
  • ガベージコレクションも普及した が、 Lisp によって 60 年代頭に登場
  • 先端言語の概念が普及言語に取り込まれるまで30年くらいかかる

普及言語
  • Fortran
  • C
  • C++
  • Java

先端から普及へ
  • 再起
  • 抽象データ型 # データのカプセル化を行う
  • オブジェクト指向
  • 関数指向 # 関数そのものをデータとして扱い、関数そのものをデータとして適用する.
Javascript なんかはオブジェクト指向と関数指向の両方を備えている。化粧し損ねて顔がくずれた Lisp とでもいうか。。 ← 素材は良いという意味だと思われ。

先端技術とはなにか
  • より抽象的
  • より簡潔
  • より生産的
  • より変化に強い

先端的普及言語
Ruby
普及言語でもっとも進化したもの

Ruby の特長
  • オブジェクト指向プログラミング言語(下とかぶってる。写し間違ってる?)
  • 純粋オブジェクト指向
  • 高階関数

純粋オブジェクト指向
  • 文字列
  • 数値
  • 配列
  • その他すべて

文法
  • Lisp: S式
  • Smalltalk: メッセージ
  • Python: インデント
  • Ruby: 保守的
外見がふつう。ブロックを閉じる end は algol からもらった。

DSL
  • Domain
  • Specific
  • Language
  • 専用言語風汎用言語

DSL
Rakefile
Rake = Ruby Make
task :default=>[:test]
task :test do
  ruby "test/unittest.rb"
end
一見すると専用の言語のようだが、実は単なる Ruby のプログラムなので、やろうと思えばなんでもできる。

DSL
単純な文法だと
→ 複雑。(コード省略)
Ruby のような言語の力がなく単純な文法で DSL ぽいものを書くと、括弧などの記法上の制限が多くて複雑な見た目になる。DSL ぽく見えない。

高階関数
  • クロージャ
  • ブロック

Ruby の特徴
  • ブロック 
  • Duck Typing
  • メタプログラミング

ブロック
  • コードの塊
  • メソッドに付加
  • 拡張可能な制御構造

ブロック
  • 繰り返し
  • 条件判断
  • データの加工
  • など

繰り返し
 3.times do
    puts "hello"
  end
  a = [1,2,3]
  a.each do |i|
    puts i
  end 
ブロックを導入することで、ループのための文法を定義しなくても繰り返しを実現できる。文法を変えることなく、制御構造を拡張することができる。

条件判断
 a = [1,2,3,4]
  a.detect {|x| x % 2 == 0}
  a.select {|x| x % 2 == 0}
  a.reject {|x| x % 2 == 0}
ループや制御構造を使って実現するようなことが、簡潔な表現が可能になる。意図をそのまま表現することが可能になる。

データ加工
 a = [1,2,3,4]
 a.collect{|x| x * 2}
  a.sort_by{|x| -x}

スコープ制御
 open(path) {|f|
     ...
  }
  # ブロックを抜けたらファイルが close されるので意図が明確に表現できる

  catch(:foo) {
    throw :foo
  }
  # 専用の制御構造を導入しなくても、単なるメソッドで実現できる

動的型
  • 変数・式に型なし
  • 実行時に型が決まる
  • エラーチェックも実行時
  • 型の宣言不要 → 簡潔
  • 型に束縛されない → 柔軟

Duck Typing
アヒルのように鳴き
アヒルのように歩くのは
アヒルに違いない
ほんとは何かわからないけど、振る舞いからアヒルだとして扱っていい という考え方。オブジェクトの型情報よりもオブジェクトのインターフェイスを重視する。

Duck Typing
型よりも
インターフェイスを重視
メソッドを満たすもの

Duck Typing
StringIO
  • 文字列への入出力
  • 継承関係なし
  • 実装共有なし
  • 外見は同じ
Ruby のプログラムで IO を期待しているところに StringIO を渡すとほぼ間違いなく動く。これが醍醐味であり強み。Java だと型の宣言と一致しないと受け付けない。共通 interface が必要になる。interface がなければ wrapper が必要だったりする。 → 面倒。事前に考えないと分岐ができない。Ruby ならだいたい問題ないよ。

メタプログラミング
  • プログラムを操作
  • 情報取得
  • プログラムを変更

メタプログラミングの力
  • ActiveRecord
    • Object-Relational
    • DBスキーマのみ
    • クラスはスキーマから
オブジェクトのアトリビュートなどはスキーマ情報から取得し、直接書き換えちゃう。

ActiveRecord
クラス定義これだけ
class User < ActiveRecord::Base
end
中身はスキーマから
設定ファイルをいじったりが必要ないので、メンテの負荷が減る。

この辺からかなり速度がアップ。メモの精度がさらに微妙なことに。

メタプログラミング
  • DBスキーマを読み
  • 属性を自動定義
  • 人手いらず
メタプログラミングの力。他の言語でもできるけど、結構面倒。Ruby はメタプログラミングに最適化されているので便利。人手が省ける。

メタプログラミング
真の違いは
哲学に基づいたバランス
他にもできるのはある。

Ruby の哲学とは?
  • 簡潔さ
  • 書きやすさ
  • 単純さを追求しない

簡潔さは力なり
by Paul Graham
  • Fred Brooksの法則
  • 簡潔さ ≒ 効率
あるプログラマが一定期間に生産できるプログラムコードの量は一定。だから言語の力で生産性の勝負が決まる。

書きやすさ
  • 少ない記述
  • 少ないタイプ量
  • 実行可能擬似コード
教科書に出てくるような擬似コード(細かい記法や規則を省略してアルゴリズムだけを表現した簡易コード)を書くと、それが動くというのが言語デザイナの一つの目標。Ruby は良い線いっている。

サンプル:階乗
  • Java で
  • Lisp で: コードが減る
  • Ruby で: もっとコードが減る。読みやすい。
  • Ruby with inject
  • Ruby with inject on Ruby 1.9 # inject(&:*)
コードは写せなかった...

サンプル:ネットワーク
一行で書けちゃいます。これも写せず...

 

続く二枚は気になるスライドだったけど、タイトルだけでほとんどスルー。細かい項目は写せず。読み取れず。

単純さを追求しない
人の好みは単純じゃない

どうでもいいことだけど、写したメモを見たら「人の交尾は単純じゃない」と typo していた orz

Ruby on Rails
web development that doesn't hurt. # 痛くないWeb開発

opinionated software ソフトがプログラミングに影響を与える
自己主張のあるソフトウェア。自分の意見を持ってる/押し付ける。

sapir-whorf仮説
  • 言語は施行に影響を与える
  • 制約を与える
  • (?)

バベル17
言語が思考に影響を与える
バベル17表紙画像。

言語からのメッセージ
メッセージが含まれている

Ruby が与える影響とは
  • プログラミングは楽しい # 昔は楽しかった。仕事でやると面白くない。楽しさを思い出したい。
  • プログラマは素晴らしい
  • プログラミングはわくわくする
  • 苦労はコンピュータへ
  • 人間は楽を
  • 記述は関係
  • 生産性は高く
  • 変化に強く
→ Enjoy Programming!
これが Ruby に振りかかった魔法。

Ruby の今後
  • 趣味から仕事へ
  • スケーラビリティ 
    • データ量
    • アクセス数
    • プロジェクト規模
テラバイトのデータを扱いたいとか、極端に大きなアクセス数をさばきたいとか、Rubyで百万行とか、今後はサポートしていかないとなぁと思ってる。

Ruby 1.9
  • 12月リリース予定
  • 新機能(M17Nなど)
  • パフォーマンス向上

ruby 2.0(2010年?)
  • 未来のいつか
  • より冒険的な機能
    • traits
    • パッージシステム
    • アスペクト指向 など

他のセッションも含めて、とても面白い内容でした。どうもありがとうございました。

追記。Asianux Road Show へのリンクを追加。資料を頂いたので、こちらは特にメモしていませんが、よしおかさんのセッションも非常にためになりました。福岡・大阪の方はチャンスがあるのでぜひ。あと、インテルのアーキテクチャの話も普段あまり触れない分野なので興味深かったです。