動的言語で大規模開発

uy · 2012/07/24(火) 09:10:42.04

たててみた

**デフォルトの名無しさん** · 2014/11/30(日) 14:03:15.99

>>530
シートベルトだよ
離陸と着陸の時以外は外しても困らんかも知れんけど

**デフォルトの名無しさん** · 2014/11/30(日) 14:13:11.05

別に何も拘束されてないけどなｗ

単にコードが読みやすくなるだけ。
人とコンパイラにとって可読性が高いコードになる。

可読性が高いから理解しやすく、理解した情報を使って
バグが少なく開発のサポートができるようになるわけ

**デフォルトの名無しさん** · 2014/11/30(日) 15:35:01.93

REPLとかで「このオブジェクトって何ができるんだっけ？」って調べるのは
動的言語では典型的な開発手法で、恩恵に預かってる開発者は多いと思うけど
静的型の補完も一緒だよ
単純にタイプ数をちょっと減らすとか、そういう話じゃない

**デフォルトの名無しさん** · 2014/11/30(日) 15:37:46.89

何のメソッド使うか分かってるんならヘボい補完でも十分じゃね？

**デフォルトの名無しさん** · 2014/11/30(日) 15:58:11.94

全部把握できる程度のチープなライブラリを使って
一人で小さなプログラムを開発するなら
ヘボい補完でも十分じゃね？

**デフォルトの名無しさん** · 2014/11/30(日) 16:11:04.82

>>540
Cくらいならともかく、ライブラリは肥大化の一方なわけで有限の記憶力を
ライブラリの引数や戻り値を完璧に覚えるより別の方に振り分けたいと思う
人も少なくないんですよ。

**デフォルトの名無しさん** · 2014/11/30(日) 16:19:35.18

>>535
わかった。では1999年ではどうだ？

Remove Class
Rename Class
Remove Instance Variable
Rename Instance Variable
Abstract Instance Variable
Create Accessors for Instance Variable
Remove Class Variable
Rename Class Variable
Abstract Class Variable
Create Accessors for Class Variable
Remove Method
Rename Method
Add Parameter to Method
Remove Parameter from Method
Rename Temporary
Inline Temporary
Convert Temporary to Instance Variable
Extract Code as Temporary
Extract Code as Method
Convert Superclass to Sibling
Inline Call
Push Up/Down Method
Push Up/Down Instance Variable
Push Up/Down Class Variable
Move Method to Component
Convert Instance Variable to ValueHolder
Protect Instance Variable
Move Temporary to Inner Scope
http://twiki.cin.ufpe.br/twiki/pub/SPG/WeeklySeminar/PracticalAnalysisForRefactoringDonRoberts1999.pdf

**デフォルトの名無しさん** · 2014/11/30(日) 16:33:33.88

>>543
静的型と動的型で同じ「Rename method」というリファクタリング機能をサポートしていると言っても、
動的型のそれは http.connect のメソッド名を変更したら
無関係な db.connect のメソッド名も変わってしまうような代物だろう

**デフォルトの名無しさん** · 2014/11/30(日) 16:45:52.62

>>544
それは人間が頑張ればいいだけの話だろ。
手抜きするな。努力しろ。

**デフォルトの名無しさん** · 2014/11/30(日) 16:52:19.04

動的言語における効率とは「問題の棚上げ・先送り」と表裏一体であり
問題の発見・防止が重視される大規模開発とは真逆の志向である

**デフォルトの名無しさん** · 2014/11/30(日) 16:54:52.49

>>544
そんなことをする馬鹿にはリファクタリングツールの使用はお勧めできない。

**デフォルトの名無しさん** · 2014/11/30(日) 16:58:31.17

>>547
一番のバカは使い物ならないツールを作ってる動的言語の連中だな

**デフォルトの名無しさん** · 2014/11/30(日) 17:02:44.20

>>545
人間が頑張らなくてもいいようにツールは進歩しているのですが？
頑張らなくなって良くなった分、他にリソースを回すとか考えられないんだろうな。

**デフォルトの名無しさん** · 2014/11/30(日) 17:04:54.56

