■

RubyKaigi 2日目: Comming soon...

Future
未来について話します

• Ruby conf 2001
  • Virtual Machine -> 1.9 2007

Yet anotherとつけたものは生き残る。Rubyもご多分にもれず

• Ruby conf 2002
  • M17N
  • Native thread
  • Generational GC

• Ruby conf 2003
  • Local variable scope
  • Multiple assignment -> 1.9 2007
  • Method visibility
  • Keyword argument -> 2.0 2013
  • Method combination -> 2.0 2013
  • Selector namespace -> 2.0 2013
    • as refinement
  • Optional static type

• Ruby conf 2004

未来についての話はなし
笹田さんがYARVの話をした

• Ruby conf 2005
  • Stabby lambda -> 1.9 2007
  • Real multi-value
  • Traits

• Ruby conf 2006

bikeshed argument encouraged
自転車置場の屋根の色をどうするかということはみんな乗ってくるけど、原子力班伝書どうするのみたいな大きな話だとみんな乗ってこないという話。
そんな感じで特になし

• Ruby conf 2009
  • Complex literal -> 2.1 2013
  • Rational -> 2.1 2013
  • True division
  • Bitmap making -> 2.0 2013
  • Symbol GC -> 2.2 2014

• Ruby conf 2010
  • Mix
  • Module#prepend -> 2.0 2013
  • Refinement -> 2.0 2013
  • mruby -> 2012

7/22入った

わたしたちはサメのように泳ぎ続けなければならない
そろそろ燃料を投入しようじゃないか
Ruby 3.0
10年くらいのスパンになるかもしれないけど

• Concurrency
• JIT (LLVM?)
• Static typing

ここ最近出てくる言語は静的型付けの言語ばかり

Scala, TypeScript,Go

Why not Ruby?

Type Annotation
Feture #9999 by Davide D'Agostino

def connect(r -> Stream, c -> Client) -> Fiber
...
end

Function Annotations
Python REP:3107

def connect(r: Stream, c: Client) : Fiber
...
end

ruby の場合キーワード引数になっちゃうから:はつかわないけどだいたいいっしょ。
ただし、ドキュメント的な意味、言語としてはチェックしない

why static?

• Performance
• Compile-time check
• Documentation

JIT

誰もRubyがはやくなることには文句はない
でも、それによるトレードオフとしてほんとにstatic typingが必要なのか？

LuaJITがあるのでdynamic typing はJITの妨げにならない。
スピードのためにstatic typingは必要ない。

Compile Time check

まあこれは確かにあるといいよね

• Static analysis
• Refactoring

Documentation

コメントのなかにぼんやり書いてあったり、変数名から推測したりするけど型があるほうがより明確。ソースとコメントの乖離もない。

why not static typing?

Static typingはRubyと相性がよくない?

• Duck typing
• Optional
• DRY

Duck typing

アヒルのように歩き、アヒルのようになくならそれはアヒルとみてよい
Dave Thomas

型情報がある世界から型のない世界にもっていくと型情報が失われてしまい、二度と戻ってこない

Duck typingのようなRubyにとって重要な特性を捨ててそれはRubyと呼んでいいのか？

Optional

TypeScriptの場合、全体的には静的な型だけど動的な型も使える。

どこかの言語みたいにv5とv6とは違う言語とかそういうことはしたくない

Dry原則

Don't Repeat Yourself
(これもDave Thomas?)

Avoid duplication
プログラミングはコンピューターに何をさせたいかを書くこと、 型情報としてあれ書いてこれ書いてって指示することはもうさっき書いたじゃんってなる。型書きたくない。

soft typing

型を明示的に書かなくても推論でなんとかできるところはあるのではないか

best-effort
お行儀のいいプログラムを書いているとだいたいうまくいくくらいな感じでよい

型というものをメソッドの集合と捉えればいい

Subset
サブセットというと、機能縮小版みたいに思えるけど、対象となるクラスの範囲がせまいといういみ

IDEの補完ができたりしたらよい

日経Linux 2014年9月号/10月号に記事書きました
10月号/11月号だったかも…

サブセットの範囲内であれば、いいことがあるけど、それを外れたらSuper-setにフォールバックすればいい。
今でもRuby良い言語ですよねｗ

コミュニティとして死なないように次のわくわくする未来に

質疑

A: (Soft typingについて? subsetについて？)流行らなかったことに関して

Q: そもそも難しいあとづけで設けるということがとてもむずかしい

