動的言語で大規模開発

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

たててみた

**デフォルトの名無しさん** · 2014/11/29(土) 12:44:23.44

標準ライブラリや他人の作ったライブラリの全てを記憶できる変態でも無い限り
コード補完によってドキュメントを含め表示して選択出来るってのは生産する
上ではかなりのアドバンテージなんだけどね。大昔のクソなIDEや最近のでも
動的言語に対応しているのはクソなIDEしかないから、そういう技術の進歩を
知らない原始人には理解できないことなんだよ。

**デフォルトの名無しさん** · 2014/11/29(土) 12:49:43.77

動的型付きにすることで失われていることのほうが多いと思う。
それで、動的型付きにしてまで守ろうとしているものってなに？

**デフォルトの名無しさん** · 2014/11/29(土) 13:13:21.80

ドキュメントについては仕様書が欲しいか具体例が欲しいかによる
ただちに必要ではないことまで書かれているのが仕様書
ある時点で必要だったことしか書かれていないのが具体例

具体例から仕様を想像できるような変態は全てを記憶ではなく推理している

**デフォルトの名無しさん** · 2014/11/29(土) 13:24:38.99

スタートダッシュと試行錯誤じゃないの
軌道に乗ったら捨てて作りなおせばいいのよ

**デフォルトの名無しさん** · 2014/11/29(土) 13:24:42.22

>>472
コード補完で出てくるドキュメントなんて知ってるメソッドなら役に立つが
知らないメソッドをそれだけでなんとかしようなんて無理だがや

**デフォルトの名無しさん** · 2014/11/29(土) 13:54:58.03

>>476
javaならソースに書かれているjavadocが出る。いわゆるAPIリファレンスと
言われるものが表示される。visual stadioだとmsdnに書いてあるのが出る。
APIリファレンスが役に立たないとか言っちゃうような無能はプログラムを
書くのを辞めたほうがいい。

javadocが出たことによって他の言語でもソースに埋め込んだコメントを
別ドキュメントに言語の標準かそれに近いレベルで提供されることが多く
なった。ただ別ツールを使ってまでドキュメントを出力するようなところは
殆ど無かったけど、IDEで自分や他人の書いたドキュメントまで手元で
参照できるようになったことで、どのレベルでコメントを書けばよいうかと
いうことに気づけた人はそれなりにいるかと思う。

書かないと煩く言われるから書くというのから、自分で書いたコードでも
元のコードを見なくても分かるように書くというのに変われた人は多いと
思います。最低でも自分で書いたコードを自分の為にというのがやり
やすくなった。

**デフォルトの名無しさん** · 2014/11/29(土) 14:00:18.54

そういえばvisual studioだとサンプルコードを検索ダウンロード出来る機能まで
付いたんだっけかな。

**デフォルトの名無しさん** · 2014/11/29(土) 14:06:58.21

>>477
javadocは、どの程度のが出るかしらんが、Visual Studioで出るような
サマリーだけじゃ役に立たんがね。

IDEで出るのはあくまでも補助的なもんで、ちゃんとしたAPIのドキュメントは
msdn見ないと駄目だろ。APIの注意書きとかサンプルコードとかはIDEでは出ないだぎゃー

最近のVisual Studioは、msdnの全文が出るんけ?
底辺土方なんで最新版は知らんのじゃ～

**デフォルトの名無しさん** · 2014/11/29(土) 14:07:50.21

>>478
マジか?
随分と進歩したもんじゃの

**デフォルトの名無しさん** · 2014/11/29(土) 14:13:44.81

>>479
> javadocは、どの程度のが出るかしらんが、Visual Studioで出るような
> サマリーだけじゃ役に立たんがね。

サマリーでも役に立つと思うし、リンクになってるから
ヘルプ調べるのも速くなるんだが？

**デフォルトの名無しさん** · 2014/11/29(土) 14:25:05.29

>>481
そういうIDEのヘルプ機能よりもGoogle先生のが役に立つ
Google先生とIDEのインテリセンスが無いとプログラムの生産性が著しく落ちるw

**デフォルトの名無しさん** · 2014/11/29(土) 14:33:59.73

>>479
ttp://docs.oracle.com/javase/8/docs/api/index.html
どのレベルも何も↑の各クラス、メソッドのがそのまま出るんだが。
これは英語だが、日本語訳のがある場合はそっちを使うことが出来る。
で、ここに書かれていなくて他に書かれているというドキュメントは存在しない
わけで、ググってどこにも無ければこれに頼るしか無い。このリファレンスが
分からない役に立たないっていうやつは少なくてもjavaはやらないほうがいい。

