1.
SOFTUMEYA, LLC.
MASASHI UMEZAWA
2016 LLoT

2.
Smalltalkとは
 ミニマリズムの言語
1. すべてはオブジェクト
2. オブジェクトがメッセージ送信する
のみで成り立つ
 予約語は6つのみ
nil, true, false, self, super, thisContext
 少ないルールの組み合わせによって何でも作っていける

3.
プログラミング言語の壁
 使う人
 アプリケーションのユーザ
 作る人
 プログラマ
 言語を作る人
 プログラミング言語開発者
 Smalltalkには上の区別が無い
 「この言語にはこれがないから…」
=>「だったら作ればいいじゃん」
 「オブジェクトにメッセージを送る」ことで、アプリのみならず
プログラミング言語そのものを変更できる

4.
自由の世界の重要性
 Kent BeckのFacebookの記事
 http://www.facebook.com/notes/kent-
beck/design-space/510856375613898
 "The greater my knowledge, the freer I feel. It’s
like walking under a Montana sky instead of
being jostled down a narrow, one-way corridor"
 「知れば知るほど、自由を感じる。狭い一方通行の
廊下に押し込まれて進むのではなく、モンタナの空
の下を闊歩するようなものだ」

5.
デモ
 クラス名やメソッド名を複数行対応にする
 http://www.slideshare.net/umejava/multilines
Object subclass: #'
／ ＼
／ ─ ─＼
／ （●） （●） ＼ よく考えたら俺いらないな
| （__人__） |
/ ∩ノ ⊃ ／
( ＼ ／ ＿ノ | |
.＼ “ ／＿＿| |
＼ ／＿＿＿ ／
'
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
category: 'Test-Multilines'

6.
デモ
 super を拡張して super super を作る
 真ん中のメソッドを飛ばす
 http://www.slideshare.net/umejava/supersupersubsub

7.
静的型の導入とか
 とはいえ定期的に現れるトピックではある
Typed Smalltalk (1988)
StrongTalk (1993)
SmallInterfaces (2000)
Gradualtalk (2014)

8.
Smalltalkにとって型とは？
 あるオブジェクトから見たときのクラス
 すべてはオブジェクト
1, true, nil なども
SmallInteger, True, UndefinedObject
クラス自身もオブジェクト
Number class => メタクラスNumber
Metaclass class => メタクラスMetaclass
 実行時にclassと聞くと必ずクラスの役割を持つ
オブジェクトが返ってくる
 という点で、「動的で強い型づけ」の言語
 「型」という概念はないとも言える

9.
型を明示的に宣言する利点
 不適切なオブジェクトにメッセージを送ることに
なるなどの誤りが、未然に判明する
 実行させなくとも、クラス定義やメソッドシグネ
チャを見てオブジェクトの責務、仕様が把握できる

10.
静的なものが皆無
 Smalltalkにおいて動いていないものは存在できない
 クラス定義、メソッド追加なども含め、すべて動的
に行っている
 クラス定義
ClassBuilderにクラス生成依頼のメッセージを送る
 メソッド定義
ClassA>>mを定義(accept)するとmのバイトコードが
ClassA classのインスタンス変数methodDictに格納される
 「実行前」に型を「宣言しておく」という文化がない
 動かしながら型っぽいものを決めていきながら動く

11.
型を明示的に宣言する利点
 不適切なオブジェクトにメッセージを送ることに
なるなどの誤りが、未然に判明する
 実行させなくとも、クラス定義やメソッドシグネ
チャを見てオブジェクトの責務、仕様が把握できる
 実行し続けている環境においてどれだけの意味が
あるのか？
 こうしてソースを眺めている間にも、
裏でうようよオブジェクトが動いている… !!
が

12.
Typed Smalltalk (1988)
 最初期のアプローチ
 VMの高速化が大きな狙い
 負担となる静的な型指定を省くため、型推定を行う
 結局のところ世に出てはいない

13.
StrongTalk (1993)
 http://www.strongtalk.org/
 初期はBrandと呼ばれるStructural Typing
=> 後にNominal Typingに変化
 型推定はしない
 静的な型チェックは動的な実行モデルに影響を与えない
 リリース直前に会社ごとSunに買われてしまった
 コンセプトの多くはDartへ

14.
SmallInterfaces (2000)
 http://www.jot.fm/issues/issue_2002_05/article1/
 http://www.mars.dti.ne.jp/~umejava/smalltalk/s
tClasses/smallInterfaces/
 Interfaceの概念の導入
 軽量でポータブル
 変数の型宣言は行えない
 動的、構造的にInterfaceに適合しているかを
チェック

15.
Gradualtalk (2014)
 http://pleiad.cl/research/software/gradualtalk
 いいとこ取りを狙う
 Traitsを使って型システムをon/off
 Structural & Nominalの両方をサポート
 Optional & Gradualの両方をサポート
 型推定は(まだ)しない
 Gradualモードで動かすと型チェックが激しすぎて遅く
なる

16.
現状は
 "I’m not against types, but I don’t know of any
type systems that aren’t a complete pain, so I
still like dynamic typing." - Alan Kay
 思い切りlate-binding側に降った言語の良さを失わ
せないような静的型システム・環境とは？

17.
産業界では
 実のところあまり困っていない
 オブジェクトが答えてくれる
 ALLSTOCKER.com by
 建機売買の総合プラットフォーム
498クラス、7705メソッド
継続ベースのWebアプリフレームワーク
Seasideを魔改造して使っている

18.
個人的には
 ライブラリのリリースのタイミングなどで、型を明
らかにさせたいときもある
 リファクタリング時に、型情報を使って影響範囲を
正確に把握したいこともある
 オンデマンドに候補となる型を浮かび上がらせるよ
うなもの
 があったら使うかもしれない