A: サブセットが小さすぎると困る
おそらくif文で分岐すると推論できなくなる。でもif文がサブセットに入らないとこまる

Q: そのばあいはORでいいんじゃないか

A: メタプログラミングは初期化の処理の時点でモンキーパッチングしたりメタプログラミング的なことをしているので、そこを除外すればよいのでは

Q: それはその時点で実行してる

A: そういうアイデアがどこかにあった

Q: それは検討してみる

■

RubyKaigi 2014 二日目

いえ、もう三日目なんですけどね。
昨夜は懇親会もないので、そのへんにいる人*1を捕まえて飲みに行きました。
今日は二日酔いです。ログを清書する時間もありませんでした。
今日もロギング中なので、なかなかあげられないと思います。
なので、終わってからまとめてあげようと思います。

*1:Matzとかそのへんを歩いていたので捕まえていきました。

■

RubyKaigi1日目を終えて

数年ぶりのRubyKaigiでテンションあがってます。勢いでログ書き続けていますが、ちょっとつらくなってきました。
2007年と状況も違いますが、モチベーションも公式でやるほどは上がりませんね。
今どきは資料ばかりかビデオも公開されたりしますよね。ログなんて労力の割に実りが少ないです。（RubyKaigiは資料・ビデオ公開あるんですかね…？ビデオはさすがになさそうな気がしますが...）
よくみるとわかりますが、実は歯抜けになっています。英語の発表はなかなか理解できません。特に実装の細かい話などはお手上げでした。（前回はzundaさんに英語はおまかせしてました。）

というわけでモチベーション下がってますが、実りが少ないと言いつつも、自分自身にとってはログらなきゃーということで聞き方も真剣になるので、同じ参加するにしてもちょっとは身になっているような気がします。
せっかくなのでこのまま勢い余って最後まで続けてみようと思います。

あと、ログに書けなかったこと

実はセッションとしては、本日最後の「Ruby committers vs the World」が一番おもしろかったんじゃないかと思います。さすがに疲れたのと自分も楽しみたい雰囲気だったので（真剣に聞くというよりおもしろがるセッションだったので）ログはやめました。
これこそログ残すべきだったなーとちょっと後悔です。（ログるのすごく大変そうだったけど）

あとはパーティタイムもすごく楽しかったですねー
RailsGirls Taipeiからも参加している女の子たちがいて、とってもキュートでパワフルで元気づけられました。（よーし、おばちゃんもがんばっちゃうぞー！）
最後にMatzとも記念撮影できたし大満足ー！でした。

Taipei Girlsたちと

すごいメンツ！！！

■

RubyKaigi: Inside RubyMotion for Android

FRENGLISH sorry

2001からRubist まだ20歳でした。

Perlが好きでした。
PerlでWebアプリを書いてました。
ある日デバッグをしてPerlへの愛がなくなりました。(すいません。Perlよく知らなくて何が起こったのかわかりませんでした。なんかminifyされたようなコードが…)

Pythonを試そうとしたけどIRCで誰かがRubyがいいよって教えてくれました。

Programming Ruby

Rubyが好きな言語になりました。
(パチパチ)

ありがとうMatz

RubyMotion iOS

Hello World in Ruby

not Bridge

Builtin Classes

• Objct <-> NSObject
• String <-> NSMuutableString
• ...

Not an interpreter

• evalはつかえない
• ruby -> AST LLVM IR -> ? -> machine code

だんだん早口になってわからなくなった

RubyMotion で開発されたプロダクト

• Frontback
• A Dark Room

• iOS8 Support
• arm64 support comming soon
• iphone6 maybe

RubyMotion Android

• Smartphone Market Share
• Tablet Market Share

どちらもandroidがiOSを抜いている

Public beta Available yesterday

simple command line interface

• Create a new project

% motion create ...

• Rake Tasks

% rake -T

• Run in Emulator
• Create a release build

% rake release

などなど

Keep using your favorite editor
Eclipse使わなくていい

Demo

How does it work?

Runtime

• Brand-new implementation of Ruby
• Unified object model Java
  • JNIからRubyMotionを呼び出している

Object model

Builtin classes based in core java

• String <-> java.lang CharSequence
• Array <-> java.util.ArrayList
• ...

Memory management

Android Garbage Collector

• Generational
• Concurrent
• Per-thread allocation pool

Grobal reference object

@x = Object.new

Compiler

• Static compilation to machine code for JNI
• Creates DEX Instruction
• Emits DWARF metadata
  • dwarfdump