**デフォルトの名無しさん** · 2014/11/29(土) 14:36:32.05

>>482
初心者に多いね。一次ソースを見ないで、
個人のブログとかみるやつ。
英語読めないからとかなのかな。

**デフォルトの名無しさん** · 2014/11/29(土) 14:37:24.55

で、そんな話はいいとして、動的型付け言語が
動的型付けにしてまで守ろうとしているものって何よ？

**デフォルトの名無しさん** · 2014/11/29(土) 14:38:14.93

動的言語でも変数aをMyClass型と教えればメソッド一覧は出せるだろ

**デフォルトの名無しさん** · 2014/11/29(土) 14:39:37.78

>>486
それで、aがMyClassだっていうのは、
人間がいちいち教えてあげるの？

aが絶対MyClassだっていうのなら
それをコードに書いておけばいいのに・・・。

**デフォルトの名無しさん** · 2014/11/29(土) 14:40:07.50

その問い自体が静的目線だってのw
視野が狭いなあw

**デフォルトの名無しさん** · 2014/11/29(土) 14:40:46.54

いちいち変数を宣言して型を指定するのとかわらないと思う

**デフォルトの名無しさん** · 2014/11/29(土) 14:42:05.95

その都度、MyClass型って教えないといけない手間がかかるのと
コードに仕様として書いておけるのの違いだね

**デフォルトの名無しさん** · 2014/11/29(土) 14:42:13.42

補完候補を500に絞り込むためだけに、aがMyClassのインスタンスでないと動かないような腐れコードにするわけか
ご苦労さまなこってw

こりゃ世の中からクソコードがなくならないわけだw

**デフォルトの名無しさん** · 2014/11/29(土) 14:43:48.06

> 補完候補を500に絞り込むためだけに
補完候補を500ってなんのこと？
動的型付けだと、その500を全て覚えてるの？
意味がわからないね。

**デフォルトの名無しさん** · 2014/11/29(土) 14:45:30.32

型を書かなくても a = MyClass() や、さらにいえば
foo(MyClass()) のようなコードがあるだけでも>>446は補完できる様になる

**デフォルトの名無しさん** · 2014/11/29(土) 14:46:28.99

逆に言えば、そういうコードがなければ
補完できないという意味である。

例えば関数の引数。これは補完できない。

**デフォルトの名無しさん** · 2014/11/29(土) 14:48:16.54

補完ってそこまで重要か
動的言語支持者の揚げ足をとるためには必要かもしれないけど
単語単位補完で十分通用してる

**デフォルトの名無しさん** · 2014/11/29(土) 14:49:08.68

型を書かなかったら a = MyClass() と a =YourClass()の両方があったら
補完がめちゃくちゃになる。
foo(MyClass()) と foo(YourClass()) のようなコードがあると
>>446の補完は使い物にならなくなる。

**デフォルトの名無しさん** · 2014/11/29(土) 14:51:15.51

>>495
> 補完ってそこまで重要か

重要ですよ。

開発効率がぜんぜん違う。

・タイプ数の省略
・うろ覚え（引数の順番程度）でヘルプを引くことの省略
・ヘルプを開く場合でもその手間の省略
・コードのミスを実行せずに知ることが出来る
・リファクタリング時に自動で安全にできることが多くなる。

これらはいらないんだ！って言うかもしれないが、
それは開発効率が大きく高まることを否定する言葉じゃないからね。

**デフォルトの名無しさん** · 2014/11/29(土) 14:54:43.83

>>494
引数に型が書いてなくても、実際に関数を使ってるコードがあれば
引数に入れられた値から型推論できるよねって話なんだけど

**デフォルトの名無しさん** · 2014/11/29(土) 14:55:43.43

単語単位補完って、単にタイプ数を
少し省略することしかできないからね。
しかも補完した結果が間違っていることがある。

動的型付けにおける補完の効果って
その程度しかできないし、その程度のことしか知らないから
静的型付け言語でもその程度のことだと思ってる人が多いんだよ。

ぜんぜん違う。静的型付け言語であれば補完は
タイプ数削減以上に大きく開発効率を上げることが出来る。

明らかに開発効率を上げると証明された。
動的型付けで開発効率を上げることは出来るのか？
動的型付けにしてまで守ろうとしているものはなんなのか？

**デフォルトの名無しさん** · 2014/11/29(土) 15:00:38.05