コンピュータにやらせるなんてアホ
脳が腐る。
人間がシコシコ変換するることで
ボケが防止される

**デフォルトの名無しさん** · 2014/11/30(日) 17:10:09.29

>>546
そうなんだよね。結局問題を先送りしてるだけ。

だいたいさ、コードの中でこの変数（httpとか）は
connectを呼び出しているって書いているから
この変数はconnectを持っている型だって決まってるわけだよね。

動的型付けであっても、型は決まってる。

だからそのことをコードに書いておけばいいわけよ。
それが変数の型宣言というもの。

型宣言しておけば、コードとその型に矛盾が起きるような修正が
発生した時、それをすぐにコンピュータが検出できる。
検出した問題を人間がみた時にも、すぐにその原因がわかりやすい。

どうせコードでは型は特定の型じゃないと動かないんだから
その型であるって明示しておけばもっと便利になる。

動的型付けでは不可能なレベルの完璧な補完っていうのも
その高度なコード解析能力の一端にすぎないんだよ。

**デフォルトの名無しさん** · 2014/11/30(日) 17:23:36.91

>>548
くやしいのうwwwくやしいのうwww

>>551
否定はしないけれど、視点の違いとか「ものは言いよう」という側面もあるな。

「真のソフトウェア工学が開発されるまでの次善の策は、
　あらゆる要素について極端に遅延結合な動的システムを使って開発する事だ。」
http://metatoys.org/oxymoron/oxymoron.html

**デフォルトの名無しさん** · 2014/11/30(日) 17:25:33.97

まあ中規模くらいなら動的言語の気楽さ>静的言語の堅牢性だけど
大規模になって全体のコードを把握できなくなると気楽さ<堅牢性になるよね

**デフォルトの名無しさん** · 2014/11/30(日) 17:37:33.47

>>552
動的と動的型付きは違うからね。

そもそもコードが「静的に型付きされているのと同様」に
特定の型じゃないと動かないように書かれているわけで。

**デフォルトの名無しさん** · 2014/11/30(日) 17:40:58.65

>>552
その頃言われていた「遅延結合」っていうのは、
遅延ではない結合、つまり特定の型以外には結合しないという意味で
それを解決したのが、継承やインターフェースでしょう。

継承やインターフェースは、指定した型＋その型を継承したもの
（もしくはインターフェースを持っているもの）に
動的に結合しているわけで、遅延結合になっている。

**デフォルトの名無しさん** · 2014/11/30(日) 17:41:53.12

静的言語だとテスト工数が減るとか、動的言語だとテスト工数が増えるとかあるの？

**デフォルトの名無しさん** · 2014/11/30(日) 17:47:36.29

>>556
コンパイルエラーをミスと考えるかバグと考えるかで話が違う。

テストはバグを見つけるもの。
だから普通はコンパイルエラーによるミスは
テストで見つけるものではない。

だから本当の意味でのテストの量は同じだが、問題はミス。

静的型付け言語ならミスは、ミスとしてテストの前段階で弾くことができるが、
動的型付け言語だと、テストの段階で弾くことになる。
（しかも静的型付け言語ならミスは修正箇所をコンピュータが示すから素早く解決できるが、
動的型付け言語だとバグを探すのと同じ作業をしないといけなくなる）

そういう点で、動的型付け言語ではテストでやるべきことが
増えるのでテスト工数が増えることになる。

**デフォルトの名無しさん** · 2014/11/30(日) 18:12:40.43

>>536
制約だな。

**デフォルトの名無しさん** · 2014/11/30(日) 18:24:06.55

>>558
それを言うなら、契約って言ったほうがかっこいいな。

契約プログラミングといえば、EiffelとD言語ぐらいだけど、
型っていうのもある意味契約だからね。

この引数は、○型であるという事前条件
この関数は、○型を返すという事後条件

**デフォルトの名無しさん** · 2014/11/30(日) 18:24:17.69

なんだ
このスレの静的厨は静的型が制約だということも理解せずに喚いてたのか
初心者としても筋が悪いな

**デフォルトの名無しさん** · 2014/11/30(日) 18:25:23.77