このへんの話は理解できなかった

REPL

LLVM JITがAndroidで動かない
dlsym()
シンボルとアドレスを取ってきてMacで実行みたいな感じ？(わからなかった)

Let's Recap
Share code across platforms

■

RubyKaigi: Non-Linear Pattern Matching against Unfree Data Types in Ruby (Egison Pattern Matching in Ruby)

Satoshi Egi

Egisonというパターンマッチ言語を作っている。RubyからもつかえるようにGemつくった。

無限リストのパターンマッチもできる
-> 双子素数のリストもパターンマッチできる

Qiita でも炎上した
http://qiita.com/egisatoshi/items/38f7f8aef32ac67ccd4b

パターンマッチの例

match(self) do
with(User.(_name, _, _, _, true)) {"Hello Prof. #{name}"}
with(User.(_name, _, _, true, _)) {"Hello Dr. #{name}"}
end

みたいな感じで書ける。
ホントはもっと長いソースだったけど、途中で断念

コンビネーション関数の例

ループをネストして書かなければならない例も1行で書ける

Non-Linear Pattern Matching

_a, __("a + 1"), __("a + 2"), *_

みたいにかくと[1,2,3]みたいのを取り出せる

トランプのストレート・フラッシュのパターンも書ける

このへんであーなるほどって思った。確かにトランプゲームなどのルールや戦略を記述するにはよいと思った

お気に入りは双子素数

match_stream(Prime) {
wth(List.(...))
}

prime_twins.take(10)

みたいな感じで...の中に双子素数のパターンを書いておくと、最初から10組の双子素数を返す

Egison Gemも作ったらか使ってみください。

** Egisonについて
人間の直感にあった言語が必要だ
パターンマッチ志向というパラダイムを提唱しています。

麻雀の上がり判定をEgisonで書きました。

Not the usual suspects: 10 plucky programming languages on the rise | InfoWorld

Mind Map on Programming Language

Programming Language

• Mathmatical Abstraction
  • Function Modularity
    • Lexical Scoping
    • Higth Orderd Function
• Type System
  • Type Check
  • Type Interface
• Pattern Matching
  • Non-linear Pattern
• Computer Abstraction
  • Memory Operation
  • Distributed Computing
• Human Understandablity
  • Friendly Syntax

Pattern Matchingでやりたいのは

• パターンマッチのモジュール化とか
• レキシカルスコープをもつパターンマッチ言語

SQLに変わるクエリ言語
twitterのUserグラフのクエリをSQLよりも簡潔に書ける

PR
CodeIQでEgisonの記事書きます
問題も出題します。

質疑

A: はやさはどう？

Q: あんまり考えていない。たぶん早い

A: デバッグが大変かと思う。ツールはない？

Q: 僕は大変だと思わないです。
ループで書くよりわかりやすい

A: 簡単？

Q:

• 友達は3時間で分かった
• 楽天では合計20時間くらいで
• Lispとかそういう言事同じくらい

ちょっとだけ感想

パターンマッチ志向というのは面白い考えだなと思った。けど、SQLと比較しちゃうと速度がきになるところ。
表現はSQLよりは柔軟そうなので表現の自由度と速度のトレードオフになりそう。両立できれば例えばNoSQLのデータストアのクエリとか応用はありそう。

■

RubyKaigi: Symbol GC

nariさん
NaCl

GC本はAmazonでは絶版。達人出版会で買ってね！
http://tatsu-zine.com/books/gcbook

SymbolはID。

:symbol

シンボルの落とし穴

• すべてのGCはGCされない
• 脆弱性につながる
  • ユーザーの入力をシンボルにすると…
  • Digest認証のヘッダーのキーをto_symしてシンボルにしていまうと…

シンボルがGCされるか？
他の言語をみても、されるのとされないのがある…

Scalaの例

symbolの実態はJavaのStringでSymbol Tableというハッシュテーブルで管理されていて、Weak Referenceで参照している。

Rubyの場合

symbolはFrozen Stringを参照していて、global_symbolsというハッシュテーブルで管理されている。<- C言語の領域
C言語側ではIDで参照している。

GCの対象になっていない。

なぜシンボルがGCされないのか…

GCするとglobal_symbolsのエントリも削除する。
そうするとC extensionのなかでIDで参照しているものが迷子になり、不整合が発生する。

Rubyの世界で死んだSymbolがCの世界では生きている

どうするか？

Immortal SymbolとMotal symbolにわける