>>498
いや、だからなければ型推論できないでしょ。
「実際に関数を使ってるコード」の方が間違っていたら
補完も間違うわけよ。foo(MyClass())って使わないといけない時に
foo(YourClass())って書いてしまったら、補完もそれに合わされてしまう。

それにさ、人間の問題はどうなるのさ？

function foo(a) {} ってコードをいきなりみせられて
aは何型でしょう？ってクイズ？（笑）

リーダブルコードってわかるかな？
ライタブルコードってはいわないんだよ。

重要なのは読む時。読む時に必要な情報が欠けてる。
もしくは間違ってる。そんな信用出来ない状態では開発効率は大きく下がるよね。

で、動的型付け言語は開発効率下がると証明されたが
あがる理由は何かあるのか？

**デフォルトの名無しさん** · 2014/11/29(土) 15:11:36.58

>>500
それは void foo(YourClass a) って間違えても同じだよね

それにクイズってなんの話？IDEがあればドキュメント見れるでしょ？

**デフォルトの名無しさん** · 2014/11/29(土) 15:14:22.47

動的言語の方がコード量が減るから大規模になりにくい
短期記憶に入りやすいから効率も上がる
静的に見て機械的に処理しやすいのは静的片付け言語だけど

**デフォルトの名無しさん** · 2014/11/29(土) 15:14:41.06

> それは void foo(YourClass a) って間違えても同じだよね

定義は一箇所。

使う場所は沢山。

一個でも間違えたらどちらが正しいかわからなくなる。

**デフォルトの名無しさん** · 2014/11/29(土) 15:16:15.20

>>502
> 動的言語の方がコード量が減るから大規模になりにくい

重要なのは、タイプ量ではなくて読む量なんだよ。

動的言語のコード量が減るってようするに、
コードを理解するための情報が減るから
コードが読めなくなる。

少なければいいってもんじゃないんだよ。

**デフォルトの名無しさん** · 2014/11/29(土) 15:17:16.14

少なければいいよ
機械がコードを読み書きするんじゃなくて人がするんだから

**デフォルトの名無しさん** · 2014/11/29(土) 15:18:12.01

>>503
型検査でエラーになるから分かるでしょ

エラーにならないならMyClassとYourClassは型レベルで互換性あるってことだし

**デフォルトの名無しさん** · 2014/11/29(土) 15:20:19.64

動的型付け言語では、コードを理解するための情報（定義）が減って、
実行するコード自体の量は静的型付けでも動的型付けでも変わらない。

たとえて言うならば、
文章の枠外にある注釈を書いているのが静的型付け言語で
同じ文章でありながら、枠外の注釈を取り除いたのが動的型付け言語

注釈があればいきなり変数が出てきても、これは○型だってわかるが、
注釈がなければ、この変数に値入れてるのどこだよ。
この関数を使ってるのはどこだよと

注目して呼んでいる所以外の情報を探してこなければいけない。

**デフォルトの名無しさん** · 2014/11/29(土) 15:22:35.61

>>503
これは面白い
頻度が少ない方に権威があるという不思議なルール

**デフォルトの名無しさん** · 2014/11/29(土) 15:24:39.97

>>506
無理だよ。

例えばMyClassにhogeというメソッドがあって、YourClassには無いとする。

これをfoo(MyClass()) と foo(YourClass())に渡した所でエラーにならない。
fooの中でhogeを呼び出しているから、YourClassを渡している所が間違いだ！と
思いきや、

動的にYourClassにhogeメソッドを追加するかもしれないから
エラーとは言い切れない。

つまりエラーと出る箇所はすべて、エラーではないかもしれない。

**デフォルトの名無しさん** · 2014/11/29(土) 15:26:57.07

>>508
そりゃそうだろｗ

たった一回気をつけてかいたものと何十回も書いたもの、
どちらが間違えやすいかなんて考えるまでもない。

**デフォルトの名無しさん** · 2014/11/29(土) 15:37:19.95

>>509
動的言語の話なら、動的にメソッド追加されるケースは多くないからワーニングを出してもOKでしょ
さらにmethod_missingが定義されてる時はワーニングを出さないという工夫もできる

**デフォルトの名無しさん** · 2014/11/29(土) 15:44:49.77

動的にメソッドを追加するケースは少ない => 補完や型検査は動的言語でも有効
動的にメソッドを追加するケースが多い => 動的言語って凄く便利だね

**デフォルトの名無しさん** · 2014/11/29(土) 15:49:50.99