ここの人たちにとってC++のテンプレートを引数に取る関数ってどういうふうに捉えられてるの？
template<typename T> void f(T func)
みたいないわゆるダックタイピング

**デフォルトの名無しさん** · 2014/11/30(日) 18:26:57.46

>>534
Static Typing vs. Dynamic Typing という対比はよく見かける
しかし structural subtyping vs. duck typing という対比は知らないね
もし「いくらでも目にする」のなら、ソース(学術的文献)を示せばいい
簡単な事だろ？

ましてや
> 「構造的部分型付けは公称的部分型付けとダックタイピングの間に位置する」あるいは
>「構造的部分型付けは公称的部分型付けとダックタイピングとのハイブリッドである」
なんて奇妙な主張は聞いたことが無い

blog記事を批判するつもりはないが、そんな個人メモを元にして
「動的型言語の補完がどうあるべきかの指標になる(>>533)」と主張するのは
馬鹿だってこと

**デフォルトの名無しさん** · 2014/11/30(日) 18:31:27.03

>>561
> ここの人たちにとってC++のテンプレートを引数に取る関数ってどういうふうに捉えられてるの？

┃ template<typename T>┃ void f(T func)
↑ ここからここまでが、型 ↑

HOGE_T void f(T func)

置き換えるならこんなふうに捉えてる。

> みたいないわゆるダックタイピング

それをダックタイピングとは言わない。

**デフォルトの名無しさん** · 2014/11/30(日) 18:36:30.75

そもそもduck typing自体まともな定義はない

**デフォルトの名無しさん** · 2014/11/30(日) 18:44:16.77

function foo(a) {
a.bar()
}

bar() を呼び出せるなら何でも foo の引数に入れられるのが
ダックタイピングというのはどうだろうか
このスレだけでも

**デフォルトの名無しさん** · 2014/11/30(日) 19:22:49.09

> bar() を呼び出せるなら何でも foo の引数に入れられるのが

それってさfoo関数の引数 aはbarメソッドを
持った型ではなければならないってことだよね？

コードに書くならば

function foo(/* fooメソッドを持った型 */ a) {
a.bar()
}

**デフォルトの名無しさん** · 2014/11/30(日) 19:26:23.25

間違えたｗ

function foo(/* barメソッドを持った型 */ a) {
a.bar()
}

そして、大概は一つのメソッドだけ使うことはないから、

function foo(/* barとbazメソッドを持った型 */ a) {
a.bar()
a.baz()
}

あぁ！もう面倒くさい。

// Hogeインターフェース = barとbazメソッドを持っていること

function foo(Hoge a) {
a.bar()
a.baz()
}

わかりやすい。Hogeってみるだけで barとbazを持っていることがわかるし
もし持っていないものをaに入れるコードを書いたらコンパイルエラーが出る

**デフォルトの名無しさん** · 2014/11/30(日) 19:32:01.35

>>566
ただし、継承関係や共通のインターフェースを持たなくても
bar() を呼び出せるなら foo に入れられなくてはならない

**デフォルトの名無しさん** · 2014/11/30(日) 19:47:43.07

http.connectを呼び出す関数に、
db.connectというメソッドを持ったオブジェクトを
入れても期待通りに動くことはまず無い。

二つの無関係なオブジェクトが同名のメソッドを持っていて
呼び出せるからといって、それはバグにしかならない。

メソッドに名前空間がないような形で使う動的型付け言語では
このような問題が起きる。

静的型付け言語ではインターフェースという型を定義することで、
同名であっても本質的に違うものは、違うものとして扱うことが出来る

**デフォルトの名無しさん** · 2014/11/30(日) 19:53:09.38

どんな御託を並べても
インターフェースがduck typingは無いわw

**デフォルトの名無しさん** · 2014/11/30(日) 19:56:23.78

インターフェースがduck typingなどとは
ひとことも言ってない。

duck typingは不要。ガアガアと鳴いたからたから
といって人間はアヒルでしか無い。
アヒルだ、空を飛べ。人間は飛べません。はいバグです。