:sym -> Immortal

いままでとはあまり変わらないねー

"sym".to_sym -> Mortal

global_symbolsのなかで、IDではなく、symbolとして格納される

同名のImmortal symbolがある場合

Immortal symbolがあって、同名で"sym".to_symとかすると、ImmortalがMortalに化ける。

from Mortal to Immortal

メソッドを定義するとき
define_method("foo".to_sym){}
(メソッドはIDで参照しているから？)MortalがImmortalに化ける。

A new pitfall comming!

Immortal SymbolはGCされない
Motal -> Immortal への変換がおこることがある

質疑
Q: メソッド他にIDが要求される場合はない？

A: Rubyあんまり書かないので、わからない。出してみてなにかみつかるかも

■

RubyKaigi: Building the Ruby interpreter -- What is easy and what is difficult?

Koichi Sasada

キーノートは笹田さんです。
なんと、意外なことに*日本語で*キーノートとしてスピーチするのは初めてとのこと
そして、なんとなんと、明日は結婚記念日(1周年)だそうです！おめでとうございます！！
そして、YARVから10周年（そういえば、未踏で同期だったんですよねー）

アンダースタンディング コンピュテーション―単純な機械から不可能なプログラムまで

Contributions

• YARV (1.9~)
• Native thread (1.9-)
• Fiber (1.9-)
• New method cache (2.0-)
• Flonum(on 64bit CPU) (2.0-)
• RGenGC (2.1-)
  • Incremental GCの話は明日くらいにでるるびまに書いてる。
• Reserch projects
  • Performance
  • Parallel
  • Profiler
• Community activities

何が簡単で何が難しいの？

mission: Qualityを高める

• Reliability / Availability
• High performance
• Low machine resourcees
• Good compatibility
• Extensibility

これらはそれぞれTrade-offがあるよね

トレードオフに打ち勝つ

Rubyのすごいところは、豊富な言語機能と書きやすさのトレードオフに打ち勝ったこと
さらいパフォーマンスなどのトレードオフに打ち勝っていきたい

Easy

Serial execution Designing simple VM
シンプルなVMをデザインするだけなら簡単

YARVつくるときはtest caseがあったのでとても助かった。でも、まず、テストフレームワークが動くまで大変だった。

Hard

Keeping productivity
VM code needs many similar codes
Solution: VM code generator

Aggressive optimization
最適化をアグレッシブにやるとRubyの動的な特性によって、その最適化が戻されてします。(ex. method redefinition)

Interoperability with C codes
Ruby -> C Cの領域に入ると、Rubyのコードとの対応がわかりにくくなる

Parallel execution

Easy

並列スレッドを提供するだけなら簡単

Hard

Provide good programming experience

• 並列プログラミングは難しいよね

interpeter should be robust

• 同期が難しい

typical bugs

• Data race
• Atomicity violation
• Order violation
• Non-deterministic nature

並列プログラミングで難しくなってRubyが楽しくなるといやだ

他の言語では…

• ちゃんと書けばsafe
• safeでないコードが書けない

実装によっていろいろ。トレードオフの関係

トレードオフ
free() と GC
みたいな関係

Idea

• MVM: Multiple virtual machines
• Smaller isolated ruby
• Introduce "owner thread" for each objects

Make program deterministic
バグがあったら簡単に検出できたほうがいい

GC Performance

GCを書くのは簡単だけど
バグなく実装するのが大変
アルゴリズムは簡単だけど、アルゴリズム以外の面でバグなく動くようにケアすることが大変

GC.verify_internal_consistency

Measurement

実行時間を図ることは簡単だけど
そもそも何を測るのか？

クラウドよりも物理マシンのほうがよい
いろんなOS、複数のアーキテクチャ

何を？
discourse benchmark

実行時間？メモリ使用量？（ピーク、平均、中間？）

Development community

コミッターになるのは簡単
ruby developerになるのは難しい
keep motivation and continuous development

Ruby Under a Microscope: An Illustrated Guide to Ruby Internals

3日目…

質疑

Q: 手伝ってほしいこと

A: 家探してる
並列処理をどうするかが近々の課題だと思っている

Q: 笹田さんがいままでに直面した課題で一番難しくて、これ解決したわーって思えること

A: 世代別GC
泥臭い課題でprocが大変だった

Q:並立処理が得意な言語に任せればよいのではないか

A: 同意するが、 自分でつくったほうが楽しい。自分がつくるかは別としてやると良い仕事だとおもう。