>>511
> 動的言語の話なら、動的にメソッド追加されるケースは多くないからワーニングを出してもOKでしょ

俺がいいたいのはそれだよ。動的にメソッド追加されるケースは多くないのに
そのために多くのメリットを捨てるだけの意味が動的型付け言語にあるのかってこと。

**デフォルトの名無しさん** · 2014/11/29(土) 15:58:27.80

>>497
>・タイプ数の省略

つまりタイプ数を省略するために
オブジェクトが持つメソッド数が僅かしかないような
ゴミみたいなライブラリを使わされるのはいやだなあ

>・うろ覚え（引数の順番程度）でヘルプを引くことの省略

補完以外にもいろいろな手段があるが？

>・ヘルプを開く場合でもその手間の省略

補完以外にもいろいろな手段があるが？

>・コードのミスを実行せずに知ることが出来る

実行すればわかることを、いちいち型として書いた上に
コードに余計な制約をつけるなんて愚の骨頂だろw

>・リファクタリング時に自動で安全にできることが多くなる。

くだらない。リファクタリングが始まったのは動的言語からだし、
リファクタリングをIDEの機能に統合したのも動的言語から。
で、補完を使うことで、可能なリファクタリングが増えるなんて初耳なんだが？

やはり静的脳で動的言語を見て「あれが欠けてる」「これが欠けてる」と言っているだけだねw
まずは自分の視野の狭さをなんとかしたら？

**デフォルトの名無しさん** · 2014/11/29(土) 16:02:07.42

補完君の要約
「ぼくがジャバでプログラムを書くのと同じやり方ができない動的言語なんて使えない」

**デフォルトの名無しさん** · 2014/11/29(土) 16:55:08.72

補完君の最大の勘違いは、
動的言語はa.と入力して出てくるメソッド名を絞り込めない
と思い込んでいること。

実際には、動的言語ではa.と入力して出てくる膨大なメソッド名の
どれでも正当なプログラムを構成し得る。
だからその膨大な候補リストは既に十分絞り込まれたもの。

ただ、静的脳の小さな容量では言語のポテンシャルが高すぎて
マトモに使いこなせない。かわいそうに。

**デフォルトの名無しさん** · 2014/11/29(土) 20:03:41.93

補完必須派に訊きたいんだけど
コンパイル時ダックタイピングともいわれる構造部分型
http://igeta.cocolog-nifty.com/blog/2008/05/subtyping.html
をサポートする静的型言語のときは、どういう候補を出すのが正解？

これがわかると、動的型言語の補完がどうあるべきかの指標になるんでは。

**デフォルトの名無しさん** · 2014/11/29(土) 21:05:19.38

>>484
オレオレOOなヤツに多いね。
自分の足りないオツムと一次ソースだけでプログラミングするやつw

個人ブログとかStackOverflowから良いコードがあればパクるのが良いねえ。
もちろん後から一次ソースで確認はする。
オレ様のゆるいオツムでは思いつかないようなクールなコードが世の中には沢山あるぞw

**デフォルトの名無しさん** · 2014/11/29(土) 22:22:32.23

>>514
リファクタリングでできることは
静的型付け言語の方がとっくに多くなってるんだよ。

始まったのは動的型付けからって
単に懐古厨なだけだろ。昔はなってｗ

最新のリファクタリング技術がどうなっているかを知ると驚くぞ。
http://nanananande.helpfulness.jp/wp-content/uploads/sites/2/2014/06/3164/1b000175b814e923b2ddeebcadbf4154-159x300.png

それに対して動的型付けの話って
昔の話しか出てないだろ。

**デフォルトの名無しさん** · 2014/11/29(土) 22:25:49.85

>>516
> 補完君の最大の勘違いは、
> 動的言語はa.と入力して出てくるメソッド名を絞り込めない
> と思い込んでいること。

なにマッチ・ポンプしてるんだよｗ

静的型付け言語では最初から絞り込めるよな？

で、動的型つけ言語は500もメソッドが出る。（ドヤっ）
そんなにたくさん候補が出たら大変だろ！（ドヤっ）

って言っておいて、今度は、

動的型つけ言語でも絞り込める時もある（ドヤっ）

ですかｗ

うん、大変だね。静的型付け言語では最初から絞り込めるよ？

**デフォルトの名無しさん** · 2014/11/29(土) 22:48:51.18

>>520は勘違いしているよ