実際には鳴くメソッドがあればアヒルである
ということになって更に意味がわからない。

もちろん、アヒルである条件をインターフェースとして定義しているならば
そのインターフェースを備えているものは、アヒルでいいですがね。

メソッド一つが有るか無いかきめんなよ。

**デフォルトの名無しさん** · 2014/11/30(日) 19:57:27.20

訂正

duck typingは不要。ガアガアと鳴いたからたから
といって人間はアヒルにはならない

**デフォルトの名無しさん** · 2014/11/30(日) 19:59:03.44

>>562
ググるとかしたことないのかね。

**デフォルトの名無しさん** · 2014/11/30(日) 20:01:50.38

したことある人が、リンクを見つけてきて
ここに書けばいいと思いますが、

それを要求することは酷なことですね。
だってググっても見つからないのだから。

**デフォルトの名無しさん** · 2014/11/30(日) 20:04:43.51

ダックタイピングの説明として
「アヒルのように歩き、アヒルのように鳴くのなら、それはアヒルである」
という言葉があるが、

それを、
アヒルのように歩くとアヒルのように鳴くという
アヒルインターフェースを実装しているものはアヒルである。
というふうに読み替えると

これは実は静的型付け言語の説明だなとわかるはずである。

**デフォルトの名無しさん** · 2014/11/30(日) 20:09:27.69

>>569
mysql.connect と postgresql.connect は置き換え可能だけど？

**デフォルトの名無しさん** · 2014/11/30(日) 20:11:34.14

>>575
>>570

**デフォルトの名無しさん** · 2014/11/30(日) 20:15:01.73

>>576
両方が同じデータベースインターフェースを
サポートしているならばそうだろうね。

現実的な話をするならば、mysql.connect を
使うコードは、実際にはmysql.connect だけを
使うことはなく、複数のメソッドを使う。

だから、その複数のメソッドというものを
定義しないといけない。

そしてその定義したものがインターフェースであり
そのインターフェースを使いますよと宣言するのが
型宣言なのである。

そうすればある型がデータベースインターフェースを
定義していることを保証する型宣言だけあれば、
全てのメソッドを安心して使うことが出来る。

このオブジェクトはconnectメソッドは持ってるけど、
disconnectメソッドを持っていないかもしれない
なんてことはなくなるのである。

**デフォルトの名無しさん** · 2014/11/30(日) 20:16:45.31

足し算と掛け算のある型なら複素数でも行列でも良いとかいうパターンは有るな

**デフォルトの名無しさん** · 2014/11/30(日) 20:21:32.59

足し算をaddメソッドだとして、
addメソッドさえあればなんでも使えるかというと

（addメソッドでググって一番目にでてきた）
> Addメソッドとはエクセルのシートに表とグラフを同時に表示するメソッドです。

に対してもうまく動くことはおそらくないだろう。

つまり名前が一緒でも、正しく動くとは限らんのさ。
だから名前と意味が一緒であることを保証するために
名前をつけたものが型なのである。

**デフォルトの名無しさん** · 2014/11/30(日) 20:24:10.20

>>575
アヒルのインスタンスを実行時にその振る舞いから分類するところがポイントなのであって
アヒルというクラスに対してコンパイル時に分類するのはダックタイピングじゃないよ

というわけでダックタイピングはインターフェースや構造的部分型とは全く別

**デフォルトの名無しさん** · 2014/11/30(日) 20:25:36.35

>>580
Excelのaddメソッドは戻り値の型が違うだろ

**デフォルトの名無しさん** · 2014/11/30(日) 20:25:53.73

>>580
だから同じ「意味」に対して名前を揃えるのが動的言語でのメソッド名のつけ方だ

**デフォルトの名無しさん** · 2014/11/30(日) 20:26:04.76

アヒルのインスタンスを実行時にその振る舞いから分類というけれど、
コード自体は、実行時に分類してないんだよ。

コードは、アヒルであること、を前提として書いてる。
実行前にコードで分類しているのに、
なぜ実行時に分類しないといけないのか。

型は動的に変わるが、コードは静的なのである。

