RTCでHow to Design a Languageを聞いてきた！

Rakuten Technology Conference

RTCのmatzさんのお話を日本語でメモしたので公開してみます。
こちらの発表です！> http://rakutentechnologyconference2015.sched.org/event/4B4Z/philosophy-behind-the-creation-of-programming-languhellip

How to Design a Language

発表者: Matz さん

すべての人は「言語」をつかう

• プログラマでもプログラマじゃなくても「言語」を扱える
  • 例えば、英語 日本語
  • これらは誰もデザインしていないよね？
• プログラミング言語も同様
  • 例えばJavaやRuby
    • Rubyは私は例外だけどね！でも僕以外の他の誰かはRubyをデザインしていないでしょ？
  • でもみんなJavaやRuby、PHPやPythonや他の言語を使ったりするよね？
    • でも使う人のほとんどはその言語のデザイナーではない

ところで、「言語」をデザインしたことはありますか？(ある？ある？？)

• 言語を設計することはそんなに大変なことではない！
• プログラミング言語はおもしろい特性がある
  • 自然言語と違っているところは意図的に設計されているところ
    • Rubyはオブジェクト指向といったように
• プログラミング言語設計者を何人知っていますか？
  • 私(Ruby)
  • Guido(Python)
  • Larru(Perl)
  • Rasmus(PHP)
  • James(Java)
  • Satoshi(Egison)
  • そこのあなた！（いたって真面目に言ってます）
    • あなた作の言語をデザインすることをお勧めしたい
    • （想像していることと少し違うかもしれないので少し説明をするよ）
• Dave Thomasと会ったときに言っていたこと
  • 「プログラミングは自分のDSL（ドメイン固有言語）を設計することだ」
  • つまり、アプリを作成する上でプログラミングすることがあなたのDSLを設計していることになるのだ
  • だから、ソフトウェアの開発をしたりアプリの開発をしているているあなたたちは独自の言語を設計していることになるのだ
  • なぜならば、インターフェースは基本的な言語だから
    • インターフェース設計
    • API設計
    • フレームワーク設計
    • これらはぜんぶ言語
    • この考え方でも、まだあなたはプログラミング言語を設計したことにはならない（僕みたいにね！
    • それでも、みんな言語を設計している！

ぼくらはみんな言語をデザインしている

• ソフトウェアを作ったり サービスを作ったり I/Fを作ったり UXをつくったり
  • これらはみんな言語なのです
• ぼくらはみんな言語設計者なのです!（でしょ？
  • 言語設計のミソは何でしょうか？

Larry Wallの場合(言語設計のミソ)

• Perlの言語設計者
  • こんな顔のね（写真を見せて！

プログラマの3つのミソ

• ひとつめ

  • 楽をする努力を惜しまないこと
    • 未来の自分ができるだけ楽に開発をできるようになるための努力を惜しまない

• ふたつめ

  • プログラムが思い通りに動かないとイライラすること
    • 思い通りに動かないとすぐにイライラするため、そのイライラを発生させないプログラミングをする

• みっつめ

  • 傲慢さ
    • 他のプログラマに自分が書いたコードについてとやかく言われたくないから美しく書く努力を惜しまない

• ぼくらはみんなより良い生活のためにコンピューターを使うよね？

  • ぼくらは自分たちの言うことをよく聞いてくれるコンピューターを使う
  • だから、ぼくらはみんなコンピューターの親分だ
  • だから、コンピューターに僕らの言葉を理解してもらう必要がある
    • 言語といってもここでは英語とか日本語とか自然言語のことをいってるわけじゃない
  • コンピューターの言語は人間中人に設計されている
    • RubyやPHPはもちろん、アプリケーションで使うI/Fも
  • 良い言語設計のミソは…！

良い言語設計のミソ

いくつかあるよ

1. 簡潔さ

• 自明的なことよりも暗黙的な方がよい
  • 一般的にこれは明らかだよね
  • 例えばCoC(Convention over Configuration)
    • 設定コードを繰り返し書く必要がないこと
      • 例えばwebサービスの設定のために何十何百ものxmlのコードを書く必要がない
  • DRY(Don't Repeat Yourself)
    • 重複、コピペを避けること
      • 10箇所にコピーしたとすると、そこにひとつバグがあった際にそのバグが潜んでいるコードをぜんぶ直さないといけない
      • 9箇所だけ直しただけで満足していたら、バグが潜んだままになってしまう
      • コピペはすごくよくないよね
• 簡潔さは生産性をよくする
  • コード量が少ないことはわかりやすいことにつながる
  • ぼくらの脳で理解できることはとても限られている
    • コンピューターにとっては膨大な量のコードは問題ない
    • でもぼくらの脳はそうじゃないから何千何万もの行におよぶコードを瞬時に理解することは困難だ

2. 推理ゲームをしない

• 推理ゲームは簡潔さと相反する
• 簡潔さを考えるときに推理ゲームを避けることを考えることになる
• コンピューターに意図を汲み取って欲しい
  • コンピューターの意図は汲み取りたくない
• なぜならば ぼくらが コンピューターの親分だから
  • コンピューターが 親分じゃないよ
• アルファシンドロームを避けるため
  • アルファシンドロームというのは、ペットが飼い主を目下だと思い暴力的になったりするやつ
  • 似たようなことはコンピューターと人間の間でも推理ゲームをしていると簡単におきてしまう
  • だから推理ゲームは避けるべきことだ

3. 心理状態を考える

• ぼくらの心理上の問題
• ぼくらプログラマの活動はよく理解されない
• プログラマはコンピューターと接しているようだけれども、プログラムをつかうのは人間だ
• ぼくらは人間のことを考えなければならない
• だからぼくらの言語を設計するときに考えなければならないのは人間がどう感じるかだ
• 簡潔さも含んでいる
• コンピューターをつかっていると小さなイライラが度重なる
  • こういったイライラに敏感にならないといけない
  • 焦りを覚えること
  • とはいっても完璧な人はいない
    • ソフトウェアの設計や作成でもだれでも間違える
    • 設計はとても難しい
    • でもぼくらはまた挑戦できる！
    • またまた挑戦できる！！よりよい言語、よりよいI/Fを！
    • だから、 成功するまで決して決してあきらめないこと！！！

4. ユーザを導く

• ぼくらは自由でありたいと願う
• でも、完全に自由だと不自由さを感じてしまう
  • だから何をすればいいのか案内してあげるといい
  • 慣例やガイドモデルとなるものや基本的な方針を示してあげるといい
  • オブジェクト指向プログラミングや関数型プログラミングはその一例
• だからユーザを導いてあげることは重要なこと
  • つかう人にとって嬉しいものであること
  • I/Fは基本的に言語
• ユーザを導いてあげる言語(I/F)に設計することは生産性の向上につながる
• ぼくらはみんな言語設計者であることを思い返して欲しい
  • 今まではそうは思わなかったかもしれない
  • でも今日の、この考え方でいくと、ソフトウェアをつくっていくことは言語設計をしていくことなのだ

素晴らしい言語を 素晴らしいソフトウェアを 素晴らしいI/Fを 設計をしよう！
そして世界を変えよう！！！

おわりに

最後まで読んでくださりありがとうございました。
乏しいリスニング力でメモしていたので自信のないところもありますが、楽しく聞かせていただきました！
これから設計するときは今回のお話を絶えず頭をよぎることになると思います。
誤解を招く点など発見した際はコメントにお願いします。