>>516が言っているのは、数値オブジェクトに対して
文字列のメソッドを呼び出して実行時エラーになっても、
それは言語仕様上は正当なプログラムであるということだよ

もちろん言語仕様上正当であることは、バグじゃないことを意味しないけどね
オブジェクトの型に無関係なメソッド呼び出しは大抵バグだろう

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

>>517
>これがわかると、動的型言語の補完がどうあるべきかの指標になるんでは。

なぜ構造的部分型が補完の指標になりえるのか、
その理由というか関連性が説明してごらん
単なる思いつきじゃねえの？

少なくとも >>517 のリンク先blog記事では
「構造的部分型付けは公称的部分型付けとダックタイピングの間に位置する」あるいは
「構造的部分型付けは公称的部分型付けとダックタイピングとのハイブリッドである」
と主張しているけど、こんな奇妙な話は聞いたことが無い
しかも記事のネタになったソース(学術的文献)が書かれていないし、
英語版 Wikipedia の Subtyping のページでも
duck tying との関連性に対する文章に対して "citation needed" と指摘されている
おまけに記者は構造的部分型付けをサポートする言語(OCaml)を使った事が
一度も無いと正直に告白している

このblog記事はあくまで記者が型システムを勉強する過程で書き残したノートであって、
この記事を引用して >>517 が何を言いたいのか、自分には意味不明だね

なお、動的型付け言語に(形式的な型推論を基礎とした)静的型付けを導入した概念は
Soft Typing と呼ばれている
動的型付け言語の補完を検討する指標となる可能性があるのは、
どちらかといえば Soft Typing ではないかと思うね

**522** · 2014/11/30(日) 00:49:19.68

細かいけど訂正

X: その理由というか関連性が説明してごらん
O: その理由というか関連性を説明してごらん

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

ガアガアとなく人間は
アヒルである。

ダックタイピング

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

>>519
昔の時点ですでに相当できてたって話もあるぞ。

http://web.archive.org/web/20090130061934/http://www.refactory.com/RefactoringBrowser/Refactorings.html

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

>>525
同じぐらい"昔"である2009年の記事出していい？Eclipse+Javaの世界の話
http://www.ibm.com/developerworks/jp/opensource/library/os-eclipse-refactoring/

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

>>526
すまん2001年の登場当初のを貼るつもりだった。

http://web.archive.org/web/20010514165503/http://www.refactory.com/RefactoringBrowser/Refactorings.html

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

520を読むと516が言う通り補完君は動的型がまるでわかってないことが明白だ

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

補完君はキーを2,3文字入力するのをケチるために
引数がMyClassのインスタンスでなければ動かないゴミメソッドにして
どうだ静的型すごいとか言い出す初心者でしょ

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

静的型は自転車の補助輪
初心者を卒業したら外そうね

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

>>529
もうちょっと汎用的なメソッドを定義する場合、MyClassみたいな具象型よりも
Interfaceや型クラスを指定することが多いね
それで必要なだけの汎用性と静的型を両立できる

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

大規模開発で人に作らせる立場だと、プログラマに静的言語という拘束具をつけた方が楽なんだよ。チームメンバの能力によって品質が変わってはいけないし。
人を指導する立場に立ってみると分かる。

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

でも静的型を嫌がってたらGoogleとかでは働けないわけじゃん？
お前らどんな底辺企業で働いてるの？
それともニート？

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

>>522
structural subtyping と duck typing の対比なんていくらでも目にするだろう。

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

>>527
じゃあ同じように2001年という "大昔" の話をするね。
http://www.ibm.com/developerworks/library/eclipse/l-eclipse.html
Refactoring with Eclipse
Erich Gamma is the team lead for Java tools for Eclipse.
Gamma was one of the Gang of Four known for creating
the book Design Patterns: Elements of Reusable Object Oriented Software.
He also created JUnit with Kent Beck (see Resources).
Refactoring is recognized as another valuable practice in object oriented programming but,
until recently, only few tools had support for it. At OOPSLA 200,
Eclipse developers demonstrated the Refactoring support in Eclipse.
They stressed that refactoring should not alter a program's behavior.

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

>>532
> プログラマに静的言語という拘束具をつけた方が楽なんだよ

どういう点が拘束具なの？

間違える行動ができない。という意味での拘束？
それはいいことじゃんｗ

**デフォルトの名無しさん** · 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は不要。ガアガアと鳴いたからたから
といって人間はアヒルでしか無い。
アヒルだ、空を飛べ。人間は飛べません。はいバグです。

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

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

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