**デフォルトの名無しさん** · 2014/11/30(日) 20:28:54.03

>>583
> だから同じ「意味」に対して名前を揃えるのが動的言語でのメソッド名のつけ方だ

だから大規模では無理なんだよ。

大規模＝大多数の人間が係る。場合によっては全く知らない人が作った
ライブラリを使うこともあるしな。

そんなんで、すべて意味を揃えるなんてことは不可能
いくつもの意味を持つ英単語なんてざらにある

単語の意味を揃えるのは不可能。というのが大前提

**デフォルトの名無しさん** · 2014/11/30(日) 20:29:37.63

>>584
コードも動的だから「動的」なんだよ
それとも、単なる動的型付けの話をしている？

**デフォルトの名無しさん** · 2014/11/30(日) 20:30:01.03

>>581
Interfaceも構造的部分型も実行時に動的に分岐する
そうでなければポリモーフィズムとは言わない

さらに言えば、構造的部分型は「アヒルというクラス」に対して分類してるわけでもない

**デフォルトの名無しさん** · 2014/11/30(日) 20:31:08.34

>>585
とはいえ
Objectクラスだけで500近いメソッド数をもっているにもかかわらず
不特定多数の開発者からのコードを集めたSmalltalkシステムは
ちゃんと動いているわけだが

**デフォルトの名無しさん** · 2014/11/30(日) 20:33:46.05

>>588
SmalltalkでObjectに500もメソッドなんてねーよｗ

あったとしたら、アンチパターンゴッドクラス
（設計の一部分（クラス）に、過剰に機能を集中させること）に
適合してしまうわｗ

**デフォルトの名無しさん** · 2014/11/30(日) 20:34:01.13

>>587
分岐（メソッド探索）の話などしていない

どの式がどのインターフェースを実装しているのかを実行時に検査してるのか？
どの式がどの型の部分型かを実行時に検査しているのか？
へー、それ、なんていう言語だい？

**デフォルトの名無しさん** · 2014/11/30(日) 20:36:14.22

>>589
わかりやすい静的脳だな
Smalltalkでは色々なパッケージがObjectクラスにメソッドを追加していくんだよw

**デフォルトの名無しさん** · 2014/11/30(日) 20:36:20.46

>>585
大規模なシステムは作者が異なる様々なライブラリを使うが、違うライブラリ間で
同じ意味の機能に同じインターフェースを持たせるのは不可能

インターフェース方式は、ある数値計算ライブラリと別の行列演算ライブラリを混ぜて使う場合などで問題になる

**デフォルトの名無しさん** · 2014/11/30(日) 20:40:02.67

>>590
実行時にvalidationするのがダックタイピングというなら
構造的部分型は確かに違うな

"If it walks like a duck and quacks like a duck, it must be a duck"

という文章からそのような意味を読み取るのは無理だが

**デフォルトの名無しさん** · 2014/11/30(日) 20:40:22.76

>>591
> Smalltalkでは色々なパッケージがObjectクラスにメソッドを追加していくんだよw

最悪だな。JavaScriptでprototypejsっていうのがあったけど、
名前が標準のメソッドとobjectに追加したメソッド名が
被って大変な目にあっていた。

それ移行Objectにメソッドを追加するのは
ダメなやり方だって広く知られるようになったね。

**デフォルトの名無しさん** · 2014/11/30(日) 20:40:39.28

>>570
いや。duck typing とは言わないけれど、Smalltalk の動的型と
同様の柔軟性を持たせつつ型安全を目指したのがインターフェイス。
（Eiffel流のクラスの継承をサブタイプに使うと型安全でないという流れで）
http://www.cs.utexas.edu/~wcook/papers/InheritanceSubtyping90/CookPOPL90.pdf

**デフォルトの名無しさん** · 2014/11/30(日) 20:43:21.18

>>592
Haskellの型クラス、Rustのトレイト等が
それらの問題点を解決している

**デフォルトの名無しさん** · 2014/11/30(日) 20:45:52.98

>>593
If it walks like a duckというのは、実際のitの振る舞いのことを指しているのだから実行時のことだと考えるのが自然だと思うが？
If it will walk like a duckならばコンパイルだろうけどな。

**デフォルトの名無しさん** · 2014/11/30(日) 20:47:16.39

>>594
>名前が標準のメソッドとobjectに追加したメソッド名が
>被って大変な目にあっていた。

初心者だな
当分補助輪をつけることをお勧めするw

**デフォルトの名無しさん** · 2014/11/30(日) 20:48:14.19

>>589
Squeak Smalltlk（Squeak4.5）で調べたけど
いろんな意味で残念ながら^^; 500近くはあるな。Object allSelectors size "=> 486 "

**デフォルトの名無しさん** · 2014/11/30(日) 20:51:13.03

>>592
>大規模なシステムは作者が異なる様々なライブラリを使うが、違うライブラリ間で
>同じ意味の機能に同じインターフェースを持たせるのは不可能

そういう初心者は補助輪（静的型）を使えばいいよw

ちなみに動的言語の環境では
様々なライブラリでどういうメソッド名がつけられているか検索する仕組みと
指定したメソッド名のメソッドを検索する仕組みが
遥か80年代から用意されていたりするけどなw

**デフォルトの名無しさん** · 2014/11/30(日) 20:53:54.80

>>599
動的言語では全オブジェクト共通の語彙が重要だから当然そうなる

**デフォルトの名無しさん** · 2014/11/30(日) 20:56:59.55

>>555
とりあえず、アラン・ケイが書いていることを読もうや。
そもそも「その頃は」って思い込み激しすぎるだろう。
これ書かれたの1999年～2000年頃だし。

**デフォルトの名無しさん** · 2014/11/30(日) 21:05:38.46

>>597
静的型でも振る舞うのは実行時だろ
チェック自体はコンパイル時だが

で、どこに実行時にチェックすると書いてある？

**デフォルトの名無しさん** · 2014/11/30(日) 21:09:31.70

>>601
とはいえ、Squeak のカオス化に嫌気してフォークされた Pharo は
だいぶ減らして 374 だし（3.0調べ）、VisualWorks はもとより 303（7.10調べ）だけどね。

**デフォルトの名無しさん** · 2014/11/30(日) 21:10:47.94

>>601
補完がうんこ過ぎるからそんなカオスになってんだろ
クラスの名前空間としての機能が死んでる

**デフォルトの名無しさん** · 2014/11/30(日) 21:13:30.42

>>600
静的型（ていうかJava）のインターフェースの話だよ
動的なら名前合わせときゃ良いんだから問題ならん

**デフォルトの名無しさん** · 2014/11/30(日) 21:15:20.91

>>599
Pharo 3.0 は、374

**デフォルトの名無しさん** · 2014/11/30(日) 21:17:02.28

>604 で既出だった orz

**デフォルトの名無しさん** · 2014/11/30(日) 21:30:34.30

>>608
乙^^

ちなみにファンお手製で変わり種のGNU Smalltalkだとわずか123。
http://ideone.com/D9lo8c

**デフォルトの名無しさん** · 2014/11/30(日) 21:50:46.91

>>595
>いや。duck typing とは言わないけれど、

引用した論文は静的型付け言語における継承の意味論モデルに関する内容であり、
duck typing や interface とは直接的に関係してない
Smalltalk における継承の意味について、Effel は Smalltalk と同じように柔軟だけど型安全ではなく、
Modula-3 や C++ は型安全だけど Smalltalk とは意味が異なる
この論文では、Smalltalk と同じ継承の意味を持ちかつ安全な新しい意味論モデルを提案している

まったく無関係な論文を引用して、いったい何を言いたいのか意味不明だね

なお、ここで言う「継承の意味」とは、具体的には Smalltalk の疑似変数 self や super のこと
たとえば Smalltalk と同じ意味論を持つ Ruby では(Smalltalk と同様な)疑似変数 self と super を持つ
それに対して、Smalltalk とは異なる意味論の Modula-3 を参考にして継承が設計された Python では
self や super に相当する疑似変数は存在せず、わざわざメソッドの引数で __self__ を明示しなければならない
結果として Python は動的型付け言語であるにもかかわらず、Smalltalk や Ruby と同等レベルの柔軟な
オブジェクト指向プログラミングができないという言語設計上の欠陥を抱えている

この意味論モデルは、以下の論文で詳細に解説されている
http://www.cs.utexas.edu/~wcook/papers/thesis/cook89.pdf

**デフォルトの名無しさん** · 2014/11/30(日) 22:04:51.19

オブジェクト指向プログラミングをするのが目的ではない。
巨大なシステムをより早くより安全に開発するのが目的なのだ。

**デフォルトの名無しさん** · 2014/11/30(日) 22:11:54.90

オブジェクト指向上の欠陥とやらが何か知らんが、
そのお陰で実用レベルの型推論（補完や型検査）が出来てるなら面白いな

**デフォルトの名無しさん** · 2014/11/30(日) 22:22:44.40

人間が間違わずに全てのコードを脳に記憶して
タイプミスすらしないことを前提にするならば、
コードにわざわざ記憶の断片（つまり型情報）を書く必要はないよ。

それができないから、型情報を書いたほうが
わずかの手間だけで、そのあとずっと楽ができるわけで。

**デフォルトの名無しさん** · 2014/11/30(日) 22:32:19.86

>>570
すまん。こっちだった。
Interfaces for Strongly-Typed Object-Oriented Programming
http://www.cs.utexas.edu/~wcook/papers/OOPSLA89/interfaces.pdf

**デフォルトの名無しさん** · 2014/11/30(日) 22:48:40.83

>>612
>オブジェクト指向上の欠陥とやらが何か知らんが、

有名な Python のself地獄だよ
キーワード「python self地獄」で検索すればGoogle先生が教えてくれる
Python しか知らなければself地獄が気にならないかもしれないけど、
Smalltalk や Ruby を知っている人からすれば、無知は幸せだなぁと見る
これの基礎が「継承の意味論における差異」になる

なお単に意味論の違いだから、self地獄と引き換えに
実用的な型推論(補完や型検査)が手に入るわけではない
両者の間に直接的な関連性は無い（言い換えるとスレチな話題）

**デフォルトの名無しさん** · 2014/11/30(日) 22:53:53.26

>>615
self地獄はGuidoが変人なだけで意味論なんて高尚な理由じゃねーだろ
self省略できるようにパーサ弄れない意味論的理由は何だよ
それこそ関係ねーよ

**デフォルトの名無しさん** · 2014/11/30(日) 22:55:23.26

>>610
> Ruby では(Smalltalk と同様な)疑似変数 self と super を持つ

Ruby の super は Smalltalk とは違うよ？

**デフォルトの名無しさん** · 2014/11/30(日) 22:55:36.39

>>615
> 両者の間に直接的な関連性は無い（言い換えるとスレチな話題）

スレの主題に沿っているのは補完や型チェックの方だけど

**デフォルトの名無しさん** · 2014/11/30(日) 22:57:41.96

>>614
この論文内では duck typing という用語は一度も使われていないし、
タイトルに Strongly-Typed と書かれているように静的型付け言語に関する内容だ

で、いったいどこから duck typing を連想したの？

**デフォルトの名無しさん** · 2014/11/30(日) 23:00:20.47

典型的なアスペか。

**デフォルトの名無しさん** · 2014/11/30(日) 23:01:15.62

>>618
>スレの主題に沿っているのは補完や型チェックの方だけど

まったくそのとおり
だから >>610 では

> まったく無関係な論文を引用して、いったい何を言いたいのか意味不明だね

と書いた

**デフォルトの名無しさん** · 2014/11/30(日) 23:09:04.67

>>619
1989年の論文にduck typingと言う用語が出てきたらそっちの方が驚くわ
abstract斜め読みしただけだがSmalltalkには言及されてんぞ

**デフォルトの名無しさん** · 2014/11/30(日) 23:09:46.51

あれ？int型の+とstring型の+に対するオーバーロードみたいな話になってる？
無知なら口だすなと言われそうなので黙っておきます…

**デフォルトの名無しさん** · 2014/11/30(日) 23:22:20.73

>>621
そうか。じゃあスレ違いの話は止めないと荒らしになってしまうな

**デフォルトの名無しさん** · 2014/11/30(日) 23:27:42.56

>>616
Python のオブジェクト指向は Modula-3 を参考にしているけど、
Modula-3 のオブジェクト指向は Simula を参考にしている
そして疑似変数 self の概念は Simula には存在せず、
Simula を参考にした Smalltalk で生まれた
だから、Modula-3 や Python に疑似変数 self は存在せず、
これを模倣するにはメソッド引数で明示的に __self__ を
渡さなければならない訳

あと疑似変数 self の値は実行時に決まるから、
もし Python で __self__ を省略できるようにするためには、
構文論(syntax)の変更すなわちパーザの改造だけではダメで、
意味論(semantics)も変更しなければならない

こうした背景も知らずに「変人だから」という理由で決めつけるのは、
Guido氏に失礼だと思うよ

**デフォルトの名無しさん** · 2014/11/30(日) 23:31:44.94

もう、超優秀なIDEがあって動的構造取り入れた c# 最強って事で良いんじゃないの？

**デフォルトの名無しさん** · 2014/11/30(日) 23:42:47.38

>>626
MSが他の処理系を駆逐する勢いでLinux版頑張ったら近い将来にそうなるかも。
種だけ蒔いて後知らねっていう可能性も高いけど。

**デフォルトの名無しさん** · 2014/11/30(日) 23:43:33.56

>>622
> 1989年の論文にduck typingと言う用語が出てきたらそっちの方が驚くわ

そうだろ、だから驚いて >>619 では

>>で、いったいどこから duck typing を連想したの？

と書いた

論文を引用するのはいいけど、この論文をどう解釈して duck typing に結びつけたのか、
説明が無ければ意味が分からんという話だよ

>abstract斜め読みしただけだがSmalltalkには言及されてんぞ

Smalltalk の柔軟な継承を強い型付け(=静的型付け)なOO言語に取り込むために
インターフェイスを用いる、という文脈でね
動的型付けを濫用するというニュアンスを持つ duck typing とは何の関係も無い

この論文、型システムと言語設計に興味がある人にはとても有益だから、
斜め読みと言わずじっくり読んでみたほうがいいと思うな

**デフォルトの名無しさん** · 2014/11/30(日) 23:44:44.78

>>616
http://neopythonic.blogspot.jp/2008/10/why-explicit-self-has-to-stay.html

・ただの関数を、後からクラスにメソッドとして後付けできること（そのとき暗黙のselfの扱い）
・decoratorがあるから（動的にstatic methodやclass methodに変更できる）

というのが理由だそうだ

**デフォルトの名無しさん** · 2014/11/30(日) 23:49:11.15

>>627
Roslyn凄そうだが、どんだけのヤツが付いていけるんだろ。

**デフォルトの名無しさん** · 2014/11/30(日) 23:50:00.23

>>626
動的構造ってなんだっけ
実行時型情報ならC++にもあるけど
むしろ実行時型情報がない言語の方が良いんだろ
ほぼ全部関数型言語だけど

**デフォルトの名無しさん** · 2014/11/30(日) 23:52:00.50

>>629
Smalltalk や Ruby なら、暗黙のselfがあっても
後からクラスにメソッドを後付けできるのにね....

**デフォルトの名無しさん** · 2014/11/30(日) 23:53:34.74

言語だけでいうならRustに期待しているんだが……

**デフォルトの名無しさん** · 2014/11/30(日) 23:57:11.19

>>682
> 後からクラスにメソッドを後付けできるのにね....

それは静的型付け言語のメリットをなくしてまで
やるべき重要な事なのか？

**デフォルトの名無しさん** · 2014/11/30(日) 23:58:47.30

>>634
おいおい、Python は動的型付け言語だよ

**デフォルトの名無しさん** · 2014/11/30(日) 23:59:07.80

>>632
その代わりに関数が無くてProcオブジェクトとかいう
キモい代用品を使わされるゴミでしょRubyって