2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

静的型付け言語の潜在開発生産性は今の100倍 ×4

1 :デフォルトの名無しさん:2013/11/04(月) 22:36:14.15
人間がやっていたことを、コンピュータにやらせる。
これが生産性を上げる最大の方法。
コンピュータは間違わない、同じ事を何度も高速に行える。

その為に、コンピュータがコードの意味を正確に
認識できる方法が必要。実行しないとわからないことは
コンピュータは認識できない。

すなわち静的型付け言語であれば、実行しなくてもわかるので
コンピュータが理解できる。そうすれば様々な
コンピュータの高度な情報支援が得られる。

コンピュータのバックアップを受け、人間の生産性は
限りなく向上する。

前スレ
静的型付け言語の潜在開発生産性は今の100倍 ×3
http://toro.2ch.net/test/read.cgi/tech/1382656209/

2 :デフォルトの名無しさん:2013/11/04(月) 22:39:10.51
write once, run ...
http://toro.2ch.net/test/read.cgi/tech/1383561626/

3 :デフォルトの名無しさん:2013/11/04(月) 22:44:32.15
http://toro.2ch.net/test/read.cgi/tech/1382656209/986
なんだかインナークラスが static なクラスであることをあまり意識せずにバンバン書いていくのは気になるなあ‥‥
どうしても static メソッドを明示したこんな書き方を推奨してしまう
http://ideone.com/HHYjJV (バグ直した)
そのあたり Java から入った人はどう考えているの?

あと元プログラムの SearchLargestNode() って必要以上に難しくしてない?というかあってるの?

4 :デフォルトの名無しさん:2013/11/04(月) 22:53:03.23
>>3
>なんだかインナークラスが static なクラスであることをあまり意識せずにバンバン書いていくのは気になるなあ‥‥

どういう意味?static classはトップレベルクラスと同等になるってだけだと思うけど

5 :デフォルトの名無しさん:2013/11/04(月) 23:01:06.57
>>3
staticは極力使わないようにしている。
これを言うと知らない人は噛みついてくるかもしれないが。
staticな(クラス,変数,メソッド)はtomcatアプリケーションのオートデプロイ時に深刻な問題が発生する。

6 :デフォルトの名無しさん:2013/11/04(月) 23:02:26.67
http://toro.2ch.net/test/read.cgi/tech/1382656209/993
>再帰ってそういうものだよ。
関数を抜けるたびに値が変わるんだったらわかるけど、変わらない値を延々返すというのはねえ‥‥もっといい方法があるはずなんだけど

>Haskellのクイックソートも許せないタイプ?
in-place でないクィックソートとか意味不明:−)

7 :デフォルトの名無しさん:2013/11/04(月) 23:06:53.76
>>3
>http://ideone.com/HHYjJV (バグ直した)

どこのバグを直したのかな?修正後のはremoveがバグってるようだけど

8 :デフォルトの名無しさん:2013/11/04(月) 23:07:02.21
>>5
もとプログラム
http://toro.2ch.net/test/read.cgi/tech/1382656209/986
http://rabbit.media.osaka-cu.ac.jp/course/index.php/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0/13#2.E5.88.86.E6.8E.A2.E7.B4.A2.E6.9C.A8
ってのは static なクラスに属するべきメソッドを、static と明示せずにアウタークラスにバンバン書いているので‥‥
いや、こういうのは自動的に static method と解釈してくれのだろうか?なんだが居心地が悪い‥‥

9 :デフォルトの名無しさん:2013/11/04(月) 23:13:08.97
>>7
おっと
Node n = searchLargestNode(root.left);
n.right = root.right;
return root.left; //here, corrected.
http://ideone.com/FXiTkS
だねえ、thx

10 :デフォルトの名無しさん:2013/11/04(月) 23:14:32.13
動的言語は遅い
速くしようとしたら
型を意識しなきゃだめ
でも遅いままで問題ないことが多い
って感じかな

11 :デフォルトの名無しさん:2013/11/04(月) 23:22:33.56
まあそれでもいいかもしれないんだけど、そう言い切っちゃうともめるからなあ。
JSはCの二倍速い。
こういっておいたほうがいいよ。

12 :デフォルトの名無しさん:2013/11/04(月) 23:25:56.47
2倍って微妙だな。200倍くらいでいいんじゃね?

13 :デフォルトの名無しさん:2013/11/04(月) 23:29:45.15
いや200000倍ぐらいじゃないか

14 :デフォルトの名無しさん:2013/11/04(月) 23:32:53.70
C++はCの二倍遅いと書いたら反論があったんだけど、普通に二倍遅いんだけどなあ。

15 :デフォルトの名無しさん:2013/11/05(火) 00:02:05.60
>>3
修正前と木の構造が違うよ。
修正するならこうだと思うけど。

Node n = searchLargestNode(root.left);
if (n != root.left) {
 n.left = root.left;
}
n.right = root.right;
return n;

16 :デフォルトの名無しさん:2013/11/05(火) 00:15:39.35
>>15
>n.left = root.left;
n よりも小さなノードが n.left に連なっているはずだよ、これをすると n.left 以下が宙ぶらりんになってしまうよ
また
n.left を root.left にすると
root.left -> ...... ->n->root.left で巡回してしまうよ

17 :デフォルトの名無しさん:2013/11/05(火) 00:17:55.27
>>16
方向をつけくわえておくね
root.left (right)-> .... (right)-> n (left)-> root.left
巡回路ができるとまずいね

18 :デフォルトの名無しさん:2013/11/05(火) 00:34:50.51
もしかしてjavaってメモリー配置の最適化出来ないの?
listクラスを実際にはリスト構造にしないとかよくあると思うんだけど。
そういうこと出来ないのかな?

19 :デフォルトの名無しさん:2013/11/05(火) 00:37:17.24
>>18
どの言語でよくあるの?

20 :デフォルトの名無しさん:2013/11/05(火) 00:39:41.38
このスレで言語聞いてもJSという答えしか返ってこないと思う。

21 :デフォルトの名無しさん:2013/11/05(火) 01:23:59.47
>>16
>n よりも小さなノードが n.left に連なっているはずだよ、これをすると n.left 以下が宙ぶらりんになってしまうよ

ならないよね。

searchLargestNodeメソッドにこれがあって

if (n == root.right) {
 // root.right = null; となっていましたが,間違いです.
 root.right = n.left;
}

removeはこうやるんだから。

if (n != root.left) {
 n.left = root.left;
}

>root.left -> ...... ->n->root.left で巡回してしまうよ

しないよね。こうやってるんだから。

if (n != root.left) {
 n.left = root.left;
}

22 :デフォルトの名無しさん:2013/11/05(火) 02:08:08.48
連結リストでクイックソートする方法を教えてください。

23 :デフォルトの名無しさん:2013/11/05(火) 02:12:28.51
自己解決しました。

24 :デフォルトの名無しさん:2013/11/05(火) 04:17:42.82
10秒で書くんじゃなかったのか?

25 :デフォルトの名無しさん:2013/11/05(火) 04:21:03.19
>>5
> staticな(クラス,変数,メソッド)はtomcatアプリケーションのオートデプロイ時に深刻な問題が発生する。

なんか、こういう書き方をしているのを見ると、
オートデプロイを実運用で使用しているんじゃないのか?って思ってしまう。

デプロイはもちろん実運用でやることだが、
"オート"デプロイは開発環境でのみ使う機能だぞ。

26 :デフォルトの名無しさん:2013/11/05(火) 04:53:40.40
>>10
型付き言語なんてアセンブリ言語より遅いくせに

27 :デフォルトの名無しさん:2013/11/05(火) 04:54:48.59
動的言語はそれより更に遅いくせに

28 :デフォルトの名無しさん:2013/11/05(火) 04:55:53.79
俺には無理だけど、すごい人が頑張って
極稀に速いことがあるんだからね!

29 :デフォルトの名無しさん:2013/11/05(火) 04:57:53.98
まれに速くても意味ねーよ。

型付き言語が(最適化が不十分な一般の)
アセンブリ言語より速いという方が
まだよくあることだ。

30 :デフォルトの名無しさん:2013/11/05(火) 04:58:26.46
アセンブリは動的言語何だが
歴史としてはそれに型をはめて扱いやすくしたのが静的言語

31 :デフォルトの名無しさん:2013/11/05(火) 04:59:50.47
言っておくが型付言語には静的も動的も入ってるぞ?
そこ勘違いするなよ?

32 :デフォルトの名無しさん:2013/11/05(火) 05:00:30.81
馬鹿だwアセンブリは動的言語じゃないぞw
動的言語は動的に型が決まるから
動的っていうんだが
アセンブリ言語は、動的に型が決まらない。
型そのものが存在しない。

33 :デフォルトの名無しさん:2013/11/05(火) 05:33:48.68
>>32
ここは真面目なスレですんで
煽りは帰って
どうぞ

34 :デフォルトの名無しさん:2013/11/05(火) 05:39:12.15
あ、言い返せないんだw

35 :デフォルトの名無しさん:2013/11/05(火) 05:44:50.79
アセンブリ言語は自己書き換え可能な動的言語であり、
かつ、静的型も動的型も持たない型無し言語。

36 :デフォルトの名無しさん:2013/11/05(火) 05:54:23.95
動的に型が決まらないから
動的型付け言語ではないな。

37 :デフォルトの名無しさん:2013/11/05(火) 06:33:05.62
>>22
動的言語ならこんなに簡単に書けますお
http://ideone.com/zDYgPt

38 :デフォルトの名無しさん:2013/11/05(火) 07:30:25.25
>>32
お前まだ話の流れが分かってないのな
動的言語と動的型付け言語は別物だろが
何が話されてるのかも分かってないのに絡んでくるのはNG

39 :デフォルトの名無しさん:2013/11/05(火) 07:43:03.00
>>37
肝心のクイックソートが
ライブラリ呼んでるだけじゃないかw

40 :デフォルトの名無しさん:2013/11/05(火) 07:44:20.67
10 名前:デフォルトの名無しさん[] 投稿日:2013/11/04(月) 23:14:32.13
動的言語は遅い
速くしようとしたら
型を意識しなきゃだめ
でも遅いままで問題ないことが多い
って感じかな

↓ ワロタw

38 名前:デフォルトの名無しさん[sage] 投稿日:2013/11/05(火) 07:30:25.25
>>32
お前まだ話の流れが分かってないのな
動的言語と動的型付け言語は別物だろが

41 :デフォルトの名無しさん:2013/11/05(火) 08:03:20.15
>>22
連結リストならコムソート使いなよ、同じくΟ(nlong)だ

42 :デフォルトの名無しさん:2013/11/05(火) 08:15:14.90
アセンブリと高級言語に差があるなら
スパコンでアセンブリ使うって
でも実際はそうなってない

43 :デフォルトの名無しさん:2013/11/05(火) 09:45:13.18
とことん最適化するときは今でもアセンブラ使うよ

44 :デフォルトの名無しさん:2013/11/05(火) 16:29:08.04
>>18
Listのインターフェイスと具体的な実装は別物。
外見は等しくListでも中身は連続したメモリ領域だったり連結リストだったりDBから
引っ張っていたりRESTインターフェイスを叩いていたりと色々。

45 :デフォルトの名無しさん:2013/11/05(火) 17:10:46.19
>>5
tomcatのクラスの自動reloadの話をしているのであればこんなコンテナ側の事情それも
開発時限定の便利機能に併せてAPIの設計を曲げることなんてしないしこの例の場合単に
実装の詳細であるprivateなメソッドの話であって実際問題privateであればreloadしても
そんなにはまらん。

>>6
この例の場合「たまたま」insertやrevome等々の操作がBinSearchTreeには触れずに
個々のNodeだけを相手にして可能な実装になっているので「たまたま」staticに「も」
出来るだけであって、Nodeクラスがstaticであること云々はそれを操作するメソッドも
staticであるべきとか云々とは全く関係がが無い。

たとえばBinSearchTreeがアンドゥやトランザクションをサポートしていたり操作と
同時にファイルに永続化するような実装になっている場合はファイルハンドラ等々を
つかんでいるであろうBinSearchTreeの参照が出来ないstaticメソッドだと恐らく
書きにくいでしょ。

46 :デフォルトの名無しさん:2013/11/05(火) 17:11:55.09
あ、ごめん。>>45>>6>>3へのレスの間違い。

47 :デフォルトの名無しさん:2013/11/05(火) 18:02:37.64
QZ完全沈黙wwwww

48 :デフォルトの名無しさん:2013/11/05(火) 18:09:47.68
>>25
開発のみで使うってどういうこと?
運用できるように使わなきゃ意味ないでしょ

49 :デフォルトの名無しさん:2013/11/05(火) 20:48:59.05
スパコンでPythonが良く使われるのはなんでだろうね?

50 :デフォルトの名無しさん:2013/11/05(火) 21:04:40.18
100倍もあったら案件ひとつが1週間で終わるな

51 :デフォルトの名無しさん:2013/11/05(火) 21:09:10.07
学術系を中心にユーザが多い。
そのため科学技術計算向けに開発されたライブラリがそろっている。
大規模行列計算など正直不得意な分野もコアをCで実装したライブラリが存在する。
並列分散実行に関してもMPIのバインディングが存在したりHadoopのゲストになれる。

環境が十分そろっているだけの話であって言語自体が効率的な大規模並列計算に
向いている訳ではないと思う。

52 :デフォルトの名無しさん:2013/11/05(火) 21:16:42.30
変態的なことをしてなくて素直だから安心して使えるってことじゃねーの
それ以外はマシンパワーで補えるしな

53 :デフォルトの名無しさん:2013/11/05(火) 21:16:55.76
単純にPerlからの流れでPythonが多いだけ
研究分野って行列もそうだけど文字列操作することもかなり多いから
スクリプトのが使いやすい

54 :デフォルトの名無しさん:2013/11/05(火) 21:35:42.46
スパコンではStringBufferを使わなくても高速な文字列処理ができるんですかね?

55 :デフォルトの名無しさん:2013/11/05(火) 21:36:31.58
>>14
const + 参照使っているか?いちいちコンストラクタを走らせてるんじゃないか?

56 :デフォルトの名無しさん:2013/11/05(火) 21:43:32.94
const type&みたいのだったか
あれは何か効能あるの?インライン化されるとか

57 :デフォルトの名無しさん:2013/11/05(火) 21:54:20.98
>>56
単なるポインタ私

58 :デフォルトの名無しさん:2013/11/05(火) 22:37:04.11
>>48

(デプロイの自動化ではなく)オートデプロイという機能は
開発段階で使う機能だって

http://otndnld.oracle.co.jp/document/products/wls/docs92/deployment/autodeploy.html

> 開発ドメインへのアプリケーションの自動デプロイ
> 自動デプロイメントは、評価またはテストのために、スタンドアロン サーバ (管理サーバ) に
> アプリケーションを迅速にデプロイするための手段です。この方法は、
> 単一サーバの開発環境でのみ使用することをお勧めします。

> 自動デプロイメントは、開発環境において単一サーバの対象で使用することを想定されています。
> Administration Console など、他のツールを使用して自動デプロイ済みの展開されたアプリケーションに
> 対象を追加した場合、アプリケーションを再デプロイしても新しい対象サーバに変更は伝わりません。
> 以下の節では、開発環境で自動デプロイメントを使用する方法について説明します。

ちょっと考えればわかるじゃん。オートデプロイのために、
本来あるべきソフトウェアの設計を歪めるなんてありえないだろ?
↓これのこと

>>5
> staticは極力使わないようにしている。
> これを言うと知らない人は噛みついてくるかもしれないが。
> staticな(クラス,変数,メソッド)はtomcatアプリケーションのオートデプロイ時に深刻な問題が発生する。

どっちが大事なんだよ?

59 :デフォルトの名無しさん:2013/11/05(火) 22:37:23.32
>>56
最適化される
今はrvalue-refあるからいらんけど

60 :デフォルトの名無しさん:2013/11/05(火) 22:40:08.20
>>59
最適化ってどんな?

61 :デフォルトの名無しさん:2013/11/05(火) 22:45:57.37
>>58
言ってる意味がよくわからんな
最終的にAPIをstaticにしなくともstaticなんて極力使わないよ
インスタンスクラスにstaticをかぶせるのは容易だけど逆はできないもの

62 :デフォルトの名無しさん:2013/11/05(火) 22:49:00.83
>>58
本来あるべき姿という考えなら
staticは本来極力使うべきではない。

63 :デフォルトの名無しさん:2013/11/05(火) 22:51:45.82
>>60
const使ってるとコンパイラが(中で)定数扱いにしやすい
あと(ライフサイクルが短くなって)死にやすい

64 :デフォルトの名無しさん:2013/11/05(火) 22:52:50.38
>>61
> 言ってる意味がよくわからんな
オラクルにでも聞いてください。
オートデプロイは開発環境用につくられてるって書いてあるんだから。

っていうか、実際にstatic使ったら問題が起きるんだろ?
それがオートデプロイを実運用で使うべきではない理由の一つじゃん。

> staticは本来極力使うべきではない。

なんでだよw

65 :デフォルトの名無しさん:2013/11/05(火) 22:53:57.91
>>61
訂正
☓ APIをstaticにしなくとも
○ APIをstaticにするにしても

66 :デフォルトの名無しさん:2013/11/05(火) 22:55:23.04
もはや、”センス”って言っていいのかもしれんな。

オートデプロイを使って開発している時に、
オートデプロイができない場合がちょくちょくあるのは
わかりきってるじゃん。

その時点で実運用で使おうなんて思わないよ普通。
オートデプロイの事を考えて開発するなんて本末転倒。

67 :デフォルトの名無しさん:2013/11/05(火) 22:55:45.73
>>64
たいていのやつはstaticをグローバル変数みたいな使い方しているだろ。
グローバル変数を排除しスコープの局所化でリソースを有効に使うべきだから。

68 :デフォルトの名無しさん:2013/11/05(火) 22:56:01.12
すべてstaticにするべき。

69 :デフォルトの名無しさん:2013/11/05(火) 22:56:35.34
>>67
正しいstaticの使い方をしてください。

70 :デフォルトの名無しさん:2013/11/05(火) 22:57:48.11
C/C++でグローバル変数を使いまくってウンココード書いているようなやつがstatic
信者だからだよ。

71 :デフォルトの名無しさん:2013/11/05(火) 22:58:53.81
>>64
なんでだよってMockオブジェクトとか作れなくなるだろ
こんな簡単な事も理解できない奴が
なんでオートデプロイなんて使ってるんだ?

72 :デフォルトの名無しさん:2013/11/05(火) 22:59:31.36
staticはインスタンスが無くても呼び出せる。
だからすべてstaticにするべき。

73 :デフォルトの名無しさん:2013/11/05(火) 23:02:08.52
小規模開発でオートデプロイ
これなら全部staticで問題ない

74 :デフォルトの名無しさん:2013/11/05(火) 23:22:56.75
例えば内部クラスは必要が無い限りstaticにすべき。
ここでも非static信者はstaticを避けるの?

75 :デフォルトの名無しさん:2013/11/05(火) 23:26:12.93
>>74
避ける。

76 :デフォルトの名無しさん:2013/11/05(火) 23:26:20.88
オートデプロイもクラスのreloadableも残念ながら現状あまりあてにならない。

77 :デフォルトの名無しさん:2013/11/05(火) 23:26:16.36
>>74
それ、もしよければ理由を教えて欲しい >>9 もそうしてるね

78 :デフォルトの名無しさん:2013/11/05(火) 23:28:26.18
staticこそが栄光であり神の教えでもあるから
Javaに幸あれ

79 :デフォルトの名無しさん:2013/11/05(火) 23:28:54.31
親オブジェクトへの参照を持つから。

80 :デフォルトの名無しさん:2013/11/05(火) 23:36:18.69
宇宙空間ならstaticじゃなくても良い可能性がある

81 :デフォルトの名無しさん:2013/11/05(火) 23:57:35.13
>>79
ごめんここまで書いてわからなくなったhttp://ideone.com/dOd99N
インナークラスにどう追加したら「親オブジェクト」(????)の参照を拾えるの?

82 :デフォルトの名無しさん:2013/11/06(水) 00:13:02.17
>>80
地球では第1コンパイル以前の処理をstaticとしていますが、
宇宙には第2コンパイルも普通に使われ
第Nコンパイルに至ってはインタプリタと同等です。
どういうことかというとstaticはありません☆

83 :デフォルトの名無しさん:2013/11/06(水) 01:18:29.47
>>81
staticでない内部クラスからは「親オブジェクト」のフィールドやメソッドに普通に
アクセスできる。この場合内部クラスでthis.mとかやれば自分自身が返る。
参照がほしければ親オブジェクトのクラス名.this。この場合はC.this。

84 :デフォルトの名無しさん:2013/11/06(水) 06:46:38.63
言語基礎レベルも知らずに煽ってたのか
Qzが来ると一気に程度が下がるな

85 :デフォルトの名無しさん:2013/11/06(水) 06:48:52.39
無用な非staticの内部クラスを避けるとか常識だと思っていたが。

86 :デフォルトの名無しさん:2013/11/06(水) 06:56:45.59
ただ名前空間っぽく使いたいだけならstatic
親オブジェクトの子要素みたいな感じのクラスが作りたいなら非staticを使う必要が出てくるかもしれない
単純に用途が違う

87 :デフォルトの名無しさん:2013/11/06(水) 07:18:04.71
>>85
メンバクラスを使うとメモリリークするって話を聞いたことがある。あれってマジなのかね。

88 :デフォルトの名無しさん:2013/11/06(水) 07:18:44.39
>>85
メンバクラスを使うとメモリリクするって話を聞いたことがある。あれってマジなのかね。
イベントリスナ実装できなくね?

89 :デフォルトの名無しさん:2013/11/06(水) 07:20:54.12
きゃー2つ投稿してしまったわどうしましょう・・・まあいいや

90 :デフォルトの名無しさん:2013/11/06(水) 07:45:51.86
>>88
マジ。匿名クラス等として定義されたリスナーへの参照が何かに捕まれている限り、
イベントの受け手である親オブジェクトもガベージコレクトされない。
なぜなら非staticな内部クラスや匿名クラスのオブジェクトは親オブジェクトへの
暗黙の参照を持つから。

ただ不要になったリスナを適切に解放しないとメモリリークを起こすのは他の言語
でも似たり寄ったりだとは思う。

91 :デフォルトの名無しさん:2013/11/06(水) 08:33:36.85

そんなのメモリリークじゃねーだろ

92 :デフォルトの名無しさん:2013/11/06(水) 09:12:13.93
>>85
常識だよ。
同じキーワードってだけで混同させて揚足取ってる奴がいるだけ。

93 :デフォルトの名無しさん:2013/11/06(水) 09:14:19.98
Mathクラスのabs関数みたいなのも
staticにするなというのかね?

システムの構造を司ってるものはstaticを使わない方がいいが、
関数ライブラリ的なものはstaticを使った方がいい。

staticは状態を持たないからテストもしやすい。

テストは必ずmockでやるべきということでもない。
モジュールの性質によって適切なテスト方法は違う。

なんでもstaticを使うなというのは、
なんでもstaticを使えと言ってるstaticおじさんと
やってることは変わらんよ。

94 :デフォルトの名無しさん:2013/11/06(水) 09:14:24.21
いや、意味的にもstaticだろ

95 :デフォルトの名無しさん:2013/11/06(水) 09:15:33.93
>>93
absは整数クラスのメンバ関数でいいだろ。staticでないほうが自然。
Javaの言語仕様がタコなせいでstaticにしているだけ。

96 :デフォルトの名無しさん:2013/11/06(水) 10:28:28.51
>>93
>なんでもstaticを使うなというのは、
>なんでもstaticを使えと言ってるstaticおじさんと
>やってることは変わらんよ。
やってることが変わらんて、言ってる中身も理由も全然違うだろ。
お前さん、ひょっとしてアホなのか?

97 :デフォルトの名無しさん:2013/11/06(水) 10:57:37.00
public static final class Neko {
public static final String nyan() {
return "にゃん"
}

98 :デフォルトの名無しさん:2013/11/06(水) 11:00:38.04
>>93
>staticは状態を持たないからテストもしやすい。
statefulかどうかに、staticかどうかは全然関係ないね。
そもそも、static領域にインスタンス置くのじゃダメなわけ?

メソッドをstaticにすると、
継承もインターフェース使っての置き換えもできない。

元のクラスそのままで、実装変更したければ、
使うメソッドを改善するかに関わらず、全部staticで実装して、
しかも参照元では名前もパッケージも全て変更することになる。

実際、JavaのMathの実装なんて遅いわけだし、
パフォーマンスが足りなくなる場合なんて十分ありうるよ。

それでもIDEがあるから簡単だ!って言うなら止めないが・・。

99 :デフォルトの名無しさん:2013/11/06(水) 15:58:09.89
そもそもはTomcatでオートデプロイが云々なのでstaticを避けるという話。
それがそんなアホいね〜よと叩かれ、内部クラスもstaticは避けるのかと話を振ってみれば
避けるとかなぜ避けるのか教えてくれと言い出す有様。
巡り巡ってようやく実装の差し替えにくさにたどり着いた訳だが、その前にまずこのスレに
非static信者が何人張り付いているのかはっきりしてくれない?

staticなメソッドや定数の実装の差し替えがしにくいのは事実。
他方で呼び出しの手軽さやコストの小ささも事実。なのでstaticなこれらは実装の差し替え
が概ね不要だったり実装そのものを動的に取得するために使う。メリットとデメリットの
程度問題であることはどの技術問題とも共通して全く変わらん。

Mathが提供するstaticメソッドの差し替えがし難いのもしたくなることがあるかもしれない
のも事実かも知れないが、頻度としてどの程度さ?

100 ::2013/11/06(水) 16:24:44.95
人数を数えるための投票システムでも作ってくれ。2chでそれは質問として成立しない。

101 :デフォルトの名無しさん:2013/11/06(水) 16:30:19.66
>>95
必要となる数学関数は用途によって範囲が異なるわけでどこまでをクラスの標準メンバに
するかユーティリティクラスに追い出すかは利用方法を考慮したさじ加減の問題。
absをメンバにしたら次はceilやroundはどうするという話になる。

102 :デフォルトの名無しさん:2013/11/06(水) 16:39:30.44
もうクラスいらないんじゃね?

103 :デフォルトの名無しさん:2013/11/06(水) 16:40:10.46
>>100
皮肉だよ。
そもそも意味不明な>>3のstatic書き換えに対してTomcatを持ち出して奇妙なstatic否定を
持ち出した>>5が事の発端なのだからそろそろ責任をもって議論を収拾してほしい。

104 :デフォルトの名無しさん:2013/11/06(水) 16:44:46.64
>>101
ceilもroundもメンバで構わんだろ

105 :デフォルトの名無しさん:2013/11/06(水) 16:53:31.84
>>104
すると今度は三角関数や対数はどうなるという話になって、結局標準Mathが提供する
関数すべてについてどうするという議論まで続く。

106 :5:2013/11/06(水) 16:55:54.42
収拾?釣りでしたwwwwwwって言えばいいのか?
いいえ私は反static同盟強硬派であります。

107 :デフォルトの名無しさん:2013/11/06(水) 17:05:48.54
>>105
別にそれでいいんじゃない?何か議論されちゃ困ることあんの?

108 :デフォルトの名無しさん:2013/11/06(水) 17:16:51.50
>>107
別に困らんけど数学関数が山盛りのAPIが本当に見通しが良くて使いやすいかは議論の
必要があるだろうね。
数学関数などを別途Math等々に切り出している言語はJavaに限らんところから見ても、
データクラスの標準メンバにこれらの関数を入れすぎても使い勝手は良くないという
認識はそう珍しくないということじゃないのかな。これは感想。

109 :5:2013/11/06(水) 17:26:56.65
通常アプリケーションではstaticを良く使う、具体的には定数やシングルトン
だがtomcatアプリケーションからはほぼ全てのstaticを除外する必要があった。
よく問題が発生したのはstatic Pattern p=Pattern.compile("正規文法",Pattern.DOT_ALL);

110 :5:2013/11/06(水) 17:33:44.51
失礼DOTALL

111 :デフォルトの名無しさん:2013/11/06(水) 17:40:27.52
autoDeployの話なのかクラスのreloadableの話なのかはっきりしてほしい。
autoDeployでそれが問題になるのはなんか変。
reloadableであれば問題になるケースはあるけどそもそも単なる開発時の便利機能で
static云々以外にも問題があって当てにならん。運用時も普通切る。

112 :5:2013/11/06(水) 17:47:02.01
reloadableにしてクラスの一部を更新した場合に起こる問題ではなく
warファイルを更新したときに起こるautodeployの問題。

113 :デフォルトの名無しさん:2013/11/06(水) 17:58:01.97
>>109
問題って具体的にはどんな現象?

114 :5:2013/11/06(水) 18:01:23.99
>>113
デプロイ前の値が残っている。
正規表現を書き変える事が多いので発生頻度が低くなかった。

115 :デフォルトの名無しさん:2013/11/06(水) 18:10:40.53
>>114
それって定数じゃないっすか?
クラスやメソッドで問題になることあった?

116 :デフォルトの名無しさん:2013/11/06(水) 18:16:11.50
>>115
クラスではNoClassDefFoundError、メソッドでもエラーが出るので致命的ではない。

117 :デフォルトの名無しさん:2013/11/06(水) 18:24:08.99
クラスのエラーはこれに限らず、ClassNotFoundExceptionやクラスローダからみつかりませんという例外がデプロイ時に出たと記憶している。

118 :デフォルトの名無しさん:2013/11/06(水) 18:47:22.54
JavaもWEBプログラミング板に行ったほうがいいな。

119 :デフォルトの名無しさん:2013/11/06(水) 18:57:10.86
>>103
>>98だけど、俺は>>3には反対だから。

ネストクラスへのstatic修飾は、
メンバの継承やインターフェイスの実装もできる。
問題にしてるのは、クラスをインスタンスとして扱い、
かつ拡張性もない、OOなモジュール性を壊す方向のstatic。

Mathについても、それを踏まえた上の反論であって、
変更を余儀なくされた時は、そうなるよって言ってるだけ。

120 :デフォルトの名無しさん:2013/11/06(水) 19:06:27.74
ご飯食べたら意見が変わったのか。

121 :デフォルトの名無しさん:2013/11/06(水) 20:06:21.75
>>120
変わってないよ。
変な勘ぐりしてかき回すなよ。

122 :デフォルトの名無しさん:2013/11/06(水) 20:16:05.02
んじゃあさ、どんなMath APIがベターなの? static使わずに。

だいたい>>3に関してもstaticとはいえprivateじゃん。
目頭立ててツッコむところじゃないよ。

123 :デフォルトの名無しさん:2013/11/06(水) 21:52:32.72
自然な設計で考えて完全にstaticはダメって言ってる人いるの?
いないよね?

つまり自然な設計で考えてstatic使うってことだよね。

その自然な設計をオートデプロイのために
歪めるのは間違い。

ここまではいいよね?

あとは、オートデプロイは完璧じゃないんだから
実運用で使うべきではないってだけでしょ?

なんの迷いもなく、この結論に到達すると思うけど?

124 :デフォルトの名無しさん:2013/11/06(水) 23:06:16.42
Javaがウンコの上にtomcatもウンコだから
auto deployが使い物にならないってことか
ゴミ言語は大変だな

125 :デフォルトの名無しさん:2013/11/07(木) 00:52:41.02
tomcatはウンコ
というかJava標準のクラスローダはウンコ

126 :デフォルトの名無しさん:2013/11/07(木) 01:14:10.39
>>123
逆に聞きたいんだけど、自然な設計って何?
staticだとどういう利点があるの?

127 :デフォルトの名無しさん:2013/11/07(木) 01:16:42.03
>>126はクラスメソッドの話

128 :デフォルトの名無しさん:2013/11/07(木) 01:41:52.64
>>126
クラス(正確にはインスタンス)というのはデータとメソッドを塊にしたもの。

インスタンスメソッドというのは、インスタンスの内容を変更するもの。
データが主であり、それを変更するためにメソッドを用意する。
インスタンスの内容を変更しないのであれば、
それはインスタンスメソッドにする意味が無い。

それに対してクラスメソッド(static)というのは、インスタンスが無いから当然だが、
インスタンスのデータを変更しないもの。これは処理が主である。
内部データというものは存在せずに、引数に対して処理を行う。

インスタンスメソッドの場合、インスタンスの内容を変更するが
それと共にインスタンスの内容を参照することも多い。
つまり、同じメソッドを同じ引数で呼んだとしても同じ結果になるとは限らない。

クラスメソッドの場合、内部データが無いため、同じ引数であれば同じ結果にになる。
グローバル変数を参照すれば同じなるとは限らないが、
そもそもグローバル変数は使わないので、それは考える必要がないこと。

例外はいくつかあるが、基本的な違いはこれ。
この違いはテストのしやすさに関係してくる。

129 :デフォルトの名無しさん:2013/11/07(木) 01:45:10.04
インスタンスメソッドはインスタンスを変更するのが
目的であり、それはつまり副作用を目的としている。

それに対してクラスメソッドはインスタンスが存在しないから
副作用がない(とは限らないが、なるべく副作用がないように作るべき)

副作用がない方がテストが簡単なのは言うまでもない。

130 :デフォルトの名無しさん:2013/11/07(木) 01:58:33.65
インスタンスメソッドってオリジナル造語?
インスタンスの意味わかってる?

131 :デフォルトの名無しさん:2013/11/07(木) 02:02:26.39
まずググればぁ?

https://www.google.co.jp/search?q=インスタンスメソッド

132 :デフォルトの名無しさん:2013/11/07(木) 02:03:53.43
これでインスタンスメソッドという用語を知らない
無知な人間がレスしているという
構図が明らかになりましたね。

133 :デフォルトの名無しさん:2013/11/07(木) 02:08:42.39
>>132もうレスしないからその構図はない。

134 :デフォルトの名無しさん:2013/11/07(木) 02:33:46.58
スタティックもインスタンスメソッドもいらん
柔軟にオブジェクトを作れるJavaScriptを見習え

135 :デフォルトの名無しさん:2013/11/07(木) 04:22:53.89
スロットもいらん

136 :デフォルトの名無しさん:2013/11/07(木) 05:32:21.84
>>129
一応反論するけどね、インスタンスメソッドもstatelessにできるし、
標準のimmutableなクラスは基本的にそうなってるよ。

逆にsingletonパタンはstatefulでしょ。

もう一度言うけど、statefulかどうかstaticかどうかは全然関係ないんだ。
実装の問題。だからテストのしやすさも一緒。
それを踏まえてstaticにする利点を教えてくれって言ってる。

137 :136:2013/11/07(木) 05:43:45.03
>>136
すまん、immutableオブジェクト=statelessではない。
この補足は完全に間違い。

インスタンスメソッドでstatelessな実装ができると言いたかった。
こっちが先にメソッドにだけ論点を当てたのに、寝ぼけてたようだ。

138 :デフォルトの名無しさん:2013/11/07(木) 06:57:59.69
テストの点でstaticメソッドにメリットがあるかというとそれは見当違いだと思う。
staticメソッドの方がテストしやすいとか言っている人はstaticメソッドそのもの
テストしやすさとstaticメソッドに依存した成果物のテストしやすさを混同している
と思うぞ。
仮に前者がテストしやすかったとしても実用上は後者が面倒になっては意味不明。

で、経験則としては成果物がstaticなファクトリメソッド等々に依存すると実装を
モック等に差し替えにくくなって、むしろテストしにくくなる。
モンキーパッチを当てやすい動的言語に対してJavaの場合、staticメソッドの類い
の実装差し替えをやろうとすると大抵はバイトコード書き換えの出番になる。面倒。

例えば人気のあるモックツールであるMockitoなんかは端からDI推奨なんでstatic
メソッドへの対応は無しと割り切っているね。

ただそんなMockitoもモックや振る舞いを定義するメソッドは一連のstaticメソッド
として提供しているんだよね。
Mockitoのユーザは例えばMockitoの実装を差し替えてテストケース自体をテストする
ことなんてまず無いだろうから扱いやすさを優先してstaticにしても普通は問題ない。

Mathについても同様。Mathを使うたびに、

Math m = Math.createFactory(conf).getInstance(); m.cos(m.getPI() * 0.25);

とファクトリやインスタンスを引っ張ってくるとか、

<bean id="myBean" class="foo.baa.MyClass">
<property name="mathInstance">
<bean ...

とかDI定義書くの普通に嫌でしょw

139 :デフォルトの名無しさん:2013/11/07(木) 18:54:01.00
むしろすべてstaticにするべき。

140 :デフォルトの名無しさん:2013/11/07(木) 22:36:38.14
やめれ

141 :デフォルトの名無しさん:2013/11/08(金) 00:29:08.60
Mathは数学の関数群なんだから本来はグローバルにぶちまけるのが正しい
それができない言語はゴミ

142 :デフォルトの名無しさん:2013/11/08(金) 00:57:10.53
Javaって純粋なオブジェクト指向突き進んでる感じだから静的メソッドがあること知らなかった

143 :デフォルトの名無しさん:2013/11/08(金) 01:34:43.34
>>141
Mathのパフォーマンス不足も十分あり得るらしいのでそれでは困るらしい。>98的には。

144 :デフォルトの名無しさん:2013/11/08(金) 01:50:46.92
>>141
import static

145 :デフォルトの名無しさん:2013/11/08(金) 05:55:14.47
import static aaa.bb.Ccc.*; はよくあるな。JUnit使うときとか。

146 :デフォルトの名無しさん:2013/11/08(金) 06:39:36.79
Mathは遅いとかJavaだとたまに聞くな
ベンチマークマニアか3Dかゲームかしらないけど

147 :デフォルトの名無しさん:2013/11/08(金) 07:21:38.08
大体の言語で標準関数はエラーチェックとか冗長なことをしてるもの
もっと早い方法は存在する
エンジンの内部実装関数を呼ぶのが一番簡単だが

148 :デフォルトの名無しさん:2013/11/08(金) 07:51:50.33
JavaのMathなんて基本的な関数しか提供していないのに遅いとかのたまったところで
差し替える価値のある他の実装が存在するのかね。

149 :デフォルトの名無しさん:2013/11/08(金) 09:04:52.22
クラスは常に差し替えられないといけない
という考えも間違ってる。

差し替えられないといけないのは
単体でテストする意味が無いような場合のみ

150 :デフォルトの名無しさん:2013/11/08(金) 13:36:54.47
仮に多少遅くても原理的に可能性があるのなら
自分で頑張るよりもネイティブの関数使って将来性に期待するのも上品

151 :デフォルトの名無しさん:2013/11/08(金) 19:35:57.66
ゴルゴフォーティーン始まるらしいね。

152 :デフォルトの名無しさん:2013/11/08(金) 19:47:18.66
JavaScriptだとMath使ったほうが速いとかわけわからん事象が発生するけどな。
それはそれで実行速度がまるで読めなくて困るんだけどな。
number crunching的にゃ、C++のようにコンパイル時にピシッとインライン化して最適化して
predictableな動作してくれるのが結局正義でしょ。

153 :デフォルトの名無しさん:2013/11/08(金) 19:52:08.63
正義を実行できる言語はJavascriptだけ。

154 :デフォルトの名無しさん:2013/11/08(金) 20:09:32.19
え、Math使うほうが遅いんなら標準のMathがある意味0じゃね

155 :デフォルトの名無しさん:2013/11/08(金) 20:17:44.70
Mathはほぼネイティブで実装されててるから早くて当たり前
あとこれからのMathは最適化の重要な情報の付加も期待されている

var floats = new Float32Array(calc())

floats[0] = floats[1] + floats[2] //最適化容易

floats[0] = floats[1] + floats[2] + 1 //最適化困難

floats[0] = Math.fround(floats[1] + floats[2]) + 1 //最適化容易

156 :デフォルトの名無しさん:2013/11/08(金) 21:48:03.21
>>152
Math使わないで何をどうやる話?

157 :デフォルトの名無しさん:2013/11/08(金) 21:56:48.41
JSはCの二倍速いので、JSで書き直したほうが高速化するというお話。

158 :デフォルトの名無しさん:2013/11/08(金) 21:59:44.06
いやいや100倍な

159 :デフォルトの名無しさん:2013/11/08(金) 22:10:48.65
うそつけ!100倍も速いわけない!
せいぜい3倍程度だろ。

160 :デフォルトの名無しさん:2013/11/08(金) 23:01:06.08
100倍とまではいかないがC++の20倍高速だね
http://nothingcosmos.blog52.fc2.com/blog-entry-155.html

161 :デフォルトの名無しさん:2013/11/08(金) 23:24:44.74
特定のコードに限って20倍って話ならどうでもいいよ。
アプリ全体で考えるのが普通だからさ。

162 :デフォルトの名無しさん:2013/11/08(金) 23:28:25.97
このネタ飽きた。

163 :デフォルトの名無しさん:2013/11/08(金) 23:38:21.67
>>161
お前の基準なんか誰も興味ないからわざわざここに書かないでくれ
スレが汚れる

164 :デフォルトの名無しさん:2013/11/09(土) 00:28:22.15
はいはい今JSerは場違いだから。
大規模計算の分野で広くバリバリ使われるようになってから顔を出そうね。

165 :デフォルトの名無しさん:2013/11/09(土) 03:13:18.77
このスレではJavaScriptの話はすべてネタと化す

166 :デフォルトの名無しさん:2013/11/09(土) 04:11:52.17
未来の話か実績の伴わない話ばかりだからな > JS

167 :デフォルトの名無しさん:2013/11/09(土) 05:05:20.13
>>149
このレス一つで本来のOOPをまるで理解していないのがわかる

168 :デフォルトの名無しさん:2013/11/09(土) 06:10:28.31
どうせJS以外はことごとく本来じゃないという方向に持って行きたいだけだろうさ。

169 :デフォルトの名無しさん:2013/11/09(土) 11:31:53.25
そもそもスレタイのテーマが一切話し合われないネタスレなんだから
ネタは多ければ多いほど馬鹿騒ぎできていいじゃない

170 :デフォルトの名無しさん:2013/11/09(土) 17:16:44.32
JSは正義なんで。
正義に文句があるということは、お前が悪ってこと。

171 :デフォルトの名無しさん:2013/11/09(土) 17:23:35.58
>>170
JavaScriptってJavaScriptで実装されてんのかな?
RhinoはJavaだけど、Node.jsはNode.jsで実装されてんの?
正義ならそうするの?

172 :デフォルトの名無しさん:2013/11/09(土) 17:27:51.27
RubyってRubyで実装さ(ry

173 :デフォルトの名無しさん:2013/11/09(土) 17:40:00.17
>>172
Rubyもセルホスティングなんだっけか?Pythonは聞いたことあるが。

174 :デフォルトの名無しさん:2013/11/09(土) 17:46:56.08
所で、実装言語をその言語でやることで
何かいいことあるの?

175 :デフォルトの名無しさん:2013/11/09(土) 17:50:06.38
あ、ごめん。質問を変えるわ。
なにか良いことあるの?ではなく
なにか良いことあったの?にする。

176 :デフォルトの名無しさん:2013/11/09(土) 17:59:25.24
ネットスケープはCSSの解釈をJSでやっていた。

当時の技術でスタイルシートの解釈は非常に難しく、IEは凝ったCSSサイトを
正常に表示できず、ブラウザごと落ちてしまうことが多かった。
時にはOSごと落ちてしまうことすらあった。

しかしながら、ネットスケープはJSのパワーを生かし見事なCSS解釈をやってのけた。
CSSを避けながら閲覧しなければならないIEを後目に着々とシェアを伸ばしたのである。

177 :デフォルトの名無しさん:2013/11/09(土) 18:14:16.33
そんなうそで騙されるぐらい過去の話のなのかw

ネットスケープはひどかったな。CSSを有効にすると落ちるから
無効にするのが常識だった。

http://softark.net/articles/m-0002.html

Netscape の惨状
びっくりした。Netscape は、いったいいつの間にこんな惨状に陥ってしまったのだろう。

ひどいもんだ。スタイル・シートを使っているページは、これでは見る気がしないだろう。
画像と文字が重なるわ、画像同士が重なるわ、テーブルの罫線が見えないわ、
センタリングした筈の区画が左端に寄るわ、もう、ぐちゃぐちゃである。

いや、ぐちゃぐちゃと言ったが、画像も入れず、TABLE も入れず、float も使わなければ、
特に大きな問題は無いようだ。つまり、こういう文章だけのページは、ほぼ問題ない。
IE で見るより、少々しょぼいと言うか、不細工な感じがするが、多分、気のせいだろう。

しかし、画像を入れると、途端におかしくなる。たとえば、楽しい日記の2月14日。たとえば、
裏夜食日記の2月12日。また、たとえば、偽偽夜食日記の2月19日。float させていなくても、
おかしくなる。画像が文字を隠したり、画像同士が重なったり、要するに、絵日記は全滅の態である。

line-heightがあるとIMGもそれだけしか改行されないのだと風の噂【謎】に聞く。
やってみると、その通りだった。で、スタイル・シートを少々修正。しかし、依然として
float させるとうまく行かない。二行目からは回り込むが、一行目が必ず画像の下に隠れてしまう。
しかも、外部スタイル・シートでなく HTML 内で float を指定すると、これはこれで挙動が異なって、
何かヘン。では、というので、非推奨の align 属性で回り込みを指定すると、画像の下端を超えても文字列のコラム幅が復元しない
(回り込みが解除されない)。どうなってんのか、ワケワカメだ。いや、バグリまくりだ。もう、わしゃ、知らん。

Master Compatibility Chart というので見ても、Netscape の対応は Microsoft に比べて随分遅れているようだ。
また、float や clear は特に実装が難しい所なので、ブラウザによらずバグが多いようだ。
ただ、IE 5 はかなり良くなった、とも書かれている。

178 :デフォルトの名無しさん:2013/11/09(土) 18:15:37.34
http://www.wdic.org/w/TECH/Netscape%20Navigator

バグ
Netscape Navigatorは、数え切れないほどの意味不明な
バグを抱えるソフトウェアであった。

まだNetscape Navigator在りし頃、当時の厨房がInternet Explorerを
叩くのにセキュリティなどのソフトウェア面のバグをよく指摘していたが、
自分の用いているNetscape Navigatorについては見てみないふりをしていたらしい。

Netscape Communicator 4頃のバグにはかなり酷いものが存在し、
例えばスタイルシート(CSS)におけるline-heightのバグでレイアウトが異常になる、
日本語などのマルチバイト文字のフォント指定をするとCSSの指定自体が無効となる、
といったものがあった。必要最低限のレベルでさえ使い物にならない状態であったため、
ここからNetscapeは徹底的に叩かれることになる。

179 :デフォルトの名無しさん:2013/11/09(土) 18:16:54.47
http://www.marguerite.jp/Nihongo/WWW/Introduction/Note-HowToCSS.html

ネットスケープ 4.xのCSS処理は非常に問題が多いです。
この問題点を挙げるとそれだけでサイトが一つ作れてしまうほどです。
ここでは、ネットスケープ 4.xで問題が起こり難くする方法について解説しましょう。

ネットスケープ 4.xに関しては考慮しないと言うのが一番簡単な方法ですが、
だからと言ってネットスケープ 4.xで問題のあるスタイルシートをそのまま取扱わせるのは好ましくはありません。
最悪の場合、ネットスケープ 4.xがクラッシュする事もあるからです。

そこで、ネットスケープ 4.xではCSSを取扱わせないのが一番無難な方法です。
スタイル定義ファイルをネットスケープ 4.xで当てないためには、そのスタイル定義ファイルに
関する<link>要素にscreen値以外の値を入れたmedia属性を当てるだけで実現します。
具体的には以下の通りになります。

180 :デフォルトの名無しさん:2013/11/09(土) 18:20:19.37
netscapeの古いバージョンはここで落とせるよ。
http://www.oldapps.com/netscape.php

4とかのバージョンは本当にひどくて
多分Googleなんか落ちると思うよ。
落ちなくても10ページも見れないんじゃないかな?
見れないとか崩れるとかじゃない。落ちるんだよ。

ぐれぐれも、仮想マシンに入れること

181 :デフォルトの名無しさん:2013/11/09(土) 18:22:50.60
ネスケが落ちるのはWindowsが不安定だからです。
Linuxなら落ちません。

182 :デフォルトの名無しさん:2013/11/09(土) 18:26:38.11
NetscapeはLinuxで使うとOSごとフリーズさせるからひどかったよね。

http://his.luky.org/ML/linux-users.4/msg01985.html
Slackware3.5+PJE0.1.5でNetscape Communicatorを使ってるときに
フリーズが頻発するため困ってます。パソコン自体が完全に固まって、
Telnetでほかのパソコンからのアクセスも受け付けなくなり、リセット
ボタンを押さざるを得なくなります。

183 :デフォルトの名無しさん:2013/11/09(土) 18:33:17.60
Netscapeは2000年ころまで使ってたけどそのご激重になってMozillaに乗り換えた記憶がある。

184 :デフォルトの名無しさん:2013/11/09(土) 18:38:16.94
>>182
あほ
ユーザプロセスで落ちるかヴォケ

185 :デフォルトの名無しさん:2013/11/09(土) 18:42:16.92
じゃあ、Linuxが悪いっていうのかよ!

186 :デフォルトの名無しさん:2013/11/09(土) 19:20:12.65
>>171
V8はエンジンの中ではJavaScriptの度合いがかなり多い方
複雑な部分、例えばDateとかはJSでよく書かれてる
もともとESの企画中の内部関数が結構抽象度高いので
JSで実装するのには向いてる

Node.jsももうかなりJS
Socket、Event、Bufferの3本柱はネイティブだけど
その周りの肉やら何やらはほぼ全部JS

>>176
JSのCSSパーサは今になってまた需要が出てきてる
https://github.com/NV/CSSOM

187 :デフォルトの名無しさん:2013/11/09(土) 19:27:53.54
>>184
普通に落とせるよw
べつに変なこと考えなくても、例えばリソースを完全に食いつぶすだけでもクラッシュするからね

188 :デフォルトの名無しさん:2013/11/09(土) 19:51:25.61
へー、ネスケはLinuxのリソースを完全に食い潰すバグがあったとでも言うのかなー?

世の中には本当に手に負えないバカがいるんだなw

189 :デフォルトの名無しさん:2013/11/09(土) 20:05:02.69
まあ、なんにせよ。ネスケ4の時代は暗黒で、
ゴミと言われて反論できないブラウザだったよな。

190 :デフォルトの名無しさん:2013/11/09(土) 20:10:45.36
かといってIEを持ち上げる気にもならんけどな

191 :デフォルトの名無しさん:2013/11/09(土) 20:20:42.92
それは今の話だろう?
IE以外のブラウザがまともになったのは
それから何年後だと思う?

192 :デフォルトの名無しさん:2013/11/09(土) 20:23:16.47
何年??
Web業界では週単位で事態が動くんだが
1年前なんてかなりの常識が通用しなくなる大昔だろ

193 :デフォルトの名無しさん:2013/11/09(土) 20:25:48.83
そう。それなのに、IE以外のブラウザが
まともになったのはそれから数年後。

週単位で自体が動く中、数年間も
他のブラウザは使い物にならなかったのだよ。

194 :デフォルトの名無しさん:2013/11/09(土) 20:27:03.74
Linuxは落ちません。
JSはCの二倍速い。

195 :デフォルトの名無しさん:2013/11/09(土) 20:29:36.47
>>193
昔のことなんてどうでもいいよ

>>194
キチガイ乙

196 :デフォルトの名無しさん:2013/11/09(土) 20:34:34.33
V8はほとんどJSで出来ているんですよ。
だからCの二倍速いんです。
Node.jsも大部分JSで書かれています。
CSSの解釈もJSがいいという人が増えています。

197 :デフォルトの名無しさん:2013/11/09(土) 20:42:06.34
V8は本当にネイティブとJSのバインディングが上手いからねえ
本当にうまい具合にできてると思う
まあ速さの秘訣はネイティブ側で泥臭くやってるからなんだけどね
泥臭いと言ってもちゃんと整理されてるし
毎日のように何処かがリファクタリングされてて本当に美しい
最近はパーサを一新してて注目に値するね

198 :デフォルトの名無しさん:2013/11/09(土) 20:43:50.91
JS信者ってアホgoogleあたりの手先か?

199 :デフォルトの名無しさん:2013/11/09(土) 20:44:19.65
>>187
OS とその食い潰すリソースってなに?

200 :デフォルトの名無しさん:2013/11/09(土) 20:47:41.53
>>195
まったくだよw
なんでネスケ4の話しだしたの?
ばかじゃね?w

201 :デフォルトの名無しさん:2013/11/09(土) 20:52:17.28
ネットスケープは素晴らしいブラウザでOSとすら言えるものだったが、
M$の陰謀で消された。
消費者は皆ネスケの復活を望んでいた。

202 :デフォルトの名無しさん:2013/11/09(土) 20:58:04.83
正直、ネスケ3はクソだったが、IEのほうがもっとひどかった。

203 :デフォルトの名無しさん:2013/11/09(土) 20:58:23.31
ないないw
ネスケのせいでCSSが使われなくなったと
言ってもいいぐらいだよ。

204 :デフォルトの名無しさん:2013/11/09(土) 20:59:28.29
ここおっさんだらけなんだなw

205 :デフォルトの名無しさん:2013/11/09(土) 20:59:29.83
どうやらIEバカの脳内ではCSSは普及していないらしいw

206 :デフォルトの名無しさん:2013/11/09(土) 21:09:42.89
IEのCSS解釈はCで書かれていたためバグが多かった。
一方、ネスケはJSで書かれていたので完璧だった。

検索で調べてもこれらの事実は出てこない。
なぜならM$が工作しているからだ。

当時をリアルに知っているものだけがネスケの素晴らしさを知っている。

207 :デフォルトの名無しさん:2013/11/09(土) 21:11:41.58
mshtml.dll

208 :デフォルトの名無しさん:2013/11/09(土) 21:13:12.37
>>206
つまり、お前は嘘言っているってことじゃねーかw
自分で、言ってどうするw

209 :デフォルトの名無しさん:2013/11/09(土) 21:15:29.45
>>208
それはどういう意味かな?

210 :デフォルトの名無しさん:2013/11/09(土) 21:35:45.88
JSがネイティブの2倍早いってのは誤訳が元ネタだよ。asm.js関係の和訳記事だね。
まあ、陰謀とか言いながら自分に都合のいい情報を鵜呑みにするのは格好悪いね。

211 :デフォルトの名無しさん:2013/11/09(土) 21:37:50.44
だから何?

212 :デフォルトの名無しさん:2013/11/09(土) 21:42:42.04
JSがCの二倍速いのは事実だよ。
信じたくない気持ちは理解できるけど、使ってみればすぐ気付くこと。
ベンチで圧倒的に速いのも当たり前のこと。
今は何でもJSで書き直すフェーズに来てて、そのうちOSやドライバもJSで
書き直される。
これはLinusも検討すると言ってるよね。

213 :デフォルトの名無しさん:2013/11/09(土) 21:46:25.73
だから、「二倍」という具体的な数字は誤訳記事が初出なの。主張を変えるのは悪いことではないの。

214 :デフォルトの名無しさん:2013/11/09(土) 21:48:13.70
実は3倍速いのだと言いたいのですね?

215 :デフォルトの名無しさん:2013/11/09(土) 21:56:06.08
ソース無いけど2倍はやいよ。
全部MSの陰謀だよ。

216 :デフォルトの名無しさん:2013/11/09(土) 22:16:13.98
JavascriptはLisp直系のアカデミックなハイエンド言語です。

217 :デフォルトの名無しさん:2013/11/09(土) 22:38:25.84
アカデミックでハイエンドって感じじゃないな
カッコ可愛い言語ってかんじかな

218 :デフォルトの名無しさん:2013/11/09(土) 23:12:29.52
k○atchさん何してはるんすか

219 :デフォルトの名無しさん:2013/11/09(土) 23:46:13.32
JSは愛されてるな

220 :デフォルトの名無しさん:2013/11/09(土) 23:54:02.54
ネタにね。

221 :デフォルトの名無しさん:2013/11/10(日) 00:32:12.89
また妄想にふけっちゃったのか

222 :デフォルトの名無しさん:2013/11/10(日) 05:52:47.49
JSの気持ちも考えろ!

223 :デフォルトの名無しさん:2013/11/10(日) 06:58:46.17
ダメな子ほどかわいいとかいうやつか。

224 :デフォルトの名無しさん:2013/11/10(日) 09:31:39.84
背伸びしたい年頃の気持ちも考えろということだろ

225 :デフォルトの名無しさん:2013/11/10(日) 09:52:52.52
JavaScriptをコケにしたらなんかいいことあるの?
認めて受け入れようって気持ちがないと成長できないよ

226 :デフォルトの名無しさん:2013/11/10(日) 10:11:15.96
説教したいお年頃w

227 :デフォルトの名無しさん:2013/11/10(日) 10:36:06.09
今更だが>>128-129の狭苦しいOO観にはイラッとする

228 :デフォルトの名無しさん:2013/11/10(日) 10:45:47.53
>>227
どのへんが古臭いの?
クラスメソッドは副作用なきよう、というのは確かにちょっと、という感じだが

229 :デフォルトの名無しさん:2013/11/10(日) 10:48:00.35
説明文の文字数の割に内容が狭苦しいということじゃないかな?

230 :デフォルトの名無しさん:2013/11/10(日) 10:59:29.79
>>229
>狭苦しい
ここもう少し

231 :デフォルトの名無しさん:2013/11/10(日) 11:07:39.51
インスタンスメソッドがインスタンスの状態を変える場合は多いが
そんなの強制されてないし副作用が必ず発生するとは限らない。
その辺の認識からして狭いということだろう。

232 :デフォルトの名無しさん:2013/11/10(日) 11:09:44.28
>>231
多いと認めるんだろう?
ならお前は同じことを言っている。

233 :デフォルトの名無しさん:2013/11/10(日) 11:11:03.87
JavaScriptはJavaやC#にようやく追いついた程度
http://www.slideshare.net/dynamis/try-firefox-os/16
まだまだネイティブまでは遠い

234 :デフォルトの名無しさん:2013/11/10(日) 11:11:04.61
あとクラスメソッドは引数だけでなくstaticなクラス変数やstaticイニシャライザも関係している。
そこの認識も狭い。

235 :デフォルトの名無しさん:2013/11/10(日) 11:13:27.91
でも大筋ではあってるな。

236 :デフォルトの名無しさん:2013/11/10(日) 11:16:07.72
あとクラスメソッドとインスタンスメソッドなんて大真面目で長文書くほど大した概念ではないということ。

237 :デフォルトの名無しさん:2013/11/10(日) 11:16:30.62
asm.jsってGCすら無いのに
それでもCの2倍遅くて、
C#と同じくらいなんだね

238 :デフォルトの名無しさん:2013/11/10(日) 11:18:36.32
>>235
副作用のとらえかたが間違っている。

239 :デフォルトの名無しさん:2013/11/10(日) 11:19:18.31
大筋では合ってるだろう。

240 :デフォルトの名無しさん:2013/11/10(日) 11:19:57.93
副作用を持ち出した時点で大筋でも間違っている。

241 :デフォルトの名無しさん:2013/11/10(日) 11:21:12.23
asm.jsにもGCは効きます
その関数が終わるまで延期されるのと
生メモリを触ることでGCの影響を受けなくすることもできるというだけです

242 :デフォルトの名無しさん:2013/11/10(日) 11:24:29.56
>>240
間違ってるというのなら
間違っているという証明をした方がいいね。

243 :デフォルトの名無しさん:2013/11/10(日) 11:25:30.14
>>241
つまり、その関数がアプリ終了まで
ずっと動いていれば、GCの影響が
全くないってこと?

244 :デフォルトの名無しさん:2013/11/10(日) 11:25:43.38
意地を張るあまり収集つかなくなる奴って一番嫌いなんだよ。さよなら。

245 :デフォルトの名無しさん:2013/11/10(日) 11:28:16.12
>>237
次のページ見てもらえれば分かるけど
asm.jsそのものは数割遅い程度でNaClなんかといい勝負
でもasm.jsでは数値計算しか出来ないし
全部をasm.jsで書くのは不可能だからね
だから全体では概ね対応環境で2倍、
直接対応はしてないけどいろいろ頑張ってるChromeで3倍くらいになる

246 :デフォルトの名無しさん:2013/11/10(日) 11:28:52.69
なんでまたその話を蒸し返してるんだこいつ?
証明できないくせに蒸し返すとか
それ単に悔しかっただけだろw

247 :デフォルトの名無しさん:2013/11/10(日) 11:32:59.04
>>228
古臭い、ではなく、狭苦しい。
ほとんど全部だよ。

> インスタンスメソッドというのは、インスタンスの内容を変更するもの。
> データが主であり、それを変更するためにメソッドを用意する。
 この見識があまりに狭い。
 オブジェクトというのはある役割を果たすためのものだ。
 データが主?それって目的と手段がごっちゃになってる。

> インスタンスの内容を変更しないのであれば、それはインスタンスメソッドにする意味が無い。
> インスタンスメソッドはインスタンスを変更するのが目的であり、それはつまり副作用を目的としている。
 インスタンスの内容に「基づいて」役割を果たせばよいのであって、内容を変更する必要はない。
 >>128-129はオブジェクト自身に対するメソッド発行しか念頭にないんじゃないかと疑う。

248 :デフォルトの名無しさん:2013/11/10(日) 11:34:04.21
>>243
asm.jsで作った関数はJS層にエクスポートされてるネイティブ関数と同じように振る舞います
JS層からasmネイティブ関数を呼び、その返り値を受け取って
処理を続けるという形になるので、副作用の実質出来ないasm.jsの部分がずっと働くということはありません
また、GCが働かない範囲では数値や元々メモリを確保する役割のバッファへの書き込みしかしないので
いたずらにメモリを消費するということはありません

249 :デフォルトの名無しさん:2013/11/10(日) 11:38:37.21
オブジェクトって英語で
「物」って意味だけどね。
役割果たすための「物」
さて物ってなに?
物以外ってなに?

250 :デフォルトの名無しさん:2013/11/10(日) 11:39:43.12
メソッドというのは、物に対するメッセージ。
メッセージを物に対して送るとき、
反応するのは、送り先の物である。
これがオブジェクト指向の原則。

251 :デフォルトの名無しさん:2013/11/10(日) 11:41:04.98
オブジェクトは物以外に対象とか反論とか言う意味がなかったけ?
あとOOは対象指向と言うと思う。

252 :デフォルトの名無しさん:2013/11/10(日) 11:42:40.69
Smalltalkを勉強したら本来メソッドというのは
オブジェクトに対するッセージだってことがわかるよ。

なぜそのオブジェクトに対してメッセージを送るのか?
それはそのオブジェクトに送らなければいけない
理由があるから。

253 :デフォルトの名無しさん:2013/11/10(日) 11:45:36.39
メッセージがオブジェクトの内容を変化させないとしたら、
それはそのオブジェクトに対して
メッセージを送る必要がないということを意味する。

そういうメソッドは違うクラスにあったとしても
問題なく動くだろう。

その場合、クラスは単にメソッドの種類をグループ化する
名前空間として使われているだけにすぎない。
名前空間はクラスではない。

254 :デフォルトの名無しさん:2013/11/10(日) 11:48:34.10
メソッド内で既定値を外れる入力だと判断したらオブジェクトの内部状態を変化させないだろ?
だからそういう議論は必ずしも成り立たないんだよ。

255 :デフォルトの名無しさん:2013/11/10(日) 11:53:14.17
別に動作や意味は関係ないと思ってる
オブジェクトから関数が生えてるように見えたらメソッドだ

256 :デフォルトの名無しさん:2013/11/10(日) 11:53:37.45
>>253
何で変化する必要がある?
オブジェクトは自身の情報を持っている。
その情報に「基づいて」、そのオブジェクトが役割を果たす。

その情報はそのオブジェクトだけが持っているかもしれない。
その場合他のオブジェクトはその役割を担えない。
別に変化する必要はないよね。

257 :デフォルトの名無しさん:2013/11/10(日) 11:53:56.57
class A{
 static int a=0;
 static int min(int b){
  if(a<b){a=b;}
  return a;
}
}
じゃあめんどくさいけど反証しとく。
staticだからといって内部状態がないわけじゃない

258 :デフォルトの名無しさん:2013/11/10(日) 11:55:49.87
ちなみに>>257はminではなくmaxとすべきだった。

259 :デフォルトの名無しさん:2013/11/10(日) 12:07:19.86
>>253
そういうのが「狭い」っていうんだよ。

260 :デフォルトの名無しさん:2013/11/10(日) 12:08:22.47
オブジェクトにメッセージを送るというのが分からん
関数にこれが対象ですよとオブジェクトを送るんだと思うんだが

261 :デフォルトの名無しさん:2013/11/10(日) 12:13:39.08
メッセージというのは関数型言語でいうところの関数と何が違うんでしょうか?

262 :デフォルトの名無しさん:2013/11/10(日) 12:17:27.56
例えるならば、メッセージは愛、関数は力

263 :デフォルトの名無しさん:2013/11/10(日) 12:22:44.41
>>260
class Postman {
 void sendMail() {
 }
}

Postmanオブジェクトにメイルを送ってというメッセージを送るときは
次のようになる。

Postman p = new Postman();
p.sendMail();

メッセージを送ることそれすなわちメソッドを呼ぶことなり。

264 :デフォルトの名無しさん:2013/11/10(日) 12:25:09.82
>>252
歴史的に先行するものが「本来」だというのは、それこそ狭い見識ですね。

265 :デフォルトの名無しさん:2013/11/10(日) 12:26:39.64
>>263
それだと単なる見る立ち位置の問題じゃない
もっと深い話ないの?

266 :デフォルトの名無しさん:2013/11/10(日) 12:28:46.79
>>265
Σd(ゝ∀・) ないよ!

267 :デフォルトの名無しさん:2013/11/10(日) 12:29:26.40
>>262
なるほど
ラブリーフォースアローみたいなもんですか

268 :デフォルトの名無しさん:2013/11/10(日) 12:32:00.30
メッセージパッシングの場合メッセージとオブジェクトは互いに独立してるってだけ
どんなメッセージをどんなオブジェクトに送っても構わない
まあオブジェクトにレシーバーがなかったらエラーになるけど

269 :デフォルトの名無しさん:2013/11/10(日) 12:42:10.16
メソッドはオブジェクトが変化する必要はない。
getter/setterのgetterがそうだろ。

メソッドはオブジェクトを変化されるか、
もしくはオブジェクトの状態を取得するかのどちらか。

さすがにオブジェクトに無関係な処理は
つまり引数と戻り値が全てのメソッドは
メソッドにする意味は無いけどね。

270 :デフォルトの名無しさん:2013/11/10(日) 12:42:46.07
変数に型がないということの利点について考える - サンプルコードによるPerl入門
http://d.hatena.ne.jp/perlcodesample/20130227/1361928810

お前らこれについてはどう思ってるわけ?その通りだと思う?

271 :デフォルトの名無しさん:2013/11/10(日) 12:42:54.60
>>259
> そういうのが「狭い」っていうんだよ。

「狭い」というのなら、
お前の「広い」を言えよ。

272 :デフォルトの名無しさん:2013/11/10(日) 12:43:55.26
>>270

そこのブログに書いてある
反論のつもりだと思ってるよ。

273 :デフォルトの名無しさん:2013/11/10(日) 12:46:45.87
>>270
それよりmyってなんですか

274 :デフォルトの名無しさん:2013/11/10(日) 12:52:06.72
>>273
ローカル変数

275 :デフォルトの名無しさん:2013/11/10(日) 12:55:02.86
宣言文や代入文の先頭にキーワードがない文法に対して
気持ち悪いという感覚を持つべきだ

276 :デフォルトの名無しさん:2013/11/10(日) 12:59:32.15
>>268
>メッセージパッシングの場合メッセージとオブジェクトは互いに独立してるってだけ
メソッドとオブジェクトが独立してるのもあるぞ
プロトタイプベース言語とか
それと似てるってことか?

277 :デフォルトの名無しさん:2013/11/10(日) 13:00:58.01
宣言は宣言詞がいるけど代入には要らないのが普通の考えじゃないか??

278 :デフォルトの名無しさん:2013/11/10(日) 13:04:50.91
完全型推論ってどの辺りまで決め打つのが一般的なの?
数値型の種類とか、オブジェクトのクラスの種類まで決め打たれるの?

279 :デフォルトの名無しさん:2013/11/10(日) 13:08:26.89
>>270
型は「型にはめる」ことでやりやすくしようって試みだから
型にはめるのを良しとしなければその通り
それから、人間のためと同じかそれ以上にコンパイラのための試みだと思うから
そんなん気にしたくねーよって主張なら型がない方のメリットが上回ってくると思う
この辺は利便性が云々より環境と性格だと思う

280 :デフォルトの名無しさん:2013/11/10(日) 13:15:09.40
>>276
オブジェクトから独立したメソッドというのがよくわからないけど
プロトタイプベース言語そのものだったりそれに似た機構を持っていることが多いと思う

281 :デフォルトの名無しさん:2013/11/10(日) 13:15:31.06
>>269
> ソッドはオブジェクトを変化されるか、もしくはオブジェクトの状態を取得するかのどちらか。

オブジェクトの状態を参照して(利用して)何かするんであって、取得する必要は必ずしもない。
getterは本当に必要なのものだけに限定した方がいい。

282 :デフォルトの名無しさん:2013/11/10(日) 13:20:31.29
>>275
ハス公キモいよねぇ〜
letくらいつけろよ、バカ!

283 :デフォルトの名無しさん:2013/11/10(日) 13:23:56.10
>>281
なにいってんの?

オブジェクトの状態を変えないが、
メソッドである必要があるものを言っただけだろ。

284 :デフォルトの名無しさん:2013/11/10(日) 13:25:49.11
>>281
そうだね

285 :デフォルトの名無しさん:2013/11/10(日) 13:27:59.59
アクセサってメソッドなのか

286 :デフォルトの名無しさん:2013/11/10(日) 13:29:01.44
>>269
>引数と戻り値が全てのメソッドはメソッドにする意味は無いけどね。

こういうメソッドは意味無いこともない。
private int min(int a,int b){
 return a<b?a:b;
}

287 :デフォルトの名無しさん:2013/11/10(日) 13:31:02.25
経験が浅いから議論がスカスカなんだよ。って雑談にイチャモンつけてる俺の方がバカなのかもしれんね。

288 :デフォルトの名無しさん:2013/11/10(日) 13:31:40.48
>>282
代入がある劣った言語と一緒にされちゃ困る

289 :デフォルトの名無しさん:2013/11/10(日) 13:32:15.70
>>283

>>269であんたは
>メソッドはオブジェクトを変化されるか、「もしくは」オブジェクトの状態を取得するかのどちらか。

と言っているが、そのどちらでもない、つまりオブジェクトを変化させないしgetterでもない
メソッドもあると言っている。

それがオブジェクトの状態を参照して(利用して)何かするメソッドだということ。

290 :デフォルトの名無しさん:2013/11/10(日) 13:32:52.46
>>286
それは意味が無い。

まずスコープがprivateである。
これはユニットテストが出来ないことを意味する。

ユニットテストをすることを考えると、
publicにした方がいい。

publicにすることで見えてくるもの。
それはこのクラスにあるべき機能なのかということ。

明らかに特定のクラスに依存したコードでないのだから、
簡単に移動できることがわかる。
つまりそのコードはクラスとは無関係のコードということだ。

291 :デフォルトの名無しさん:2013/11/10(日) 13:33:12.25
スタティックどころか全部グローバル関数でもええんやで?

292 :デフォルトの名無しさん:2013/11/10(日) 13:33:24.94
>>286
> private int min(int a,int b){
>  return a<b?a:b;
> }

それはstaticで十分だということじゃね?

293 :デフォルトの名無しさん:2013/11/10(日) 13:34:13.95
>>289
うん、そして、引数と戻り値だけで完結するものは、
メソッドではないとも言ってる。

クラスは単に名前空間として利用しているだけ。

引数と戻り値だけで完結するものは
素晴らしいよね。

294 :デフォルトの名無しさん:2013/11/10(日) 13:37:04.76
>>293
JavaScriptのことだなそれ

295 :デフォルトの名無しさん:2013/11/10(日) 13:41:18.94
>>294
違うけど? どうしてそう思ったの?

296 :デフォルトの名無しさん:2013/11/10(日) 13:42:02.03
個々の関数もたとえばMathクラスのインスタンスだと捉えればいいのだ。

Math exp([] (double x) { return exp_impl(X);});
double y = exp(1.5);

297 :デフォルトの名無しさん:2013/11/10(日) 13:43:10.73
(Mathクラスのインスタンスではないが)
Mathクラスのインスタンスだと "捉えれば" いいのだ。

って言ってる時点でな・・・。

298 :デフォルトの名無しさん:2013/11/10(日) 13:44:51.10
>>293
もしかして、メソッド内で自身の状態を参照することを「オブジェクトの状態を取得」と表現してんの?
「オブジェクトの状態を取得」と言えば、普通外部に公開するgetterのことを想像するが。

299 :デフォルトの名無しさん:2013/11/10(日) 13:45:42.02
そもそもさ、minって
Intergerクラスのメソッドであるべきじゃないの?

Integer a = 1;
Integer b = 2;

Integer c = a.min(b);

みたいにさ。

300 :デフォルトの名無しさん:2013/11/10(日) 13:47:47.67
>>297
何が言いたいのか?

そりゃ実際の数学では個々の関数はインスタンスと考えられるけど、プログラム言語でも同様に実装しろと?

301 :デフォルトの名無しさん:2013/11/10(日) 13:52:33.44
>>299
minの意味を考えろ。属するクラスが全然違う。
Intergerクラスのメソッドなんかじゃない。

302 :デフォルトの名無しさん:2013/11/10(日) 13:55:16.15
JavaScriptだとプロトタイプだけじゃなくて
オブジェクトが直接持ってる
要はobj.method()と出来るものはなんでも
そのオブジェクトのメソッドと呼んだりするな

303 :デフォルトの名無しさん:2013/11/10(日) 13:58:30.10
>>299
演算子を内部的にメソッドであると解釈する考え方もあるようですが、
もうそろそろ、演算子とメソッドの根本的な違いを
人類が認識するべき時かもしれませんね。


演算子とメソッドは全く違うもの。そしてminは演算子。
a 演算子 b があったとき、これをa.演算子(b) と解釈するのは間違い。

演算子とはaやbのメソッドではなく、aとbを引数にする関数
演算子(a, b) つまり関数(a, b)と解釈するのが正しい。

aとbを対等に扱うものはメソッドではなく関数で実装する。
メソッドは特定のオブジェクトに対して処理をするものでなければならない。

もし無理やりminをメソッドにするならば、a.min(b) はaよりbが小さければ、
aの中身をbに置き換えるものでなければならない。

演算子を関数として解釈するならば、三項演算子
a ? b : c を if(a, b, c) と捉えることも簡単でしょう。
四項演算子、五項演算子ってのも作ろうと思えば作れるでしょうね。

Integer i, String s の演算子+をIntegerのメソッドにするか、Stringのメソッドにするのか
悩む必要もありません。演算子=関数ははクラスとは独立しているので、
関数+(Integer i, String s) を実装すればいいだけです。

304 :デフォルトの名無しさん:2013/11/10(日) 14:00:40.68
演算子オーバーロードでは
a + b

a.add(b)
とされるし区別ないよ^^;

305 :デフォルトの名無しさん:2013/11/10(日) 14:01:39.91
>>304
これほんと違和感あるわw

a + b

add (a, b)
と解釈するほうが
よっぽどわかりやすいだろ。

306 :デフォルトの名無しさん:2013/11/10(日) 14:05:55.97
C++ ではとうの昔から friend 関数にするのが好まれている

307 :デフォルトの名無しさん:2013/11/10(日) 14:08:27.76
例えばゲームの当たり判定でも、

自機が爆弾に当たれば爆発する、
自機が仲間にあたっても何も起こらない。
自機がパワーアップアイテムに当たればパワーアップする
っていうのを実装するとき、

この処理ををどこに実装するかって問題がある。
自機に実装すればいいと思うが、
そうすると、自機は、爆弾や見方やパワーアップアイテムという
情報を知らないといけない。
つまり外部のクラスに依存してしまうということ。

これを
接触関数(自機、爆弾) {
 自機.爆発();
 爆弾.爆発();
}

接触関数(自機、パワーアップアイテム) {
 自機.パワーアップ();
 パワーアップアイテム.消滅();
}

接触関数(自機、仲間) {
 なにもしない
}

とできれば、シンプルに実装できる。

308 :デフォルトの名無しさん:2013/11/10(日) 14:16:38.13
>>307
そっかjavascriptってすげーな

309 :デフォルトの名無しさん:2013/11/10(日) 14:18:38.49
>>305
それは関数のオーバーライドで済まそうっていう考えね
関数のオーバーロードが無い言語もあるし、型が緩い言語とかであっても
もっと広く適応できるメソッド的な仕組みで実現しようという試み

前者はまさに「演算子オーバーロード」だけど
後者は特定のタイプに対する演算子の振る舞いを定義するっていう
ちょっと考え方が違う

例えばaを主体について定義するとこうなる
a + b → a.add(b)
b + a → a.radd(b)

310 :デフォルトの名無しさん:2013/11/10(日) 14:19:43.71
>>308
見てわかるようにオーバーロードができる言語の話で
できないJavaScriptの話なんかしてないけど、
頭ダイジョーブ?

311 :デフォルトの名無しさん:2013/11/10(日) 14:21:28.54
例えばaを主体について定義するとこうなる
a + b → a.add(b) ・・・aにbを加算する
b + a → b.add(a) ・・・bにaを加算する

普通は
a + b ・・・ aとbを加算したものを返す

312 :デフォルトの名無しさん:2013/11/10(日) 14:23:14.38
足し算に順序なんてありません!
リストは足すものではありません!
みたいな〜

313 :デフォルトの名無しさん:2013/11/10(日) 14:28:15.11
行いたい処理で交換法則が成り立つとは限らないでしょ

314 :デフォルトの名無しさん:2013/11/10(日) 14:29:55.13
>>305
動的型付けにはオーバーロードなんてないんですよ!!

315 :デフォルトの名無しさん:2013/11/10(日) 14:31:20.43
この前から他人の発言を抜き出して騒いでるビックリ君なんなの?

316 :デフォルトの名無しさん:2013/11/10(日) 14:32:30.24
>>260,261
例として 1 + 2 という式を考えてみる

関数型の場合、(>>260が言うように)関数へ 1 と 2 という
整数オブジェクトを送ることが計算である

オブジェクト指向では、1 という整数オブジェクトへ + 2 という
メッセージを送ることが計算である
ここで、+ 2 の"+" は(演算子ではなく)メッセージの種類を示す
識別子であり、セレクタと呼ばれる
また、+ という関数オブジェクトへ整数対 (1, 2) というメッセージを
送るというスタイルでも計算を表現できる

まとめると、オブジェクト指向の中で、後者の関数オブジェクトへ
引数を送るというスタイルに限定したものを関数型と呼ぶ
言い換えると、オブジェクト指向は関数型を包含した計算モデルである

317 :デフォルトの名無しさん:2013/11/10(日) 14:32:41.57
関数(写像)と関数の合成の場合は順序が重要だな

318 :デフォルトの名無しさん:2013/11/10(日) 14:33:38.50
>>314
オーバーロードがなくても型はあるんだから
実行時オーバーロードをスレば良い。

つまり、型みて振り分ければいいだけ。

add(integer a, integer b)で呼ばれたら
add_integer_integer(a, b)に移譲
することだってできるだろう?

319 :デフォルトの名無しさん:2013/11/10(日) 14:34:38.35
>>316
正解!

320 :デフォルトの名無しさん:2013/11/10(日) 14:34:55.12
>>316
オブジェクトはメッセージを受け取れない
受け取れるのは関数とはそういった類のもの
わざわざ難しく考えてるようにしか見えない

321 :デフォルトの名無しさん:2013/11/10(日) 14:37:10.00
>>318
それは変だよ
add_integer_integer(a, b)
という関数書いたら自動で使われるっていうのは

322 :デフォルトの名無しさん:2013/11/10(日) 14:37:17.20
>>318
できるの?具体的のどの言語のこと言ってるの?

323 :デフォルトの名無しさん:2013/11/10(日) 14:39:22.51
mpz_add (mpz_t rop, mpz_t op1, mpz_t op2)
こういうのを手続き型っていうんですよね?

324 :デフォルトの名無しさん:2013/11/10(日) 14:41:07.53
は?

型名を取得する関数はあるんだから
integerという型名がわかったら、
あとはeval('add_' + name_a + '_' name_b + '()')
を実行するだけじゃねーかw

325 :デフォルトの名無しさん:2013/11/10(日) 14:43:01.33
>>324
めんどっすね。

326 :デフォルトの名無しさん:2013/11/10(日) 14:46:51.50
>>324
call度にeval介するのか
うんうん、初心者にしては頑張ったな

327 :デフォルトの名無しさん:2013/11/10(日) 14:47:31.09
>>325
汎用的な関数で処理できるんだから
あとは1行書けば終わりだよ。

function add(a, b) {
  return hogehoge('add', a, b');
}

このhogehoge関数を
作れない人はいないでしょ?


これだけでも出来るかもな
add = function(a, b) { hogehoge('add', a, b') }

さらに
add = createHogeHoge('add');

スタックトレース解析して関数名取得するなら
add = createHogeHoge();

328 :デフォルトの名無しさん:2013/11/10(日) 14:48:39.62
>>326
> call度にeval介するのか

あのー、動的型付け言語ってのは
そういうものなんですけど?

329 :デフォルトの名無しさん:2013/11/10(日) 14:50:53.66
一方動的言語の代表JavaScriptはよりまともな方法を選んだ
http://www.slideshare.net/BrendanEich/js-resp/10

330 :デフォルトの名無しさん:2013/11/10(日) 14:52:56.45
>>327
その名前の関数こしらえなきゃならんのでしょ、めんどっすね。

331 :デフォルトの名無しさん:2013/11/10(日) 14:54:32.32
>>328
コスト考えましょうね初心者君

332 :デフォルトの名無しさん:2013/11/10(日) 14:56:32.77
両方の方法があるね、でも関数オーバーライドがないような
動的言語には向いてないねって言ってるだけなのにどうして意地を張るのか
もwしwかwしwてwww
本当にこ、>>318 wwwこwwれwwがwwいいとwwww思ってんのかwwwww

333 :デフォルトの名無しさん:2013/11/10(日) 14:57:11.19
>>327
釣りが流行ってるのか?
そんなに突っ込みどころ用意してたら釣られる奴いなくなるだろ

334 :デフォルトの名無しさん:2013/11/10(日) 14:57:43.24
>>328
ちがうよ

335 :デフォルトの名無しさん:2013/11/10(日) 14:58:35.07
>>316
おおむね賛成だが
> 関数オブジェクトへ引数を送るというスタイルに限定したものを関数型と呼ぶ
この定義はちょっと違うだろ?

336 :デフォルトの名無しさん:2013/11/10(日) 15:01:13.30
>>330
> その名前の関数こしらえなきゃならんのでしょ、めんどっすね。

何が面倒くさいの?

型ごとに関数を作ること?
あぁ、それは静的型付け言語でも
同じだったw

337 :デフォルトの名無しさん:2013/11/10(日) 15:03:44.62
>>336
静的言語だと関数名変わるわけじゃないし
hogehogeとか書く必要ないし簡単だよ。
動的型なのに型を調べるっていうのがもうちょっと無理があると思う。

338 :デフォルトの名無しさん:2013/11/10(日) 15:04:31.32
性的メソッドからここまでの流れを産業で

339 :デフォルトの名無しさん:2013/11/10(日) 15:05:59.90
>>338
生産性を高めたいなら静的言語を使うべき

340 :デフォルトの名無しさん:2013/11/10(日) 15:06:54.27
>>336
継承があるから型ごとには作らないよ
でも動的型で型名から振り分けとなると自分で全部やることになるよ

341 :デフォルトの名無しさん:2013/11/10(日) 15:07:15.21
>>316
関数型の場合、関数と値(0引数関数)は区別されないよ

342 :デフォルトの名無しさん:2013/11/10(日) 15:07:32.39
こういうのが言いたいんでしょ?
http://www.slideshare.net/BrendanEich/js-resp/15
ただの関数名でどうこうできるとかアホすぎ

343 :デフォルトの名無しさん:2013/11/10(日) 15:08:08.51
最近性的生産性が落ちてきて困っています。

344 :デフォルトの名無しさん:2013/11/10(日) 15:08:45.41
歳のせいだな

345 :デフォルトの名無しさん:2013/11/10(日) 15:11:20.36
また、動的型付け言語は論破されたのかw

346 :デフォルトの名無しさん:2013/11/10(日) 15:11:24.18
マルチメソッドを知らない子達が
不毛な議論をしてるのはココですか?

347 :デフォルトの名無しさん:2013/11/10(日) 15:12:05.37
なんでオブジェクト指向の話になると自分だけのローカル用語使う奴が出てくるんだろ

348 :デフォルトの名無しさん:2013/11/10(日) 15:12:35.70
そら最終的には静的型と同じで型指定になるわな
こっちのが楽なの当たり前なんだから
素直に良い部分は良いと認めりゃいいだけなのに

349 :デフォルトの名無しさん:2013/11/10(日) 15:12:57.85
マルチメソッドは
無意味に難しくしたものだと思っている。

関数オーバーロードができれば、
マルチメソッドは不要になる。

350 :デフォルトの名無しさん:2013/11/10(日) 15:16:12.35
いや同じ概念だし
単に実行時かどうかの違いだし

351 :デフォルトの名無しさん:2013/11/10(日) 15:16:49.59
オーバーロードは静的な型で呼び出す関数を切り替える
マルチメソッドは動的な型で呼び出す関数を切り替える

第一引数でディスパッチする普通のメソッドを拡張したのがマルチメソッド

352 :デフォルトの名無しさん:2013/11/10(日) 15:18:14.20
>>350
型推論と動的型付けくらいには違うんじゃないか

353 :デフォルトの名無しさん:2013/11/10(日) 15:19:56.84
両方できるC#が最強ということで

354 :デフォルトの名無しさん:2013/11/10(日) 15:24:17.29
オーバーロードから更に一歩進んだのが
代数的データ型とパターンマッチによる分岐

355 :デフォルトの名無しさん:2013/11/10(日) 15:29:49.32
マルチメソッドをオブジェクト指向言語に取り入れる上で気になるところは
マッチする関数が複数あった場合どうなるかってとこだな
静的なオーバーロードみたくコンパイルエラーには出来ないケースもあるだろうから
実行時エラーにするかHaskellのパターンマッチみたく最初にマッチした関数を実行するくらいしか無いだろうけど

356 :デフォルトの名無しさん:2013/11/10(日) 15:39:22.56
そんなのswitchで書けるし

357 :デフォルトの名無しさん:2013/11/10(日) 15:48:55.33
それをswitch汚染という。至る所に同じswitch文が表れる。

358 :デフォルトの名無しさん:2013/11/10(日) 16:13:24.85
メソッドオーバーロードは便利だよね
Perl6はサポートしてるけど、主要なスクリプト言語だとそれくらいだよな
ま、Perl6リリースできてないけど

359 :デフォルトの名無しさん:2013/11/10(日) 16:19:14.85
どういう時に便利なの?

360 :デフォルトの名無しさん:2013/11/10(日) 16:20:20.39
Perl6って仕様そこそこまとまっててベータ版の実行系くらいはあんの?

361 :デフォルトの名無しさん:2013/11/10(日) 17:06:57.42
Pythonにもマルチメソッドデコレータがある

362 :デフォルトの名無しさん:2013/11/10(日) 18:01:30.90
Perl6は静的型付けだし

363 :デフォルトの名無しさん:2013/11/10(日) 19:01:29.04
なんか少し巻き戻してみるとstaticに関する話が頓珍漢な形で収束しているな・・・

> 引数と戻り値だけで完結するものは、メソッドではないとも言ってる。

はぁ?

> 引数と戻り値だけで完結するもの

そんなのは実装の詳細であってメソッドのクライアントには知り得ぬことだ。
そしてこんな実装の詳細によってpublicインターフェイスがstatic云々とかが
左右されるわけないでしょ。

> ユニットテストをすることを考えると、publicにした方がいい。

内部に深い呼び出し階層を持つコードを外からテストする方法は毎度悩ましい
問題ではあるけれども、「ユニットテストをすることを考えるとpublicにした
方がいい」なんて脳天気にpublicにすることなんてあり得ない。
public汚染の罹患者ですか?

364 :デフォルトの名無しさん:2013/11/10(日) 19:10:32.54
> そんなのは実装の詳細であってメソッドのクライアントには知り得ぬことだ。

へ?

対象のオブジェクトを変化させたいと思ってるから、
そのメソッドを呼ぶわけで、メソッドのクライアントは
知り得ることだけど?

365 :デフォルトの名無しさん:2013/11/10(日) 19:19:09.61
引数と戻り値は、実装のインターフェースであって
実装の詳細じゃないけどね。

メソッドを実行した結果、何が起きるかは
メソッドのクライアントが知るべき情報。
当たり前じゃない。

実装の詳細は知りえぬっていうのは、「何が起きるか」は知らせるが
その起きる動作を実現する方法は知らせないって話。

全く違いすぎるよ。

あーあ、バカ晒したねぇ。そういうことだよ
こういうレベルのやつが噛み付いてくるんだよ。

366 :デフォルトの名無しさん:2013/11/10(日) 19:21:22.10
仕様は知るべきだけど実装は知らなくていいな

367 :デフォルトの名無しさん:2013/11/10(日) 19:25:38.70
そもそも公開する必要無いようなメソッドをテストする必要が出てくるのってレアケースじゃね?

368 :デフォルトの名無しさん:2013/11/10(日) 19:26:35.16
>>365
そもそも論として「完結」って何よ?

たとえばminメソッドでいえば、そのメソッドはオブジェクトの状態を変化させない
immutableなメソッドだとドキュメントに明記されていて実際にそう実装されている
とする。この場合、minメソッドはメソッドではない方が良いの?

369 :デフォルトの名無しさん:2013/11/10(日) 19:32:14.65
方がいいとか意味不
であるかでないかの話をしてるんだが

370 :デフォルトの名無しさん:2013/11/10(日) 19:52:19.71
あ、そう。
で、どうなの?
引数としてintを二つとって一つ返す、オブジェクトの状態を変化させないminという
名前の操作はメソッドなのそれともメソッドでは無いの?

あとテスト目的でpublicにする是非もよろしく。
この手のpublic汚染もstatic汚染と同様に初学者によくある現実のパターンなので。

371 :デフォルトの名無しさん:2013/11/10(日) 20:03:13.11
> immutableなメソッドだとドキュメントに明記されていて

これを実装の詳細だと言うやつがいるんだよねぇw
これ(オブジェクトを変えるか変えないか)は仕様であって
実装の詳細じゃないのにね。

372 :デフォルトの名無しさん:2013/11/10(日) 20:06:01.03
Javaではなんでもメソッドとして
実装するしか無いよ。

まあそういうのは無視して、
immutableなメソッドかつ、引数と戻り値が全て
(つまりオブジェクトの内部状態にアクセスしない)
まさにmin関数のようなものを

逆にインスタンスメソッドとして実装する理由は何?
その理由を聞きたいね。

名前空間として使う以外に、なにもないでしょう?

373 :デフォルトの名無しさん:2013/11/10(日) 20:10:47.52
>>370
> あとテスト目的でpublicにする是非もよろしく。

テストしたほうがいいのに、テストしないってのは良くない。
他の関数経由でテストできるというが、
それだと、単体でテストするよりもテストが複雑になる。

テストは一番シンプルな形でテストしたほうが
複雑性を取り除くという意味で良い。

で、テストのためにpublicにするのがいやなら、
発想を変えてpublicにするのが妥当な設計に変えればいい。

つまり、あるクラスにprivateなmin関数があるのであれば、
別のクラスを作って、そこにpublicなmin関数を作り
あるクラスからは、そのmin関数を呼べばいい。
そうすれば、自然な設計でpublicにできる。

minのようなものは例外で、そうそうあるもんじゃないと思うかもしれないが、
あるクラス・・・で使用するユーティリティを集めたクラスという設計にすれば、
自然な形で比較的簡単にpublicに変更できる。

374 :デフォルトの名無しさん:2013/11/10(日) 20:14:47.81
privateなんて必要ないがな
クロージャでOK

375 :デフォルトの名無しさん:2013/11/10(日) 20:15:42.00
クロージャーは変数のスコープを小さく出来ないので
関数内関数があったほうがいい。

376 :デフォルトの名無しさん:2013/11/10(日) 20:20:47.72
参照できるだけで書き換えられないなら
クロージャで良いよ

377 :デフォルトの名無しさん:2013/11/10(日) 20:22:57.19
Rubyからscalaに変えるべき15の理由
http://www.slideshare.net/yukishigenakajo/rubyscala15

> Railsによって得られた生産性の向上は、テスト作成の作業に失われてしまいました

> Ruby(動的言語)の限界
> - 大規模開発に向かない
> - 実行するまでエラーがわからない

もうさ、いろいろと揺り戻しが来てるよね、最近。
動的言語とか、GCとか、ゼロ年代に流行ったものがやっぱり駄目だったと。
潮流が完全に変わった。

動的言語信者は「テスト書け」でずっと押し通してきたが
プログラマは怠惰が美徳であるべきということを忘れている。
テストを書けばいいというのは「運用で解決」と大して変わらんではないか。

必要以上に膨大なテストコードを書くことを厭わない勤勉さはプログラマ失格だ。

378 :デフォルトの名無しさん:2013/11/10(日) 20:26:07.50
LLに実行するまでエラーが分からないと言っちゃあオシマイだな
実行してエラーを見つけるものなのに、そこが受け入れられないのは頑固者というもんだよ
まあテスト書きゃあいいだけだが

379 :デフォルトの名無しさん:2013/11/10(日) 20:28:32.28
>>377
GC・・・だと・・・?

380 :デフォルトの名無しさん:2013/11/10(日) 20:30:41.72
非コンパイル言語は逆にそれを活かして
トライアンドエラーでコーディングしていくものと思ってる
別にそこで開発効率が落ちるとは思わない

381 :デフォルトの名無しさん:2013/11/10(日) 20:31:38.64
>>379
ゼロ年代に流行ったGCっていったら
ゲームキューブの方だぞ
勘違いするな

382 :デフォルトの名無しさん:2013/11/10(日) 20:34:50.49
スレタイの潜在開発生産性って
プログラムレベルだと要はGCみたいなオートシステムが新たに生まれるってことしかないよね
例えば動的なマルチコアへの負荷分散とか、そういうの

383 :デフォルトの名無しさん:2013/11/10(日) 20:36:58.39
静的型付け言語を使うからって別に必要なテストの量が減るわけじゃない

384 :デフォルトの名無しさん:2013/11/10(日) 20:47:08.48
>>380
活かしてというかそうせざるを負えないんだろ。
テストが網羅されてることを人間が判断しなきゃいけない時点で効率悪いと思う。

385 :デフォルトの名無しさん:2013/11/10(日) 20:48:16.14
よく分からんけどものすごく大きいシステムを作ってしまったんじゃないの?
そもそもサーバーサイドでフレームワークを使う時点で厳しいと思わなくてはならない
実はできる限り物事の繋がりを解いてシンプルにした方が楽な事のほうが多い

フレームワークは簡単にプロトタイプを作るためのもの
フレームワークそれだけでシステムだから更にその上にシステムを作ろうとすると
そりゃあテストから何から大事になる

386 :デフォルトの名無しさん:2013/11/10(日) 20:48:24.62
>>371
> これを実装の詳細だと言うやつがいるんだよねぇw

仕様だよ。
実装の詳細は「オブジェクトの内部状態にアクセスしない」という部分だ。

>>372
> 逆にインスタンスメソッドとして実装する理由は何?

「immutableなメソッドかつ、引数と戻り値が全て」というのは「オブジェクトの
内部状態にアクセスしない」とはイコールでは無いからだ。

たとえばinterface MyInterface{int min(int a, int b);}があって、これを実装
した具象クラスの実装の詳細が

return a <= b ? a : b;



private final Comparator<Integer, Integer> myComparator;
...
return this.myIntComparator.compare(a,b) <= 0 ? a : b;

かはメソッドのクライアントにとっては知ったことでは無いからだ。
クライアントが知っているのは、そのオブジェクトが知っているやり方で小さい方の
intを返すだけであって、その実装が内部状態にアクセス云々は知った話では無い。

この例を挙げたのはComparatorの例を示したかったからでもある。
JavaだとComparator#compareはインスタンスメソッドで、それも大抵その実装は
「immutableなメソッドかつ、引数と戻り値が全て」だと思うのだが。
こういうインスタンスメソッドもおかしいのかな?

387 :デフォルトの名無しさん:2013/11/10(日) 20:48:40.08
>>383
減るでしょ。コンパイルできた時点で型の問題はないことが保証される。
テストしなくてもいいレベル。

388 :デフォルトの名無しさん:2013/11/10(日) 20:51:03.74
>>384
テストに動的かどうかなんて関係ないでしょうに

389 :デフォルトの名無しさん:2013/11/10(日) 20:53:07.70
>>388
ある。ありまくり。静的言語ではコンパイラがやってくれる
型チェックの網羅を動的言語では人間がテストコードを書いて
チェックしなきゃいけない。静的言語ではコンパイルできた段階で
テスト終わってる。コンパイラがやってくれる。これこそが生産性。

390 :デフォルトの名無しさん:2013/11/10(日) 20:57:36.88
『私はテストを書いたことがありません』
まで読んだ

391 :デフォルトの名無しさん:2013/11/10(日) 21:01:29.84
文字列を期待してて100文字以内かチェックするのに普通lengthを使うが
もしかしたら配列が返ってきてるかもしれないから型チェックも要るんだ!
みたいなこと言いたいんだろうか……(呆)

392 :デフォルトの名無しさん:2013/11/10(日) 21:02:34.92
>>390
静的言語ではコンパイルできた段階で型の問題がないことが『保証される』が
動的言語では人間がテストコードを書いて確認するだけだから型の問題がないと『思う』という
レベルに留まり甚だ信頼性の低いものなのである

393 :デフォルトの名無しさん:2013/11/10(日) 21:05:12.67
型の問題とやらがあれば出力値が狂うからわかるし
型の問題とやらがないとしても出力値のテストは同じだけ要るやん

394 :デフォルトの名無しさん:2013/11/10(日) 21:05:32.20
>>391
静的言語ではコンパイルが通った段階で型の問題は完全に解決されてる
わけだからあとはざっと眺めてロジックが間違ってないことを確認すれば
テスト終了

動的言語ではいつテストを終えればいいのかもわからない
ほとんどの場合もういいやと開発者が途中で投げ出してテスト完了
どっちがいいかはいうまでもない

395 :デフォルトの名無しさん:2013/11/10(日) 21:07:45.52
よし、もう触るのは止めよう

396 :デフォルトの名無しさん:2013/11/10(日) 21:08:05.05
全ての取り得る入力値をテストしない場合に妥協になるのは動的静的関係ないがな
その理屈だと静的にバグは皆無ってことになる

397 :デフォルトの名無しさん:2013/11/10(日) 21:08:32.92
>>393
すべての型の問題は出力値の違いによって検出できるとは『限らない』わけで
これが型の問題がないと『思う』というものの限界
『保証される』こととは天と地の差がある

398 :デフォルトの名無しさん:2013/11/10(日) 21:09:49.58
>>あとはざっと眺めてロジックが間違ってないことを確認すれば
この辺が笑いどころですね、分かります。

399 :デフォルトの名無しさん:2013/11/10(日) 21:11:13.53
>>396
同じ時間をかけて作ったならば静的言語の方がバグが少ない
コンパイル段階で型の問題がなくなるから
動的言語では型の問題がなくなったと開発者が思うだけ
この違いわかるかなあ

400 :デフォルトの名無しさん:2013/11/10(日) 21:14:03.15
はぁ、で、型の問題って何?

401 :デフォルトの名無しさん:2013/11/10(日) 21:15:43.93
>>373
> 発想を変えてpublicにするのが妥当な設計に変えればいい

その手のプラクティスで重用されるのがたとえばDIなんだが。
staticネタと関連する点ではたとえばDIではファクトリやロケーター等のstatic
メソッド呼び出しは一般的に排除される傾向がある。

>つまり、あるクラスにprivateなmin関数があるのであれば、
>別のクラスを作って、そこにpublicなmin関数を作り

それは他方で新たな依存性を導入するということでありテスト目的でアドホック
にこんなことをやられては正直たまらん。


> あるクラス・・・で使用するユーティリティを集めたクラスという設計にすれば、
> 自然な形で比較的簡単にpublicに変更できる。

ユーティリティメソッド依存症というのもあってだな、このクラスからだけ使うと
思って切り分けたユーティリティメソッド群をpublicとして実装するも、予期せぬ
クラスからもこれは便利だと参照されるようになった結果元のクライアントクラス
の仕様変更に伴いあるユーティリティメソッドを書き換えようにも他のからも
使われまくりでおいそれと変更できないということがある。

いいとこパッケージプライベートだよ。適切なメソッドの可視性を実現するために
皆気をつかっているのにこの人は書くこと書くことお気楽すぎる。

402 :デフォルトの名無しさん:2013/11/10(日) 21:15:56.92
※ここまで静的型がよりテストが少なくて済むという説明なし※

403 :デフォルトの名無しさん:2013/11/10(日) 21:17:46.38
>>400
いろいろある
オブジェクトが持ってないメソッドを呼び出してたり
メソッド呼び出しの引き数が違ってたり
全然違うオブジェクトを参照してたりする
動的言語ではそれをテストコードを書いてチェックしなければいけない
しかもすべてチェックできたかどうかはわからない
静的言語ではコンパイラがすべて自動的にやってくれる
しかも保証される

404 :デフォルトの名無しさん:2013/11/10(日) 21:18:13.90
型と考えるから理解できないんだよね。
コードの参照の有無。

例えば、動的型付けで
このpublicメソッドにアクセスしているのはどこ?
って質問に、正確に短時間で答えられる?

動的型付け言語でも、時間かければできるさ、
だけど同じ時間で質を上げたほうがいいだろ。
時間が問題だってことにいい加減気づこう

405 :デフォルトの名無しさん:2013/11/10(日) 21:19:56.88
>>401
えとさ、時と場合により
どっちがいいか変わるって
話はやめてくれる?

わかりきってることで、
それ反論になってないから。

時と場合により、俺の言ってることが正しいって
認めてるでしょう?

406 :デフォルトの名無しさん:2013/11/10(日) 21:20:58.55
>>402
静的言語ではコンパイラがほぼすべてのテストを自動的にやってくれるから
あとは開発者がざっとコードを眺めて終わりにできる

動的言語ではすべてのパスを通るテストコードを書かなきゃいけない
しかもすてべのパスを通っているかは開発者がそう思うって程度にしか
わからない

407 :デフォルトの名無しさん:2013/11/10(日) 21:21:51.90
「静的言語ではコンパイラがほぼすべてのテストを自動的にやってくれるから
あとは開発者がざっとコードを眺めて終わりにできる 」

「動的言語ではすべてのパスを通るテストコードを書かなきゃいけない
しかもすてべのパスを通っているかは開発者がそう思うって程度にしか
わからない 」


↑すぐにわかると思いますが、これを言ってる人=こういう勘違いをしている人は
動的型付け言語愛好者ですw

408 :デフォルトの名無しさん:2013/11/10(日) 21:22:34.67
動的型付け言語愛好者は馬鹿だから、
こんな誰も言ってない言葉が
聞こえるんですよ。

409 :デフォルトの名無しさん:2013/11/10(日) 21:22:41.28
動的型言語は内部の型についてのロジックが思ったとおりになってるか分からない
なるほど
ならテストの増やしようが無いんじゃね?
結局内部のロジックが思ったとおりになってるか分からないのは皆同じなんだし

410 :デフォルトの名無しさん:2013/11/10(日) 21:22:52.67
>>407
意味不明

411 :デフォルトの名無しさん:2013/11/10(日) 21:24:26.75
>>410
なら意味がわかるようにちゃんと言ってあげましょうか?

動的型付け言語愛好者は卑怯だっては話です。

↓こんなことは誰も言ってないのですよ。
「静的言語ではコンパイラがほぼすべてのテストを自動的にやってくれるから
あとは開発者がざっとコードを眺めて終わりにできる 」


だ・け・ど、わざと静的型付け言語を褒めるふりして、
でたらめなことを言ってる。

そういうことです。

412 :デフォルトの名無しさん:2013/11/10(日) 21:25:55.25
確かに、動的型付け言語だと、
grepで検索して探すしか無いからな。

それで見つかっても、それがたまたま同じ名前なだけで
違うメソッドである可能性があるから、
見つかったメソッドの数だけ、
正しいかを判断していかないといけない。

2、3個ならいいが、大規模になると
手におえないよ。

413 :デフォルトの名無しさん:2013/11/10(日) 21:26:37.65
>>411
酷い妄想ですね
バカなんですか?死ねばいいと思います

414 :デフォルトの名無しさん:2013/11/10(日) 21:26:54.05
>>403
>オブジェクトが持ってないメソッドを呼び出してたり
メソッド名は動的に決まり得る
>メソッド呼び出しの引き数が違ってたり
型関係なし
>全然違うオブジェクトを参照してたりする
目的において違う=型が違う
と思うのはあまりにも浅はかすぎ

415 :デフォルトの名無しさん:2013/11/10(日) 21:28:27.23
>>413
ごめんね、ばらしてw

416 :デフォルトの名無しさん:2013/11/10(日) 21:29:08.03
動的に決まる=決まるのが遅い。

決まってからでないとテストが出来ない。

何もかも遅れる。遅い。

417 :デフォルトの名無しさん:2013/11/10(日) 21:30:43.36
すれ違いがあるようだが
そもそも動的型付言語では型の違いは問題ではない

418 :デフォルトの名無しさん:2013/11/10(日) 21:30:50.42
>>414
>メソッド名は動的に決まり得る

それが間違ってたときのことですよ

>型関係なし

型が関係ある話です
勝手に関係ないとか決め付けないでください

>目的において違う=型が違う
>と思うのはあまりにも浅はかすぎ

ここでの違うは意図しないという意味です
浅はかなのはあなたです
全部頓珍漢ですね

419 :デフォルトの名無しさん:2013/11/10(日) 21:30:55.97
>>414
> >メソッド呼び出しの引き数が違ってたり
> 型関係なし

関係有るぞ?

obj.foo(1, 2, 3)

fooがいくつの引数を持っていることは、
objがどんなクラス(型)か決まってからでないと
判断できない。

こんな基本的なこともわからないから
静的に型が決まることが、意味が無いと言ってるんだろうね。

420 :デフォルトの名無しさん:2013/11/10(日) 21:32:09.39
>>419
テスト時に分かるかどうかの話をしてるのですが
本題をお忘れです?

421 :デフォルトの名無しさん:2013/11/10(日) 21:32:21.54
テストを実行すればわかるとからなともかく、
引数の数に、型が関係ないと
言ってしまったのは、アウトだなw

言ってしまったからね。
どうするんだろうね?

422 :デフォルトの名無しさん:2013/11/10(日) 21:33:18.32
>>417
型に無自覚であるがゆえに起こる意図しない動作を型の問題と
言っているのですよ
それくらい読み取ってもらわなきゃ

423 :デフォルトの名無しさん:2013/11/10(日) 21:34:32.71
>>420
テスト時にわかるって要するに、
テストする前にわかるのに比べて、
わかるのが遅いって言ってるのと同じなんだけど、
そこんところ理解してる?

テスト時にわかっても遅いんだよ。
そんなちんたらした開発してんな。

424 :デフォルトの名無しさん:2013/11/10(日) 21:37:07.68
動的厨ってHello world以上のプログラムを書いたことがあるのでしょうか・・・

425 :デフォルトの名無しさん:2013/11/10(日) 21:37:46.01
結局反論できずに言い訳や話をそらす事、もしくは煽りしか出来ないんですか
ガッカリです

426 :デフォルトの名無しさん:2013/11/10(日) 21:38:47.94
>>405
> 時と場合により、俺の言ってることが正しいって
> 認めてるでしょう?

知らんがな。とりあえずいいたいのは時と場合によらず下のような短絡的な思考は
トラブルの元だからもっと慎重になれってことだ。

>>290
> まずスコープがprivateである。
> これはユニットテストが出来ないことを意味する。
> ユニットテストをすることを考えると、
> publicにした方がいい。

で、批判したら>>373みたいなフォローがあったけどそれにしても牧歌的すぎるので
追加で>>401として積み重ねただけの話。

staticメソッドの方に関してはもう返答は無いみたいだね。
> 引数と戻り値だけで完結するものは、メソッドではないとも言ってる。

こんな妙な認識、どこから出てきたのだろう。まあ終わったみたいだから良いけど。

427 :デフォルトの名無しさん:2013/11/10(日) 21:39:01.79
で、その型の問題とやらがどうテスト項目に影響するのかまだ聞いてないんだけど

428 :デフォルトの名無しさん:2013/11/10(日) 21:40:11.94
動的型付け批判っていうかTDD批判?

429 :デフォルトの名無しさん:2013/11/10(日) 21:43:19.37
静的型ならテストして内部を眺めれば正しいかどうか分かる!!
うーむ、自分が使うとすべての言語が動的型になってしまうようだ

430 :デフォルトの名無しさん:2013/11/10(日) 21:54:21.14
要は動的に決まる事はチェック困難だから排除してしまえって思想?
あー何となくわかった感じする
LLでは作りながら細々自然にチェックするんだよね
コンパイルチェックってものもないし、上で挙がってるように
あとからまとめてテストして終わり!って感じなのと相性あまり良くないから

その作りながらのチェックを「テスト」というものにしてしまうと大変かもね
この前話題出たけどコンソール出力、段階置かずにああいうので流れるように
チェックとトライアンドエラー、作成をやっていくのがLLのコツだと思う

確かに結局はコンパイラがやってくれるようなところを自分でやってるのはあるんだろうね
まあでもそれは柔軟さとの引き換えでもあるから、しかたないけど、どうしたらいいのかねえ

そう言えば気づいたことだけどLLの方が1つの関数長く書く気がする
こういうのもチェックしやすい自然の工夫なのかもね
他にも設計の組み立て方とかが結構変わってくると思う

431 :デフォルトの名無しさん:2013/11/10(日) 21:57:58.28
LLerは例えコンパイルチェックやテストがあっても、目で値を見て確かめないと安心できない
逆にそういうのが無くても目で見ることによって、ちゃんと動いてるなと考える
これって合ってると思う?

432 :デフォルトの名無しさん:2013/11/10(日) 22:04:04.46
その場のチェックで済ませてテストを書き起こさないようだと将来の仕様変更やメンテナンス時に困る。
その場のチェックで済むのは書き捨てだけ。

433 :デフォルトの名無しさん:2013/11/10(日) 22:08:01.91
テストなんか残すものは最低限、それこそAPIレベルでの出力値のチェックでいい。
それとは別に残さないテストも必要不可欠。

434 :デフォルトの名無しさん:2013/11/10(日) 22:33:00.11
昔は机上デバッグのように
しっかり考えてから開発したもんだが、
動的型付け言語野郎を見ると
何も考えずに開発してる
時代は変わったなーって思うよw

435 :デフォルトの名無しさん:2013/11/10(日) 22:33:55.42
変わったんだよ

436 :デフォルトの名無しさん:2013/11/10(日) 22:35:19.04
悪い方向にね。

437 :デフォルトの名無しさん:2013/11/10(日) 22:37:59.42
> そう言えば気づいたことだけどLLの方が1つの関数長く書く気がする

その一言で、あ、こいつ技術ないなって
わかっちゃったよ。

438 :デフォルトの名無しさん:2013/11/10(日) 22:41:29.52
で、その型の問題とやらがどう開発時間に影響するのかまだ聞いてないんだけど

まさか静的型付け言語の方が開発時間が短いって言う訳?
例えばメソッドの参照箇所を検索するのが速いとか、
簡単なミスをその場で気づくことが出来るとか、

確かに、型の問題じゃなくて
開発時間に大きなメリットが有ると思うよ。

でもテスト項目には影響しないだろー?
開発時間が短くなっても
テスト項目に影響しなければ
メリット無いって言ってくれよ!

439 :デフォルトの名無しさん:2013/11/10(日) 22:58:18.76
毎回そうだけど、静的型付けのメリットが
簡単なミスを見つけることよりも、
ミスを見つける手間や速さ、
そしてプログラム全体の把握だというと
途端に静になるんだよね。

静的型付けでバグが見つかる。
だからそれはテストなんだって勘違いしている人は
大概これで黙る。

440 :デフォルトの名無しさん:2013/11/10(日) 23:00:12.24
LLの関数が長く感じるのは抽象度が高くて
メインからサブをちょこちょこ呼ぶ形になるからだと思うわ

441 :デフォルトの名無しさん:2013/11/10(日) 23:02:58.65
静的型付けのほうがバグが見つかるっていうのは
静的型前提で書いててもしチェックがなかったらとして比べた場合であって
逆に動的型前提で書くとそもそも静的のようなチェックが入るとエラるんだから
比べるようなもんじゃないのにねえ
いつになったら分かるんだろうか

442 :デフォルトの名無しさん:2013/11/10(日) 23:04:20.60
関数の実装は静的型、利用は動的型がやりやすいってことでしょ結局
もうこれでいいよ

443 :デフォルトの名無しさん:2013/11/10(日) 23:05:50.71
JSはCの二倍速い。

444 :デフォルトの名無しさん:2013/11/10(日) 23:08:15.31
20倍だろ
間違えんなよ

445 :デフォルトの名無しさん:2013/11/10(日) 23:09:25.13
そもそもCとJSが比べられることが無いがな
C++でしょうに

446 :デフォルトの名無しさん:2013/11/10(日) 23:23:18.44
C++とCって違うのか?

447 :デフォルトの名無しさん:2013/11/10(日) 23:52:11.64
1違う

448 :デフォルトの名無しさん:2013/11/11(月) 00:09:36.36
http://ideone.com/w9xC6R

449 :デフォルトの名無しさん:2013/11/11(月) 00:34:31.31
やつは言った。
テストがあればわかるのだから
実行前に一切のチェックは不要。
文法エラーでさえも、テストでわかれば十分だ。



ま、そんなこと言ったなんて嘘だけどさw
でも、テストがあればー、テストさえあればーって
言ってる人はそう思ってなきゃいけないはずなんだよね。

俺はやだね。バグとはいえないような簡単なミスであればあるほど
実行前にすぐに見つけて欲しい。

テストコードにバグですと言われて、どこにバグが有るんだ!?って
探すなんてマヌケはしたくない。
テストコードはバグが有るのはわかっても、バグの場所までは教えてくれないからさ。

450 :デフォルトの名無しさん:2013/11/11(月) 00:56:25.82
今宵の学芸会はここですか?

451 :デフォルトの名無しさん:2013/11/11(月) 00:59:12.40
そんな駄文を皆に見せるためにサルがとけるまで真っ赤な顔して耐えてたのか
プログラミング始めて何ヶ月か分からんがオレすげーは早めに卒業しとけよ

452 :デフォルトの名無しさん:2013/11/11(月) 01:22:28.05
なんか文句言うだけのやつが多くてワロタw

453 :デフォルトの名無しさん:2013/11/11(月) 01:38:48.85
きちんとテストを書けばデバッガは必要ない。
デバッガを使っているのは初心者。

454 :デフォルトの名無しさん:2013/11/11(月) 01:39:26.30
今度は釣れますかな?w

455 :デフォルトの名無しさん:2013/11/11(月) 01:40:14.95
テスト → バグを見つけるもの
デバッガ → 見つけたバグを修正するもの

役目がぜんぜん違う。

456 :デフォルトの名無しさん:2013/11/11(月) 01:42:18.52
あれだ、動的型付信者は静的型付を触った事あるかのように言うけど
本当に触ったぐらいでしかないんだろうな。
変数宣言云々とか規約や運用の問題とか言うけど
それを管理(レビュー)するコストだって掛るだろうに。

入力フォームなどで入力する際に入力時にエラーを返してくれる画面と
サブミットしないと返してくれない画面があったらどっちが
利用者にとって楽かって問題と一緒でしょ

457 :デフォルトの名無しさん:2013/11/11(月) 01:50:09.67
シャドーボクシングかな?

458 :デフォルトの名無しさん:2013/11/11(月) 01:51:38.51
デバッガを使うということはバグがあると宣言してるようなものだな
客がかわいそう
金返してやれよ

459 :デフォルトの名無しさん:2013/11/11(月) 01:54:14.39
それをいうならテストだってそうだろ

460 :デフォルトの名無しさん:2013/11/11(月) 01:54:18.06
なぜ詭弁多い

461 :デフォルトの名無しさん:2013/11/11(月) 01:55:56.72
テストはバグがないことを保証するものだな

462 :デフォルトの名無しさん:2013/11/11(月) 01:57:48.19
学習にデバッガを使うのは良いんだけど、製品にデバッガを使うのは
プロ失格だと思います。
お金をもらうことの重みをかみしめてほしいです。

463 :デフォルトの名無しさん:2013/11/11(月) 02:02:22.36
デバッガ→バグがあることを宣言する
テスト→バグがないことを保証する

どちらがお客様のためになるか一目瞭然

464 :デフォルトの名無しさん:2013/11/11(月) 02:07:53.54
一人の声の大きいバカがコミュニティを狂わす良い例ですね

465 :デフォルトの名無しさん:2013/11/11(月) 02:11:52.83
発注するときはデバッガを使うか聞いたほうがいいね
使うなら別のとこに発注したほうがいい

466 :デフォルトの名無しさん:2013/11/11(月) 02:18:43.36
プロは現状で最適な方法を選択する。バカがアホな方法をやってたら勝手に自滅しろと思うのみ。

467 :デフォルトの名無しさん:2013/11/11(月) 02:20:28.32
勝手に自滅とは、デスマーチは無能もしくは自己過信ゆえの自業自得ということだ。

468 :デフォルトの名無しさん:2013/11/11(月) 02:43:14.33
テストをないがしろにするとデスマーチが起こる。
まずデバッガを完全に撤廃し、テストを完全に行う。
これが大事。

469 :デフォルトの名無しさん:2013/11/11(月) 02:50:01.29
このネタもう飽きた。

470 :デフォルトの名無しさん:2013/11/11(月) 03:04:15.24
動的型で型チェックしてたらテスト必要になるの当たり前だよね
どういう根拠で静的型と変わらないと言ってるの?

471 :デフォルトの名無しさん:2013/11/11(月) 03:31:45.35
神を疑うのですか?

472 :デフォルトの名無しさん:2013/11/11(月) 03:35:17.96
神という言葉を脅し文句として愛用するJS信者ですかw

473 :デフォルトの名無しさん:2013/11/11(月) 04:23:00.05
まずUbuntuをインストールする技術を身に着けたほうが良いのでは?

474 :デフォルトの名無しさん:2013/11/11(月) 05:03:18.67
?

でも開発機にOSXやUbuntu使っているのもよく見るようになったなぁ。
Cygwin使うとしてもデプロイターゲットがLinux等のUnix系だとWindowsは無駄に不便だし。

475 :デフォルトの名無しさん:2013/11/11(月) 08:03:48.77
バグがあるものを出荷してこそプロ
バグフリーに出来るのは競争力皆無のおもちゃを作るときだけ

476 :デフォルトの名無しさん:2013/11/11(月) 08:51:16.28
むしろバグはあるものとしてアップデートで対応する
一度作ったらあとは極力知らんぷりよりマシ

477 :デフォルトの名無しさん:2013/11/11(月) 21:49:03.13
だからウェブアプリは適当にリリースしても
すぐに更新できるから動的言語に向いている

478 :デフォルトの名無しさん:2013/11/11(月) 21:59:41.66
リリースのしやすさは関係ないだろw
「Web環境下での」開発効率の面では動的言語が優秀だろうが

479 :デフォルトの名無しさん:2013/11/11(月) 22:06:56.26
>>478
違う違う。バグがあってもすぐに直せるから
そこまでテストに時間かけなくていいってこと。

480 :デフォルトの名無しさん:2013/11/11(月) 22:09:24.13
それは分かってるが
それはWebアプリの性質であって
直接言語とは関係しないだろうに

481 :デフォルトの名無しさん:2013/11/11(月) 22:18:29.38
> 「Web環境下での」開発効率の面では動的言語が優秀だろうが

それは分かってるが
それはWebアプリの性質であって
直接言語とは関係しないだろうに

482 :デフォルトの名無しさん:2013/11/11(月) 22:22:28.03
>>480
いや関係有るよ。

動的言語の場合、エラーがあっても
実行していなければ、エラーにならない。

ファイルを更新するときは、
実は削除されて再作成されるわけだけど、
短い時間とはいえ、ファイルが削除されたタイミングに
アクセスされるとエラーになる。

でも、多少エラーになってもいいじゃんって
適当にファイル更新するでしょ?
こういう風に適当に手抜きできるのが動的言語
だからエラーは多いが、エラーに成った時になおせばいいんだよ。そんなの。

483 :デフォルトの名無しさん:2013/11/11(月) 22:26:47.38
あーWebアプリっていうのをサイトに近い複数の要素の集合体と捉えてたのね

484 :デフォルトの名無しさん:2013/11/11(月) 22:33:28.79
>>480,481
横レスだけど、関係あると思うよ

そのWebサービスをユーザに近いフロントエンドと
情報資源に近いバックエンドの2つに分けて考えてみる
まずフロントエンド側はユーザと直接的に接するから、
仕様の改善や変更の要求が頻繁に起きやすい
逆にバックエンドはビジネスルールをモデル化したものだから、
その仕様は比較的に安定している

これらの背景を前提にすれば、フロントエンド側の開発には、
簡潔な記述で素早く開発ができる、すなわち開発効率が良い
動的型付け言語が適している
それに対してバックエンド側の開発には、コード品質が高く
実行効率(性能)の良い静的型付け言語が適している
.....のではないかと

485 :デフォルトの名無しさん:2013/11/11(月) 22:47:49.22
そこでバックエンドのJava APIを直接叩ける動的言語Groovyの出番ですよ!

デプロイの遅さだけはどうにもならんけれどもな!

486 :デフォルトの名無しさん:2013/11/11(月) 23:03:04.55
Java8でラムダ式やStream APIが入ってもScalaのがいいんか?

487 :デフォルトの名無しさん:2013/11/12(火) 00:17:51.50
>http://d.hatena.ne.jp/perlcodesample/20130227/1361928810
> 関数のオーバーロードが不要になる
>
> sub sum {
> my $value = shift;
>
> if ($valueがA型なら) {
>
> }
> elsif ($valueがB型なら) {
>
> }
> }
ネタサイトからの引用で申し訳ないが
動的厨はこういう記述に疑問を感じないの?
オーバーロードしなくていい!とか思っちゃうの?

488 :デフォルトの名無しさん:2013/11/12(火) 00:44:03.69
>>487
柔軟だぞ。

引数の数が変わった時とか、
引数をずらすことで
第一引数を省略できたりする。

489 :デフォルトの名無しさん:2013/11/12(火) 00:58:05.85
@multimethod(A)
def sum(value):
    # ... code for A

@multimethod(B)
def sum(value):
    # ... code for B

490 :デフォルトの名無しさん:2013/11/12(火) 01:02:49.15
>>489
Cという型が来た場合はどうなるの?

491 :デフォルトの名無しさん:2013/11/12(火) 01:06:44.95
>>487
手続き型では、そういった「魔術的」なコードになる
これがオブジェクト指向だと、
・データ型はオブジェクトのクラスである
・オブジェクトに対する操作は(手続き/関数/演算子ではなく)
 メッセージ(もしくはメソッド)という識別子(セレクタ)である
から、以下のように自然なコードが書ける

class A
  def sum(other_value); ....; end
end

class B
  def sum(other_value); ....; end
end

つまり、メッセージ sum(x) をオブジェクトAが受信したのか、
それともオブジェクトBが受信したのかという違いでしかない
>>316も参照の事)

492 :デフォルトの名無しさん:2013/11/12(火) 01:10:29.65
>>491
オーバーロードも知らない人は
でてこないでくれる?

493 :デフォルトの名無しさん:2013/11/12(火) 01:17:27.11
>>491

sum(Integer, Integer) -> Integer
sum(Float, Float) -> Float
sum(Float, Integer) -> Float
sum(Integer, Float) -> Float
sum(Float, Cat) -> TypeError
sum(Drink, IceCream) -> Float

的なのはどう表現するの?

494 :デフォルトの名無しさん:2013/11/12(火) 01:20:14.53
>>491
それだけだとオーバーロードが要らない例にならないのでは?
その例だとother_valueはclass Aしか想定してないでしょ?

495 :デフォルトの名無しさん:2013/11/12(火) 01:21:11.50
@multimethod(A)
def sum(value):
# ... code for A

@multimethod(B)
def sum(value):
# ... code for B


これを改良するとこうなる

def sum(A value):
# ... code for A

def sum(B value):
# ... code for B

496 :デフォルトの名無しさん:2013/11/12(火) 01:24:48.16
multimethodのようなものをみると
やっぱり、変数に型があったほうがいいと思う。

たとえ、実行時に動的にその型を解釈するとしても
変数に型があったほうがいいと思う。

497 :デフォルトの名無しさん:2013/11/12(火) 01:29:18.46
>>493
class Integer
  def sum(y); self + y.to_i; end
  def to_i; self; end
  def to_f; Convert.integer_to_float(self); end
end

class Float
  class sum(y); self + y.to_f; end
  def to_i; Convert.float_to_integer(self); end
  def to_f; self; end
end

aFloat.sum aCat # ==> モジュール Convert でTypeErrorを検出
aDrink.sum aIceCream # ==> クラス Drink におけるsumの定義に従う

498 :デフォルトの名無しさん:2013/11/12(火) 01:30:26.11
>>497
お前、間違ってるぞw

499 :デフォルトの名無しさん:2013/11/12(火) 01:31:16.44
>>492
ここは2chだから、誰にも自由に発言できる権利がある

500 :デフォルトの名無しさん:2013/11/12(火) 01:31:51.03
>>499
発言して恥をかく権利ですか?w

501 :デフォルトの名無しさん:2013/11/12(火) 01:34:50.33
>>500
自己紹介乙w

502 :デフォルトの名無しさん:2013/11/12(火) 01:35:29.18
自己紹介? 発言したのは俺じゃないけど?

503 :デフォルトの名無しさん:2013/11/12(火) 01:37:08.40
俺だよ

504 :デフォルトの名無しさん:2013/11/12(火) 01:50:36.87
オーバーロードって要するに型から関数を推論してる機能だから
動的型付けでも普通にそれぞれの型のメソッドを呼べばいいだけの話なんだが
動的に型を判断したらそりゃ多重ディスパッチになるよ

505 :デフォルトの名無しさん:2013/11/12(火) 01:56:44.67
Drink型のcoraオブジェクトにIceCream型のvanillaIceオブジェクトをsumしたら
mazeruとかsizumeruとかgetMawariNoShariShariShitaTokoroメソッドを定義した
Floatインターフェイスをmix-inして欲しいのだが。

>>497の方法だと何をsumしてもIntegerはIntegerだしFloatはFloatだし同じ方法
だとDrinkだっていつまでたってもDrinkだと思う。

506 :デフォルトの名無しさん:2013/11/12(火) 02:24:23.03
>>504の説明によると
動的っていうのは、引数によって同じメソッドに別名を与えないといけないのか。
それは不便。

507 :デフォルトの名無しさん:2013/11/12(火) 02:25:00.84
100年くらい後退した気がするね。
気がするね。

508 :デフォルトの名無しさん:2013/11/12(火) 02:43:49.75
OCamlディスってんの?

509 :デフォルトの名無しさん:2013/11/12(火) 02:48:59.64
OCaml凄いってみんな言ってるからちょっと興味あるよ。
高橋真奈著やさしいOCamlが出たらやってみるよ。

510 :デフォルトの名無しさん:2013/11/12(火) 05:48:26.90
>>506
んなわきゃないw

511 :デフォルトの名無しさん:2013/11/12(火) 07:40:38.15
>>495
Python3なら、こういうのも可

with multimethod:
    def sum(value : A):
        # ... code for A

    def sum(value : B):
        # ... code for B

512 :デフォルトの名無しさん:2013/11/12(火) 08:02:57.99
多重メソッドの有用性がわからん
そんなのを使うことになるときは設計を疑った方がいい

513 :デフォルトの名無しさん:2013/11/12(火) 08:19:10.91
def sum(A a){
 // Code for A
 ...
}

def sum(B b){
 // Code for B
 ...
}

A v1 = new A()
sum(v1) // 単一ディスパッチ

def v2 = new B()
sum(v2) // 多重ディスパッチ

514 :デフォルトの名無しさん:2013/11/12(火) 09:37:28.17
v1.sum
v2.sum
じゃいやなの?

515 :デフォルトの名無しさん:2013/11/12(火) 15:47:48.60
class C{
 def op(A a2, A a2){
  // Code for op(A,A)
  ...
 }

 def op(A a, B b){
  // Code for op(A, B)
  ...
 }
 ...

C = new C()

A a = ...
B b = ...
c.op(a, b) // 単一ディスパッチ

def v1 = ...
def v2 = ...
c.op(v1, v2) //多重ディスパッチ

516 :デフォルトの名無しさん:2013/11/12(火) 15:52:10.06
Perl6もPython3も全然普及してない

517 :デフォルトの名無しさん:2013/11/12(火) 17:10:23.08
>>514
これって例えば後からよりルートに近いクラスで
メソッド定義かぶるように追加した場合の挙動とかってどうなるの?

518 :デフォルトの名無しさん:2013/11/12(火) 17:19:27.34
>>514
単に一引数の多重ディスパッチがオブジェクトの引数なしメソッドの呼び出しに
置き換えられるというだけであって、引数が増えると結局一緒。

519 :デフォルトの名無しさん:2013/11/12(火) 18:34:55.62
>>518
>>517

520 :デフォルトの名無しさん:2013/11/12(火) 19:11:41.78
>>513,515
何の言語か知らんけど型推論してるだけのように見えるんだが

521 :デフォルトの名無しさん:2013/11/12(火) 19:32:04.47
動的に上書きなんかをしてこその多重メソッドで
そうじゃないのならただのオーバーライドだもんげ

522 :デフォルトの名無しさん:2013/11/12(火) 19:46:55.76
var length = o.getLength() より
int length = o.getLength() のがどう考えても分かりやすい。
だが var = "文字列です。" だと別に可読性は落ちない。
型推論は便利だがコーディングルールが必要だ

523 :デフォルトの名無しさん:2013/11/12(火) 19:51:55.90
>>520
Groovy。基本的に型無し(def)は実行時に型判定して動的ディスパッチする。
と、ここまで書いて型指定したときには効率良く単一ディスパッチしてくれたかイマイチ
思い出せないことに気がついたw

524 :デフォルトの名無しさん:2013/11/12(火) 19:52:28.00
変数名入れ忘れたが var msg = "文字列です。" ってことで

525 :デフォルトの名無しさん:2013/11/12(火) 20:21:58.90
>>523
http://ideone.com/Vau4dl
今試してみたんだけど↑の結果って型指定しても動的にディスパッチしてるっぽくない?
Groovy初めてだからやり方あってるか知らんけど

526 :デフォルトの名無しさん:2013/11/12(火) 21:33:27.06
>>525
しまった〜、やぱりそうか常に動的ディスパッチか。

527 :デフォルトの名無しさん:2013/11/13(水) 19:29:50.43
型指定しても継承ツリーの中で一番近いクラスを使われるっぽいね
http://ideone.com/DieNkp
http://ideone.com/74jNvk
http://ideone.com/jP5xOy

528 :デフォルトの名無しさん:2013/11/13(水) 20:28:23.42
>>527
今更ながらそのあたりの詳細に気がつかされる程度にはあんまり意識して動的ディスパッチを
活用していない事を実感した。

529 :デフォルトの名無しさん:2013/11/13(水) 20:59:26.31
なんで?
じゃあ型に合わせた関数を呼ぶにはどうしたらいいの?
型ごとに別の名前を割り当てるの?

530 :デフォルトの名無しさん:2013/11/13(水) 21:03:53.81
メソッドでええやん

531 :デフォルトの名無しさん:2013/11/13(水) 21:58:50.42
そこまで明確に呼び分けたいならちゃんと名前分けたほうがいいだろ

532 :デフォルトの名無しさん:2013/11/14(木) 01:06:57.10
収まりが悪くなるんだよな
getDateById()
getDateByIdAndName()
getDateByIdAndNameAndStatus()
とか、これをそれぞれgetUnixTimeByXX()みたいなのも追加しようと思うとさらに増えていく

533 :デフォルトの名無しさん:2013/11/14(木) 01:27:29.24
>>532
その辺はメソッドミッシングとかで対応すべき事かな。

534 :デフォルトの名無しさん:2013/11/14(木) 02:52:21.37
>>532-533
あほかw そんな名前にするからいかんのだろ。

メソッドは一つgetData()、引数に条件を入れればいいじゃないか。
条件をオブジェクトにした、条件オブジェクトでもいいし、
SQLのような簡単な条件文字列を作ってもいい。

条件オブジェクトと条件文字列の両方に対応するなら
オーバーロードを使えるな。

型と条件をごっちゃにしてはだめだ。

535 :デフォルトの名無しさん:2013/11/14(木) 03:40:28.77
メソッド内に分岐処理を書くと、コードを読まないとそのメソッドは使えなくなる
IDEのインテリセンスが効かなくなる
メソッドオーバーロードがない言語はこういう問題をスマートに解決することが出来ない

536 :デフォルトの名無しさん:2013/11/14(木) 08:02:29.14
>>532

getDate(id=x)
getDate(id=x, name=y)
getDate(id=x, name=y, status=z)

必要なのはキーワード引数とデフォルト引数

537 :デフォルトの名無しさん:2013/11/14(木) 09:52:09.54
多重継承したクラスや複数のインターフェイスを実装したクラスの多重ディスパッチってどういう振る舞いになるの?

538 :デフォルトの名無しさん:2013/11/14(木) 09:53:05.57
キーワード引数が無い言語しか使ったことないと
そういう発想が出てこないんだよね
Jから始まる言語とか

539 :デフォルトの名無しさん:2013/11/14(木) 10:53:57.50
オブジェクトで渡せばキーワード引数と同じことじゃん?

540 :デフォルトの名無しさん:2013/11/14(木) 11:18:57.43
読みやすさが全然違うよ
ただしハッシュリテラルがあれば話は別

541 :デフォルトの名無しさん:2013/11/14(木) 11:51:03.63
getDate(id=x, name=y, status=z)
これだと
id=x, name=y, status=z
getDate(id, name, status)
なのと紛らわしい

せめて
getDate(id=>x / name=>y / status=>z)
みたいな方がいいのではないか

542 :デフォルトの名無しさん:2013/11/14(木) 11:58:15.81
メソッドオーバロード出来ない場合は、メソッド内に分岐処理を書くか、メソッド名を少しずつ変えてたくさんのメソッドを書くか、どっちかしかない
C#は名前つき引数もあるしメソッドオーバーロードもあるけど、引数を連想配列で指定すると補完が効かなくなる
シグネチャだけで機能を判断出来るメソッドオーバーロードに比べて劣ってる

543 :デフォルトの名無しさん:2013/11/14(木) 12:02:42.94
これまでメソッドオーバーライドが便利だという例も出てないのに

544 :デフォルトの名無しさん:2013/11/14(木) 12:08:06.44
>>541

  x getDateByName: y status: z.

または

  x.getDate name: y, status: z

がリーダブルだと思う

545 :デフォルトの名無しさん:2013/11/14(木) 12:12:55.23
Perl6は名前つき引数もメソッドオーバーロードも出来て仮引数の型指定も出来るなど非常に優れてる
まともにリリースされることなく終わりそうだけど

546 :デフォルトの名無しさん:2013/11/14(木) 12:18:20.14
>>544
コロンは一瞬思ったけど型指定と紛らわしくね
それならいっそハッシュリテラル使うのがいいと思うけど

547 :デフォルトの名無しさん:2013/11/14(木) 12:32:46.09
JavaScript(ES6)だとこうか

add = ({x, y}) => x + y

num1 = 10, num2 = 20

add({x: num1, y: num2}) //30

548 :デフォルトの名無しさん:2013/11/14(木) 13:56:54.31
ハッシュリテラルと違って、本物のキーワード引数は補完が効く

549 :デフォルトの名無しさん:2013/11/14(木) 14:10:25.16
それは場合によりけり

550 :デフォルトの名無しさん:2013/11/14(木) 14:12:22.41
そりゃウンコなエディタやIDEじゃ無理だわな

551 :デフォルトの名無しさん:2013/11/14(木) 14:55:19.83
優秀なのならリテラルでも効くんじゃね
コンピュートキーじゃない場合は

552 :デフォルトの名無しさん:2013/11/14(木) 15:08:43.27
変数の三原則って一般的な用語?
静的言語だけの用語かなぁ

553 :デフォルトの名無しさん:2013/11/14(木) 15:15:20.67
静的言語であっても用語自体は一般的とまでは言えないな
内容については大方適応できるでしょう

554 :デフォルトの名無しさん:2013/11/14(木) 15:28:22.78
例えばidとnameが共にユニークでどちらかだけでも一意にデータを取り出せるから、引数にidとnameを同時に指定するようなメソッドの使い方をさせたくないとか
そういうのは引数をハッシュにするとメソッドの中で例外処理書くしかない

555 :デフォルトの名無しさん:2013/11/14(木) 15:30:28.14
例えば日付を渡したら翌日の日付が返ってくるメソッドがあるとして、intのunix timeを引数で渡したら返り値はintで、dateオブジェクトを引数で渡したら返り値はdateオブジェクトで返すようにしたいとか
メソッドオーバーロードにしても名前つき引数にしても、ないとプログラムが書けないわけではないが、あれば便利に使える

556 :デフォルトの名無しさん:2013/11/14(木) 16:06:46.54
そういう時はDate->Date関数を定義しておいて
ラップするので十分いいし分かりやすいよ
例えばこんな感じで


function nextDate(x) {

switch (x.constructor) {
case Date: return NextDate(x)
case Number: return NextDate(new Date(x)).getTime()
case String: return NextDate(new Date(x)).toString()
default: throw "type err"
}

function NextDate(date) {......return date2}

}


オーバーライド等が活きるときはもっと異なる処理をさせたいときdと思う

557 :デフォルトの名無しさん:2013/11/14(木) 16:10:26.78
>>544
2つめはGroovyは出来るな。書いてあるとおりカッコも省略できる。
x.getDate([name:y, status:z])という形で名前付き引数では無くMap渡しになるけど。

class X{ def getDate(args){print args}}

def x = new X(), y = "sampleName", z = "sampleDate"
x.getDate name: y, status: z

-> [name:sampleName, status:sampleDate]

558 :デフォルトの名無しさん:2013/11/14(木) 16:51:59.66
こんな感じか

function nextDate(x) {

switch (x.constructor) {
case Date: return NextDate(x)
case Number: return NextDate(x).getTime()
case String: return NextDate(x).toString()
default: throw "type err"
}

function NextDate(x) {
var date = new Date(x)
date.setDate(date.getDate() + 1)
return date
}

}

559 :デフォルトの名無しさん:2013/11/14(木) 16:53:27.70
VS

function nextDate(d:Date) {
return $NextDate(d)
}
function nextDate(n:Number) {
return $NextDate(n).getTime()
}
function nextDate(s:String) {
return $NextDate(s).toString()
}

function $NextDate(x:Any) {
var date = new Date(x)
date.setDate(date.getDate() + 1)
return date
}

560 :デフォルトの名無しさん:2013/11/14(木) 17:05:13.00
メソッドオーバーロードについて書いたけど、オーバーライドについては知らない

561 :デフォルトの名無しさん:2013/11/14(木) 17:34:17.60
言葉尻大戦がまた始まりそうな予感……!!

562 :デフォルトの名無しさん:2013/11/14(木) 17:42:43.21
何度も何度も間違えてるからな
それも明確に意味が違うのに

563 :デフォルトの名無しさん:2013/11/14(木) 18:49:36.48
どう違うのか説明よろ

564 :デフォルトの名無しさん:2013/11/14(木) 19:01:23.58
引数の型で分岐するのは動的型でも普通に書けるけど、
戻り値の型でオーバーロード出来るのは静的型だけだな

565 :デフォルトの名無しさん:2013/11/14(木) 19:05:31.69
知らんけど、オーバーロードと言えば同じ名前でシグネチャが違うメソッドができる。
オーバーライドと言えば、継承などで上書きできる。
みたいな感じじゃないの?知らんけど。

566 :デフォルトの名無しさん:2013/11/14(木) 19:11:06.65
普通に書けないよ
引数を調べてifで処理を別けないといけない、もしくは別のメソッドを作るか
どっちにしてもダサい
返り値の型で処理を変えるのはPerl5なら不完全だけど出来る
今wantarrayを積極的に使ってる人は少ない印象だけど

567 :デフォルトの名無しさん:2013/11/14(木) 19:20:32.48
>>558がダサいとは思わないけどな
>>559だと$NextDateの頭に$がついてるのもそういう理由だろうけどスコープの手間が掛かるし

568 :デフォルトの名無しさん:2013/11/14(木) 19:22:09.03
>>566
マルチメソッドが無いゴミ言語の話?

569 :デフォルトの名無しさん:2013/11/14(木) 19:23:53.45
別名付けるのサボるだけの機能が過大評価されすぎでしょ
実装量が減るわけでも無いのに

570 :デフォルトの名無しさん:2013/11/14(木) 19:27:00.90
重要だと思うのはifやswitchが減ること。
ifのネストおばけみたいなプログラムをよくみかけるが、
そういう繁雑さから完全開放された経験がない人にはわからない境地。

571 :デフォルトの名無しさん:2013/11/14(木) 19:29:47.74
え?ほんとにできないの?
なんで?
自分で調べるの?

572 :デフォルトの名無しさん:2013/11/14(木) 19:32:46.82
もしかして演算子のオーバーロードもできないとかある?

文字列 + 文字列
整数 + 整数
整数 + 文字列
文字列 + MyClass

こういうのとかどうするの?

573 :デフォルトの名無しさん:2013/11/14(木) 19:39:03.36
動的でも出来るよ
JSみたいな糞言語じゃ無理だけど

574 :デフォルトの名無しさん:2013/11/14(木) 19:39:44.64
JSだとtoStringとvalueOfである程度いける

575 :デフォルトの名無しさん:2013/11/14(木) 19:58:09.81
>>572
SmalltalkやRubyとかだと
オーバーロードは無いけどオーバーライドする事で同じ型の演算は普通に出来る
単一のメソッドで複数の型を扱う場合はメソッド内で分岐させるか別名を付ける必要がある
ていうか整数+文字列って酷いな

576 :デフォルトの名無しさん:2013/11/14(木) 20:02:40.49
数値 + 文字列は論外だけど、
ベクトル + 数値リテラルとかは出来ると便利よね

577 :デフォルトの名無しさん:2013/11/14(木) 20:05:54.39
頭が固い
あらゆる記号がオーバーロード出来ないといけない

578 :デフォルトの名無しさん:2013/11/14(木) 20:07:48.10
出来るからといって実際やるかどうかは別だがな
整数+文字列は醜い
まあ、デフォルトでこうなってるゴミ言語も存在するが

579 :デフォルトの名無しさん:2013/11/14(木) 20:08:17.67
極力ifやswitchはなくすべきで、よほどパラメーターの数や組み合わせが多くない限り、
ハッシュでパラメーター全部引き取って中で条件分岐させる巨大なメソッド作るぐらいなら、必要なパラメーターだけ引き取る小さなメソッドを複数作った方がマシ

580 :デフォルトの名無しさん:2013/11/14(木) 20:11:34.26
お前の中ではな

581 :デフォルトの名無しさん:2013/11/14(木) 20:55:48.16
演算子オーバロードは黒魔術的だからな

582 :デフォルトの名無しさん:2013/11/14(木) 21:01:48.58
>>536

なんか話がずれてるけど、
検索の条件は一つのオブジェクトとして渡すべきだよ。

そうすれば、条件オブジェクトからSQLのWHERE区に変換するという
メソッドを作るだろうし、そのテストも簡単になる。

これをキーワード引数にしてバラバラに渡すのはセンスが悪すぎる。
いくつ引数作らないといけないのさ?

583 :デフォルトの名無しさん:2013/11/14(木) 21:18:13.47
>>575
> 整数+文字列って酷いな

すまん…^^; Squeak Smalltalk だと

3 + '4' "=> 7 "


ちなみに元祖wダブルディスパッチで実現されている。

SmallInteger >> + aNumber
 <primitive: 1> "失敗すると次行を実行"
 ^ super + aNumber

Integer >> + aNumber
 aNumber isInteger ifTrue:
  [self negative == aNumber negative
   ifTrue: [^ (self digitAdd: aNumber) normalize]
   ifFalse: [^ self digitSubtract: aNumber]].
 ^ aNumber adaptToInteger: self andSend: #+

Object >> adaptToInteger: rcvr andSend: selector
 ^ self adaptToNumber: rcvr andSend: selector

String >> adaptToNumber: rcvr andSend: selector
 ^ rcvr perform: selector with: self asNumber

584 :デフォルトの名無しさん:2013/11/14(木) 21:44:33.17
Groovy起動遅すぎて動的言語としては落第だと思うの

585 :デフォルトの名無しさん:2013/11/14(木) 21:56:39.38
>>584
それは言語として落第なのであって動的静的は関係ないw

まぁ実際もっと起動が速くなってほしい。
ワンライナーとしてサクサク使えない言語はどうしても普段使いの道具箱から外れてしまう。

586 :デフォルトの名無しさん:2013/11/14(木) 23:14:35.93
>>582
可変長キーワード引数というのもあってだな

587 :デフォルトの名無しさん:2013/11/14(木) 23:15:44.27
>>586
そういう問題じゃないから

588 :デフォルトの名無しさん:2013/11/15(金) 01:47:44.53
可変長キーワードはひとつのオブジェクトとして渡るっての
ホント無知だな

589 :デフォルトの名無しさん:2013/11/15(金) 01:48:51.72
低能は自分が使ってる言語の機能の枠内でしか
思考できないってのが良く分かるな

590 :デフォルトの名無しさん:2013/11/15(金) 02:02:21.37
ぶっちゃけリテラルの皮があるかないか程度の違いしか無いってことでOK?

591 :デフォルトの名無しさん:2013/11/15(金) 07:34:01.06
>>588
順序性ないし重複も許されないけどな

592 :デフォルトの名無しさん:2013/11/15(金) 10:42:16.56
順序性を持って省略したければリストで渡せばいいんじゃね

593 :デフォルトの名無しさん:2013/11/15(金) 12:39:12.46
>>584
Gradleとか常駐オプション(--daemon)標準装備してるから
スタンドアローンでつかうならそういうのが常套なんかも。

594 :デフォルトの名無しさん:2013/11/15(金) 15:35:34.34
>>593
Gradleはインクリメンタルビルド前提だから常套以前の問題だな

595 :デフォルトの名無しさん:2013/11/15(金) 17:43:38.48
性的種付け言語を教えてください。

596 :デフォルトの名無しさん:2013/11/15(金) 18:40:59.14
sex言語があります

597 :デフォルトの名無しさん:2013/11/15(金) 18:46:10.74
sexpね。ああ、Lispか

598 :デフォルトの名無しさん:2013/11/15(金) 22:51:01.49
>>591-592
Pythonの def func(*args, **keywords) は意外と理にかなってるのか

599 :デフォルトの名無しさん:2013/11/16(土) 08:18:04.52
変に記法作らなくてもハッシュやリストで渡して受け取る方は
分割代入ですよってする方が美しくなかろうか

600 :デフォルトの名無しさん:2013/11/16(土) 08:32:15.32
[解釈]
要するにJavaScriptのやり方が美しいのです最高なのです他の方法は変なのです

601 :デフォルトの名無しさん:2013/11/16(土) 09:44:57.81
ハッシュで渡す方法って、変なキーで渡ってきたときのエラー処理を
自前で書く必要があるの?

602 :デフォルトの名無しさん:2013/11/16(土) 09:52:07.71
>>601
その為にPerlではHash::Utilが
標準モジュールとして提供されてるんだよ。

Hash::Utilでロックしておけば、キーの追加をしたり、
本来あるべきキーがなければ参照した時にエラーになる。

多分他の言語にも似たようなモジュールあるでしょ?
Perlなめるな。

603 :デフォルトの名無しさん:2013/11/16(土) 10:11:44.62
わざわざ lock 処理を自前で書くのね
あーウンコすぎて目眩がする

604 :デフォルトの名無しさん:2013/11/16(土) 10:25:51.16
>>603
え? 手間変わらないだろ。
引数を書くのも、キーを羅列するのも。

あえて言うのなら、lock_keysという関数の分のタイプ量だけだ。
わずか10文字程度にお前なに時間かけてるんだよw

605 :デフォルトの名無しさん:2013/11/16(土) 10:52:29.37
add(x=0, y=0, z=0)  に相当する関数を
キーワード間違ったらエラーになるようにPerlで書くとどうなるの?

606 :デフォルトの名無しさん:2013/11/16(土) 11:13:19.05
別に何もしなくても変なキーで渡ってきたら値が不正になるんだからどうでもいいと思うが

607 :デフォルトの名無しさん:2013/11/16(土) 11:14:44.32
>キーワード間違ったらエラーになる
違うこと=間違いと思うのは脳みそ固いね、静的脳だわ

608 :デフォルトの名無しさん:2013/11/16(土) 11:18:12.71
>>606
デフォルト引数も指定してたら
間違った事に気がつかないでしょ

609 :デフォルトの名無しさん:2013/11/16(土) 11:32:17.16
は?分割代入時に!で必須項目の指定出来るでしょ

610 :デフォルトの名無しさん:2013/11/16(土) 11:42:23.68
期待してないキーが来たらエラーにしたいってことでは?
例えばa=0を期待しててbってのが来た時にどうするか
オブジェクトだと難しいよね
そもそもそれをエラーにしたいって考えが良くない気もするけど

611 :デフォルトの名無しさん:2013/11/16(土) 11:43:09.20
ここまで>>605のコードなし

612 :デフォルトの名無しさん:2013/11/16(土) 12:03:22.29
>>605

sub add {
 my %params = @_;
 lock_keys(%params, qw(x y z));

}
add(a => 1, x => 1);

実行結果
Hash has key 'a' which is not in the new key set at a.pl line 6.

デフォルト値あり
sub add {
 my %params = (x => 0, y => 0, z => 0);
 lock_keys_plus(%params);
 %params = (%params, @_);
 warn Dumper(\%params);
}
add(x => 1);

実行結果
$VAR1 = {
 'z' => 0,
 'y' => 0,
 'x' => 1
};

613 :デフォルトの名無しさん:2013/11/16(土) 12:14:13.97
可読性が>>605より大幅に劣っているように見えるが、
そもそもPerlに可読性を求めるのが間違いとも言える

614 :デフォルトの名無しさん:2013/11/16(土) 12:23:00.80
>>613
自分でヘルパー関数作れば?
用意されなきゃ何も出来ない、脳無しなの?

615 :デフォルトの名無しさん:2013/11/16(土) 12:24:38.16
自作のヘルパー関数を使えば可読性が上がるの?

616 :デフォルトの名無しさん:2013/11/16(土) 12:25:54.73
確かに
最初緩くて気軽で良くて
厳密さを取りたい時にはちょいと自作すればいいよね
まあその程度の問題で別にどうというほどのことでもないね
この話は終了

617 :デフォルトの名無しさん:2013/11/16(土) 12:27:53.85
この場合、緩いことに何のメリットも無いんですが

618 :デフォルトの名無しさん:2013/11/16(土) 12:28:02.61
>>615
上がるかどうかではなく、自分の力で上げるんだよ。
それが出来ない奴が、本当の脳無し。

sub add {
 my $params = params({x => 0, y => 0, z => 0}, @_);
 warn Dumper($params);
}
add(x => 1);




# こんくらい自分でモジュール作れ
sub params {
 my $def = shift;
 lock_keys_plus(%$def);
 %$def = (%$def, @_);
 return $def;
}

619 :デフォルトの名無しさん:2013/11/16(土) 12:30:07.22
ところで、その関数で add(1, 2, 3) って普通の関数のようにも呼び出せるの?

620 :デフォルトの名無しさん:2013/11/16(土) 12:31:19.85
呼び出せるように自分の力でするんだよ。ほんと脳無しだなw

621 :デフォルトの名無しさん:2013/11/16(土) 12:31:47.20
じゃあ、そのコード貼ってみて

622 :デフォルトの名無しさん:2013/11/16(土) 12:32:20.04
sub add {
 my $params = params([x => 0, y => 0, z => 0], @_);
 warn Dumper($params);
}
add(1, 2, 3);


自分の力でやってみな?

623 :デフォルトの名無しさん:2013/11/16(土) 12:32:53.85
あれ?できないの?逃げちゃう?

624 :デフォルトの名無しさん:2013/11/16(土) 12:34:32.16
いや、これできるだろ?

あとはparamsの第一引数をみて
その順番通りにハッシュを作るって
値を入れるだけだ。

625 :デフォルトの名無しさん:2013/11/16(土) 12:38:33.14
あーやっぱりウンコですわ
そんなの自作ライブラリでやってるの?w

626 :デフォルトの名無しさん:2013/11/16(土) 12:43:03.34
add(1, 2, x = 3) みたいなのは可能?

627 :デフォルトの名無しさん:2013/11/16(土) 12:47:28.28
>>625
自慢気に話してるが、それって
自作関数を作るわずか数分の差しかないってことだよね?

ほらできた。

sub params {
 my $kvlist = shift;
 my $def = {};
 $def->{$_->[0]} = shift // $_->[1] foreach( pairs @$kvlist);

 lock_keys_plus(%$def);
 return $def;
}

第一引数の型を見て処理を変えればいいだけだから
>>618を混在も可能

628 :デフォルトの名無しさん:2013/11/16(土) 12:49:42.10
>>626
こんな引数になるだろうね。
add(1, 2, {x => 3, y => 4})

629 :デフォルトの名無しさん:2013/11/16(土) 12:53:01.89
そんな基本的な処理を各自が自作ライブラリでやってたら
第三者にとっての可読性は悪くなるよ、これはマジで
書いた本人は良いだろうけど

Perlのコードなんて、どうせ書いたヤツ以外読めないから良いのか

630 :デフォルトの名無しさん:2013/11/16(土) 12:55:15.47
あぁ、この程度の他人が書いた関数を理解するのに
時間がかかる人なのねw

仕事では他人が書いた、もっと長くてドキュメントもないような
糞コードだって理解しなくちゃならないんだよ。

基礎能力が圧倒的に違いすぎる。

631 :デフォルトの名無しさん:2013/11/16(土) 12:57:00.75
>>628
ごめん、思い付きで質問したけど、
この場合xに1が入るべきか3が入るべきか微妙だね

632 :デフォルトの名無しさん:2013/11/16(土) 12:57:24.38
これCPANに上げればよかったかな(苦笑)
まあ誰か勝手にパクってやってくれ。
と俺が言っても俺が書いたって証拠もないけどなw

633 :デフォルトの名無しさん:2013/11/16(土) 12:58:05.37
CPANにゴミを突っ込むのはヤメろ
ただでさえゴミの山なんだから

634 :デフォルトの名無しさん:2013/11/16(土) 12:58:47.95
>>631
> この場合xに1が入るべきか3が入るべきか微妙だね

そんなもん、仕様で決めればいいことだよ。
後に書いたのが有効になるでも
前に書いたのが有効になるでも
エラーになるでも、一番いい方法を考えて決めればいい。

635 :デフォルトの名無しさん:2013/11/16(土) 12:59:59.85
>>634
それぞれ自作ライブラリ毎で仕様が違うんですよね?
で、違うライブラリの関数呼び出すときは毎回仕様をチェックするんですよね?

636 :デフォルトの名無しさん:2013/11/16(土) 13:03:04.60
>>633
それ他の言語でも同じですわwww
PerlもRubyもJS(node)もPHPもPythonも

だれでもアップロードできるパッケージシステム
なんてのがあると、結局質が良かったり
悪かったり、更新が遅かったりするようのが
大量にできるよね。

だからなかなか使う気が起きない。
こういうところはApacheとかGoogleとかの大きな団体が
大きなライブラリとして作ったものが安心できるね。

637 :デフォルトの名無しさん:2013/11/16(土) 13:07:05.79
関数のシグニチャをみただけで、引数をどういう渡し方をしたらエラーになるのか分かる上に、
それがエディタのツールチップに表示される言語もあるのにね……

638 :デフォルトの名無しさん:2013/11/16(土) 13:10:39.59
>>625
お前バカなの? プロジェクトで使う
共通のライブラリとして
定めて使うに決まってるじゃん。

そもそも"自作"ライブラリであるなら仕様は自作した一つだし、
なんで俺が自作したものがあるのに
他人が作ったものを使わないといかんの?

逆に既に他人が使うものがあるならそれを使えばいいし、
なんで同じことをする微妙に仕様が違う関数を
複数使わないといけないんだだよw

お前の開発スタイルが透けて見えるわ。
関数をコピペしてちょっと改造して使うってやり方してるだろ?
そんなんだから、同じような処理なのに微妙に違うものが
たくさん出来てしまうんだよ。

639 :デフォルトの名無しさん:2013/11/16(土) 13:11:21.33
>>637
凄いよね。それはたった数分のメリットだ。

640 :638:2013/11/16(土) 13:12:13.51
>>638>>635へのレス

641 :デフォルトの名無しさん:2013/11/16(土) 13:13:04.05
劣った言語を使う人間は、皆同じ事を言う

642 :デフォルトの名無しさん:2013/11/16(土) 13:14:33.37
>>641が自分でそれを証明している件について

643 :デフォルトの名無しさん:2013/11/16(土) 13:15:51.82
>>638
お前が全く分かってない事が分かった
他人が作ったライブラリの中では、そいつ独自の引数チェック関数を使ってて、
それは仕様が微妙に違うって話だろ
だったら違うライブラリを使う度に、引数渡しのルールなんて基本的なものの
仕様を確認する必要があるじゃん

644 :デフォルトの名無しさん:2013/11/16(土) 13:21:34.58
>>643
お前は何を対象にしてるんだ?

チームで同じプロダクトを開発してるなら、
そのチームのルールに合わせればいいだけだろ。
微妙に仕様が違うなら、それはそれを書いた人の問題。

全くの他人であれば、プロダクトも全く他人のものだろ?
それはそいつのルールに合わせればいいだけの話。

同じプロダクトで仕様が異なれば混乱もするだろうが、
他人のプロダクトなら、そのプロダクトのやり方に従えばいいし、
そのプロダクトで仕様は同じだろ。混乱するわけがない。

もしかして他人のコードよんだことないの?
オープンソースのコード見て、俺が作ったものじゃないから
この関数の使い方わかんないって泣くの?

645 :デフォルトの名無しさん:2013/11/16(土) 13:23:45.99
他の言語じゃ言語仕様で決まってるような事が
ライブラリ毎に違うんじゃ効率悪いわ

646 :デフォルトの名無しさん:2013/11/16(土) 13:24:37.63
ほんと、この程度の理解能力でも
大きな差があるんだなって思うよ。
もっと他人が書いたコードを読め。

これプログラマの能力の一つなんだよね。
出来る人は知らない言語や関数であったとしても
表面から意図と意味を読み取れるでしょ?

647 :デフォルトの名無しさん:2013/11/16(土) 13:27:23.84
優秀なプログラマは怠惰だから、
ライブラリ毎に違う仕様を把握するなんて面倒な事は
避けられるなら避けるよ
で、これは避けられる類の問題

648 :デフォルトの名無しさん:2013/11/16(土) 13:39:36.56
>647
プログラマの美徳の怠慢ってそういう意味じゃねーぞw

全体の労力を減らすために手間を惜しまないって意味だぞ
自分の力で手間を解決できないのは、無能な意味の怠慢

649 :デフォルトの名無しさん:2013/11/16(土) 13:39:38.52
勤勉で無能ってのはドカタの資質だからな

650 :デフォルトの名無しさん:2013/11/16(土) 13:40:43.17
デフォルト引数ねぇのかよ、かったりーな

よし自分で関数作って楽にするか

これが「優秀なプログラマの怠慢」

651 :デフォルトの名無しさん:2013/11/16(土) 13:41:35.27
全体の労力を減らすために、劣った言語から優れた言語に切り替える手間を惜しまない

652 :デフォルトの名無しさん:2013/11/16(土) 13:42:34.45
それは劣った言語であるという前提がなければ成り立たない
意味のない答えだ。

653 :デフォルトの名無しさん:2013/11/16(土) 13:43:06.81
キーワード引数の仕様がライブラリ毎に違うとか
劣ってるでしょ

654 :デフォルトの名無しさん:2013/11/16(土) 13:43:50.45
そもそもキーワード引数は対して必要ない機能。

655 :デフォルトの名無しさん:2013/11/16(土) 13:44:50.28
結局自分の力で問題を解決できない人が、
こんなのが標準で言語に入ってるから凄いんだ。
それを使ってる俺も凄いんだ。って言ってるにすぎないな。

656 :デフォルトの名無しさん:2013/11/16(土) 13:44:55.58
あ、結局はそういう逃げに入るよね
劣った言語ユーザって

657 :デフォルトの名無しさん:2013/11/16(土) 13:46:29.58
自分で問題を解決する力がある人にとっては
”この程度の小さい差”って笑い飛ばすんだろうな。

658 :デフォルトの名無しさん:2013/11/16(土) 13:47:12.96
>>655
ライブラリ毎にキーワード引数の仕様が違うという問題は
どうやって解決したの?

659 :デフォルトの名無しさん:2013/11/16(土) 13:49:57.53
>>658
ライブラリごとにキーワード引数の仕様が違うという
問題にぶち当たったことがない。

なぜならなくて困ってるのは、一部の人だけで殆どの人は困っていないから。
その困っている人だって、力があるなら自分で解決できるということは
証明された。解決するににかかった時間は数分だ。

結局のところ、問題を解決するのに必要なのは、自分の技術力なんだよ。

660 :デフォルトの名無しさん:2013/11/16(土) 13:50:09.53
結局オブジェクトで渡すほうが上位じゃね?
ゲッターとかも機能するし、それこそプロキシ渡したりもできる

661 :デフォルトの名無しさん:2013/11/16(土) 13:52:23.33
>>659
問題が解決出来ないから、キーワード引数を使う文化が根付かなかったんだよ
キーワード引数が在る言語では、キーワード引数は良く使われる機能

662 :デフォルトの名無しさん:2013/11/16(土) 13:54:23.53
キーワード引数の利点は分かりやすいってことだと思う
自由さは少ないけれど、そりゃあもちろん物事には2面性があるからね
でも問題は、実装、利用共に上手く両立するのはまあ難しいし
下手をすると折角の分かりやすさが無くなっちゃうってことだよね

663 :デフォルトの名無しさん:2013/11/16(土) 13:54:40.85
分かると思うけど、>>661はライブラリ毎に仕様が異なるという問題であって
自作できるなんて問題ではないよ

664 :デフォルトの名無しさん:2013/11/16(土) 13:56:56.50
>>662
機能が強力な程良いのならgotoが優れてることになるからね

665 :デフォルトの名無しさん:2013/11/16(土) 13:58:25.49
なら逆に本当に色んな記法の出来るようになればいいのかって言うとそうでもないと思う

666 :デフォルトの名無しさん:2013/11/16(土) 14:00:48.97
あんまり記法を増やしたり自由にするとどこかの言語みたいに
うっかりしても構文エラーにならなくなったりするからなw

667 :デフォルトの名無しさん:2013/11/16(土) 14:17:09.92
そういえばプロキシのハンドラ数って
1,2個から10個以上まで言語環境によって差があるけど
どのくらいの数でどういうチョイスがいいのかね

668 :デフォルトの名無しさん:2013/11/16(土) 14:37:31.52
>>663
「ライブラリ毎に仕様が異なるという問題」は
発生してないのに、なんでそんなに必死になってるの?

669 :デフォルトの名無しさん:2013/11/16(土) 14:40:53.51
そんなこと気にするヤツがTMTOWTDIなPerlを使ったりしないから
問題になってない、が正解

670 :デフォルトの名無しさん:2013/11/16(土) 14:42:02.51
違いはあるんだなあそれが

671 :デフォルトの名無しさん:2013/11/16(土) 14:45:34.97
大体、Perlで引数チェックなんてズレてる
Perlプログラマは間違わない

672 :デフォルトの名無しさん:2013/11/16(土) 14:50:40.83
いいよそういう煽りは
引数の数なんてデフォでチェックするのは利便性を損ないすぎるから
必要なら明示的にチェックすればいいんだよ

673 :デフォルトの名無しさん:2013/11/16(土) 15:46:27.96
引数のチェックは利便性を損なうんですよ。
プロならチェックするべきじゃありませんね。

674 :デフォルトの名無しさん:2013/11/16(土) 16:32:04.61
チェックが利便性を損なうっておかしくね?
チェックがデフォなのがどのくらい有用なのかって話じゃね?

675 :デフォルトの名無しさん:2013/11/16(土) 16:36:48.76
ここで言うチェックがデフォというのはC言語のようなスタイルですよね。
あれは良くない。
理由は良くないからです。

676 :デフォルトの名無しさん:2013/11/16(土) 16:46:18.91
> 引数の数なんてデフォでチェックするのは利便性を損ないすぎるから

損ないすぎるというくらいだから、利便性を損なう例を
いくらでも簡単に挙げられるよね?
え?無理?

677 :デフォルトの名無しさん:2013/11/16(土) 16:58:02.05
>>675
C の関数は引数の数ははじめから固定だから‥‥チェックはしない
引数の内容をチェックすることはCに限らず推奨されてはいるが

678 :デフォルトの名無しさん:2013/11/16(土) 17:02:38.56
> C の関数は引数の数ははじめから固定だから‥‥チェックはしない

それは実行時にしないってだけで
コンパイル時にはチェックしてるじゃん

679 :デフォルトの名無しさん:2013/11/16(土) 17:13:18.90
コンパイラにチェックされるのは利便性を損なうからダメなんですよ。
ダメなものはダメ!

680 :デフォルトの名無しさん:2013/11/16(土) 17:43:24.53
>>677
printf

681 :デフォルトの名無しさん:2013/11/16(土) 17:47:44.66
ぼくは静的型でも引数にNullが代入されてるか調べる時があります!

682 :デフォルトの名無しさん:2013/11/16(土) 18:29:50.69
すべてのあおりもんくはむししてかまいませんね

683 :デフォルトの名無しさん:2013/11/16(土) 19:04:04.43
>>680
デフォルトで引数の数はチェックしておいて、
必要なときだけ可変長引数を使う方が良いな
printfみたいな関数の方が少ないんだから

684 :デフォルトの名無しさん:2013/11/16(土) 19:12:40.14
だめです。
引数チェックは有害です。

685 :デフォルトの名無しさん:2013/11/16(土) 19:33:46.13
昔はJavaでもincetanceof書く馬鹿が多かった
今はjsとか動的型で書いてる奴がtypeofとかやってる
Javaプログラマ馬鹿にしてる場合じゃない

686 :デフォルトの名無しさん:2013/11/16(土) 19:41:21.43
>>685
JavaのジェネリックってInteger Or Stringみたいなパラメータ指定できないじゃん。
instanceof使うしかないよね。動的言語なら簡単なんですけど!!

687 :デフォルトの名無しさん:2013/11/16(土) 19:59:51.91
パラメータ指定って何?

688 :デフォルトの名無しさん:2013/11/16(土) 20:04:38.31
>>687
<T>とか

689 :デフォルトの名無しさん:2013/11/16(土) 20:27:25.29
特殊化出来ないの?
まじで?できるでしょ??

690 :デフォルトの名無しさん:2013/11/16(土) 20:29:15.78
>>689
できねえから言ってんだよ、じゃあお前やってみろよ
もしできなかったら動的厨に鞍替えしろ

691 :デフォルトの名無しさん:2013/11/16(土) 20:39:04.07
JavaScriptはhasInstanceシンボルが入ったから
これからはtypeofよりinstanceofの方が型判定に使われるようになるだろうな
柔軟でいい感じ

s = "abc"
n = 123

StringOrNumber = {
[Symbol.hasInstance](o){ return Object(o) instanceof String || Object(o) instanceof Number }
}

s instanceof StringOrNumber //true
n instanceof StringOrNumber //true

692 :デフォルトの名無しさん:2013/11/16(土) 21:01:18.77
>>686
そんな互換性のない2つの型受け入れる事に何の利点があるんだ
どうしてもって言うならvisitorにする時にAdapterかませばいいだけ
現代でinstanceofなんて使うなよ

693 :デフォルトの名無しさん:2013/11/16(土) 21:09:26.00
そうですよ。
Javaに欠点などないのですよ。
理由は最強のプログラミング言語だからです。

694 :デフォルトの名無しさん:2013/11/16(土) 21:10:55.59
Java(笑)
完全無欠の糞言語

695 :デフォルトの名無しさん:2013/11/16(土) 21:12:39.54
>>692
VisitorとかAdapterとかどんだけ肥大化させるんだよ
コード増やせばバグを作りこむ可能性が増えることを認識しろ
instanceof使ったほうがマシ
関数型でもパターンマッチで普通に使うだろ
instanceof使うのが最先端

696 :デフォルトの名無しさん:2013/11/16(土) 21:13:30.25
え?instanceofなんて普通に使うんだけど。
equalsとか

697 :デフォルトの名無しさん:2013/11/16(土) 21:15:04.22
だからパターンマッチ指向の言語を使えと

698 :デフォルトの名無しさん:2013/11/16(土) 21:17:48.21
>>695
依存性逆にするだけであって肥大化はしねーよ
いちいち型増やす度にinstanceOf書いてたほうが肥大化するわ

つかパターンマッチでinstanceofって前提狂ってるだろ
オメーは動的型でしか考えられないのか

699 :デフォルトの名無しさん:2013/11/16(土) 21:20:21.28
なんでJava 使うんだろうね

700 :デフォルトの名無しさん:2013/11/16(土) 21:22:05.21
>>698
>依存性逆にするだけであって肥大化はしねーよ

なに言ってんだお前
instanceofで2つの型を分けるだけなのに
VisitorパターンとAdapterパターンを実装しなければならないんだろ
それを肥大化と言わずになんと言うんだ
デザインパターンが最高だと思うなよオブジェクト厨が

パターンマッチで型を指定するだろ。
それとinstanceofを使うことは変わらないだろ。

701 :デフォルトの名無しさん:2013/11/16(土) 21:22:23.11
Scalaは言語使用見てると中々よさげだね
私が実践で使うことがあるかは知らないけど

702 :デフォルトの名無しさん:2013/11/16(土) 21:30:38.80
多相バリアントの出番だな

703 :デフォルトの名無しさん:2013/11/16(土) 21:58:05.43
色々調べた結果、LinuxならJavaで特殊化できることがわかりました。
Windows上でやってたのが問題だったようです。
お騒がせしました。
やっぱりWindowsはダメですね。

704 :デフォルトの名無しさん:2013/11/16(土) 22:01:14.15
>>700
>instanceofで2つの型を分けるだけなのに
>VisitorパターンとAdapterパターンを実装しなければならないんだろ
必要なのはNumberOrStringなんて意味もなく混ぜる場合だけ
それこそ型で処理分ければいいだけだ

それとこの場合はvisitorにするのは動的型もメリット大きいんだぞ?
実装側はメソッド定義、呼び出し側はそれの呼び出しだけで済む
つかリファクタすべき典型パターンだろこれ

>パターンマッチで型を指定するだろ。
>それとinstanceofを使うことは変わらないだろ。
ま、instanceofの構文糖のが普通だと思ってたらそうなるわなw

705 :デフォルトの名無しさん:2013/11/16(土) 22:04:30.98
>>704
訂正
☓ 必要なのは
○ Adapterが必要なのは

706 :デフォルトの名無しさん:2013/11/16(土) 22:07:22.47
これまで碌なコード書いてきてないのがすぐ分かるな
まあ好きに言わせておけ

707 :デフォルトの名無しさん:2013/11/16(土) 22:11:19.23
>>704
Object getValue() {
}

void process() {
 Object value = getValue();
 if (value instanceof Integer) {

 } else if (value instanceof String) {

 }
}

じゃあこれをご自慢のVisitorとAdapterを使ってどうぞ

708 :デフォルトの名無しさん:2013/11/16(土) 22:41:35.88
つBoost.Any。

709 :デフォルトの名無しさん:2013/11/16(土) 23:04:13.32
>>707
これ
void processInternal(Integer x);
void processInternal(String x);
で済むじゃん

710 :デフォルトの名無しさん:2013/11/16(土) 23:06:39.81
>>709
すむわけないだろ横着すんな。
Visitorにすると動的型でメリットが大きくて
Adapterが必要なんだろ。
VisitorとAdapterを使ってこしらえてみろよ。

711 :デフォルトの名無しさん:2013/11/16(土) 23:13:21.29
なんで?
なんでダメなの?

712 :デフォルトの名無しさん:2013/11/16(土) 23:14:53.26
>>711
なんでいいと思ったんだ?
そもそもキャストしないとメソッド呼び出せねえじゃん。
さっさと自慢のVisitor、Adapterパターンというやつを見せてみろよ。
リファクタリングの典型例なんだろ。さっさとやれよw

713 :デフォルトの名無しさん:2013/11/16(土) 23:17:15.16
知ってるパターンを言ってみただけのOO厨なのか?w
instanceofを否定するやつってこんなレベル

714 :デフォルトの名無しさん:2013/11/16(土) 23:20:44.06
つまり、動的型はダメってこと?
静的型の大勝利なの?なんで?

715 :デフォルトの名無しさん:2013/11/16(土) 23:22:54.18
>>712-713
今書いてるんだが出す前にちょっと一つ反論させろ
いくらなんでもinstanceof不可避な制限つけたら
使わないでできるわけ無いだろ

型の無い状態からvisitor適用しろって
instanceofで静的に分けろって言ってるようなもんだぞ

716 :デフォルトの名無しさん:2013/11/16(土) 23:23:19.63
何を言ってるのか分からない
静的型のオーバーロードだと>>709じゃダメだが、
動的型のマルチメソッドなら大丈夫なのに

717 :デフォルトの名無しさん:2013/11/16(土) 23:28:47.50
動的型なら getValue().doSomething() で済む

718 :デフォルトの名無しさん:2013/11/16(土) 23:32:03.97
IntegerとかStringみたいなプリミティブな型に
好き勝手にメソッド足すのは良く無いと思います

719 :デフォルトの名無しさん:2013/11/16(土) 23:37:48.09
ラッパーかませばいいじゃん。

720 :デフォルトの名無しさん:2013/11/16(土) 23:39:05.39
void processInternal(Integer x);
void processInternal(String x);

こういうの嫌いなんだよね。
実際に書いてみればわかるけどさ、
この後さらに他の型も使えるようにすると

void processInternal(Integer x);
void processInternal(String x);
void processInternal(Foo x);
void processInternal(Bar x);

みたいに同じようなのがずらずら並んでキモい。

こういうのはさ。

void processInternal(Param x);

みたいな物一つにして、
Param p = new Param(integer);
Param p = new Param(string);
Param p = new Param(foo);
Param p = new Param(bar);
ってやったほうがいいよ。

721 :デフォルトの名無しさん:2013/11/16(土) 23:39:44.91
>>718
拡張メソッド使えばいいやん

722 :デフォルトの名無しさん:2013/11/16(土) 23:43:07.43
おいレス返せボケ
都合のいい前提のままならコード出さねえぞ

723 :デフォルトの名無しさん:2013/11/16(土) 23:45:34.37
というか機能によって何処まで分離するなんか変わってくるじゃん
対して重要じゃない機能で何でもかんでもなんとかパターンを適用してるの?

その時点で設計としてはFatになるんだから言語仕様でできる範囲と
デザインパターンの適用を同列に議論してるのがそもそもあほ

そりゃ動的型付言語の方が書くのは楽に決まってるじゃん
可読性、保守性はまた別の話

724 :デフォルトの名無しさん:2013/11/16(土) 23:46:42.79
>>720
objectとキャストで十分

725 :デフォルトの名無しさん:2013/11/16(土) 23:50:37.43
>>720はこうだった。
Param p = new ParamInteger(integer);
Param p = new ParamString(string);
Param p = new ParamFoo(foo);
Param p = new ParamBar(bar);

>>724
そんなことをしたら、コードが複雑になるだろ。
引数が単一の型であることが重要。
つまりprocessInternalはParamという抽象型
一つだけに対する処理を書けば良くなる。

objectとキャストなんかに頼ったら
processInternalの中で○○型なら変換して〜って
という本質的でない処理であふれるだろ。

726 :デフォルトの名無しさん:2013/11/16(土) 23:51:33.43
> processInternalの中で○○型なら変換して〜って
> という本質的でない処理であふれるだろ。

まあそれを動的型付け言語はやらざるをえないわけですけどねw

727 :デフォルトの名無しさん:2013/11/16(土) 23:51:52.28
>>720
これもそうだけど何でもかんでも受け付けるようなのは
限られた機能だけであって全部が全部そんな実装しないでしょ
やるとしても抽象クラスででしょ

それをケチりたいなら動的型付言語を使えばよろしい

小規模ならそれでもいいでしょう
規模が大きくなって色んな奴が出入りするようなプロジェクトだと死ねるけど

728 :デフォルトの名無しさん:2013/11/16(土) 23:59:25.06
オーバーロードの用途の8割は
型を変換してオリジナルの処理を
呼び出すだけなんだから、
もっとシンプルな文法が合ってもいいと思うな。

729 :デフォルトの名無しさん:2013/11/17(日) 00:13:14.00
変換なんてしてねえよ

730 :デフォルトの名無しさん:2013/11/17(日) 00:14:51.92
お前はしたことがないんだろう

731 :デフォルトの名無しさん:2013/11/17(日) 00:19:37.96
Object型なんていう動的に有利なサンプルでさえ賛否両論あるってことは!
やっぱり静的の大勝利なんじゃないの?
違うの?
なんで?

732 :デフォルトの名無しさん:2013/11/17(日) 00:35:12.03
>>728
それはテンプレートじゃね

733 :デフォルトの名無しさん:2013/11/17(日) 00:40:20.48
>>732
テンプレートは、引数の型を
その型のまま処理するときに使う。

俺が言ってるのは(オーバーロードは)
いろんな型に対応している関数の話。
内部的には型を変換して処理する
(数値を文字型にしたり)

734 :デフォルトの名無しさん:2013/11/17(日) 00:46:44.02
そろそろまとめますね。
要約すると、JSはCの二倍速い。
そういうことですよね?

735 :デフォルトの名無しさん:2013/11/17(日) 00:53:54.49
お前ん中でまとまったので
もう出てくる必要はないと思うよw

736 :デフォルトの名無しさん:2013/11/17(日) 01:16:32.61
「JSはCの二倍速い」をNGに入れとけ
ネタ荒らしには一切構うな

737 :デフォルトの名無しさん:2013/11/17(日) 01:26:44.05
JCはSの二倍速い

あっ間違っちゃったw

738 :デフォルトの名無しさん:2013/11/17(日) 01:32:12.25
>>733
型を変換するかどうかはその関数の意味によるんじゃね?
print っていう関数だったら、そりゃ何でも文字列にするんだろうけど、
sort だったら?

739 :デフォルトの名無しさん:2013/11/17(日) 01:37:01.64
>>738
なんにでも対応できるなんて言ってないよ。

”オーバーロードを使う場合”は、
型変換してあとは同じロジックを使うことが
多いって言ってるだけ。

> sort だったら?
sortはそもそもオーバーロードを使うことが
少ないから例が悪い。

740 :デフォルトの名無しさん:2013/11/17(日) 01:41:20.23
都合の悪いことはジョガイジョガイww

741 :デフォルトの名無しさん:2013/11/17(日) 02:24:09.16
stlはソートで演算子オーバーロード使えるよね。

742 :デフォルトの名無しさん:2013/11/17(日) 04:10:52.08
Perl5でちゃんと引数チェックをしたい場合、この手のモジュールを使う
有名なモジュールは他にもいくつかある
http://search.cpan.org/~gfuji/Data-Validator-1.03/lib/Data/Validator.pm
なお、Perl6はメソッドオーバーロードを含めてここに挙がったような機能はすべて満たしてる

743 :デフォルトの名無しさん:2013/11/17(日) 04:27:04.40
まだ実装が無かったり広く使える状況に無いバージョンの言語使用を取り上げて云々
するときは「満たす予定」とか「満たす(※ただし時期未定)」とか書こうぜ。

744 :デフォルトの名無しさん:2013/11/17(日) 06:28:57.60
>>726
おまえバカだろ?

745 :デフォルトの名無しさん:2013/11/17(日) 06:32:44.94
結局、型ってのは苦痛の元でしかないんだな。

746 :デフォルトの名無しさん:2013/11/17(日) 07:21:09.32
Perl6が静的型付に方向転換したのは興味深い

747 :デフォルトの名無しさん:2013/11/17(日) 07:24:23.54
VisitorとAdapterを使ったコードはまだなのか?
あんだけ偉そうに言っといて出せないってどういうことだよw
リファクタの典型なんだよね?じゃあやってみろよ。

748 :デフォルトの名無しさん:2013/11/17(日) 10:10:19.48
>>747
Object型をinstanceofなしでVisitorにするなんて不可能
そんな条件で出すわけ無いだろ馬鹿

749 :デフォルトの名無しさん:2013/11/17(日) 10:17:53.21
不可能は言い過ぎたな
リフレクションでも分岐はできる。
どちらにしろJavaなのに型検査を使わない前提を条件にする馬鹿に
いちいち取り合うわけないだろ

750 :デフォルトの名無しさん:2013/11/17(日) 10:18:26.92
>>748
ああ書けないのね、ヘタレすぎだろw

>どうしてもって言うならvisitorにする時にAdapterかませばいいだけ
>現代でinstanceofなんて使うなよ

>依存性逆にするだけであって肥大化はしねーよ

>それとこの場合はvisitorにするのは動的型もメリット大きいんだぞ?
>実装側はメソッド定義、呼び出し側はそれの呼び出しだけで済む
>つかリファクタすべき典型パターンだろこれ

こんなに偉そうなこと言っておきながらいざ書けと言われたら書けないのね。あっそう、じゃあもういいよw

751 :デフォルトの名無しさん:2013/11/17(日) 10:20:26.19
>>759
書けるし書いたよ
でも先に条件をきちんと述べてくれないとな
どうせ上にヤツみたいにObject型使ってないとか難癖つけるんだろ?

752 :デフォルトの名無しさん:2013/11/17(日) 10:23:43.94
>>751
お前さ、人の言うことにはずけずけ文句言って典型的パターンだとかバカにするくせに
自分がコード出すときは文句言われるの怖くて出せないわけ?激ダサだな。ゴミのようなヘタレだな。
そんなヘタレコードもう見たくもねえよ。自分の考えに自信をもって胸を張って提示しみろよ。

753 :デフォルトの名無しさん:2013/11/17(日) 11:05:08.15
http://uploda.cc/img/img528823f2c1b44.jpg

754 :デフォルトの名無しさん:2013/11/17(日) 11:11:23.82
メタ情報を活用し秩序を重視する文明人→静的型付け
無駄を省きフットワークを重視する裸族→動的型付け

755 :デフォルトの名無しさん:2013/11/17(日) 11:27:22.44
型消去の仕組みを使うと高速性が生かせないので、できるだけ型情報を維持しようと
するけど、そこにヒントがあるんじゃないの?
たとえば、H8使ってモータードライバ作ろうとするとき、動的を有効に使えるかどうか。

756 :デフォルトの名無しさん:2013/11/17(日) 11:29:34.86
GC始まるとカニ歩きはじめるロボットがあったら怖いでしょ。
怖くないよ^^

757 :デフォルトの名無しさん:2013/11/17(日) 11:32:10.60
>>756
どっちだよw

758 :デフォルトの名無しさん:2013/11/17(日) 11:34:28.62
将来ロボットが街を歩くようになったら、動的と静的はすぐ見分けがつく。
たまにプルプルしてるのが動的。
人間も年取ると「あの人は動的」とか言われるんだろうね。

759 :デフォルトの名無しさん:2013/11/17(日) 11:41:36.23
>>758
kwsk

760 :デフォルトの名無しさん:2013/11/17(日) 11:53:10.23
ドライバの処理が追い付いていないと、停止中のサーボがプルプルするでしょ。
お爺さんぽくて良いなと。

761 :デフォルトの名無しさん:2013/11/17(日) 11:57:41.77
>>752
結局確約できないんだなw
ま、確かにこんな奴に文句言われても、もうどうとも思わんわ
pastebin.com/tbqxHZgC

762 :デフォルトの名無しさん:2013/11/17(日) 12:05:37.49
>>761
絶対叩かないって約束しろよと泣き事言われても聞く気はない
それが俺の武士道だ

763 :デフォルトの名無しさん:2013/11/17(日) 12:09:46.69
なにこれなめてんの?ただのVisitorパターンじゃねえか。
Adapterはどこなんだよ、getValueはどこ行ったんだ?使い物にならねえよ。
デザインパターンのご本読んで丸写ししただけなの丸わかりwレベル低すぎ。

764 :デフォルトの名無しさん:2013/11/17(日) 12:27:16.65
>>762-761
絶対叩くななんて言ってねえよ
でもObjectについては言及しなかったのは偉いぞ

お前はその教科書レベルすら思いつかないってこった

765 :デフォルトの名無しさん:2013/11/17(日) 12:29:07.78
ところでみんな何作ってんの?

766 :デフォルトの名無しさん:2013/11/17(日) 12:32:20.78
>>763
ほれwがんばって勉強しろよw
/d.hatena.ne.jp/Nagise/20120426/1335451716

767 :デフォルトの名無しさん:2013/11/17(日) 12:38:27.58
>>764
確約して欲しかったんだろwうじうじ、ぐずぐずしてコード出そうとしなかったじゃないかw
何度も催促してようやく出したが本に書いてあるサンプルコードをそのまま打ち込んだだけのただのVisitorパターンだった。
完全にゴミだった。で、Adapterパターンはどうしたんだ?
ご本に載ってるだろ、それ書けばいんじゃねえの?w

768 :デフォルトの名無しさん:2013/11/17(日) 12:41:29.22
>>766
なるほどね、お前はそれを読んで感化されて調子に乗ってVisitorパターンがどうとか言っちゃったわけなのか?
言っては見たものの実力が足りず丸投げとw

769 :デフォルトの名無しさん:2013/11/17(日) 12:45:22.56
Javaは冗長の代名詞なんだから
いくら長くなっても全く問題ないでしょ?
Javaでタブーなのは少しでもトリッキーなもの
ベタベタ書くのはとてもいい行為

770 :デフォルトの名無しさん:2013/11/17(日) 12:46:57.46
沢山書けばたくさんお金がもらえるからですか?

771 :デフォルトの名無しさん:2013/11/17(日) 12:55:48.35
java原人は現代人よりも人間本来の能力が高いのです。現代人はそこらに生えている草が食えるか食えないか知らないように。

772 :デフォルトの名無しさん:2013/11/17(日) 12:59:39.30
>>769
あほかw

その言語で出来る限り短くにするに決まってるじゃん。

冗長なのが問題なのではなく、
必要ないものがあるのが問題。

例えばJavaは型情報が必要だが、それはそれであると便利であり
これは必要な物だから、冗長には当てはまらない。

773 :デフォルトの名無しさん:2013/11/17(日) 13:00:52.74
むしろ虚弱な現代人が安心して生きていくためにJava法典が必要なのです

774 :デフォルトの名無しさん:2013/11/17(日) 13:03:22.79
Javaは記憶域を確保するために型情報を必要とするので沢山書けて
沢山時間がかけられる。
同じことをするのにお金がいっぱいもらえます。

775 :デフォルトの名無しさん:2013/11/17(日) 13:04:33.99
>>774がJavaで書くと、それだけで冗長なコードになりそうだな
そして言語のせいにするんだよね
Javaがー。俺が悪いんじゃないー。Javaがーって

776 :デフォルトの名無しさん:2013/11/17(日) 13:14:53.84
俺ほめてるんだけど。
Javaすげー。工数盛り盛りー。Javaすげーって。

777 :デフォルトの名無しさん:2013/11/17(日) 13:16:56.66
Javaは良くも悪くも土方向け言語、馬鹿や初心者でも開発に参加できる言語だからね
念のため言っておくけど、褒め言葉だよ、そういう特長を持ってるのは素晴らしい

778 :デフォルトの名無しさん:2013/11/17(日) 13:40:07.05
>>768
全然効かんw
少なくともinstanceof列挙に何も感じないアホよりはマシです

779 :デフォルトの名無しさん:2013/11/17(日) 13:45:58.06
>>767
見落としてた
>で、Adapterパターンはどうしたんだ?
書き換えにAdapterが必要なんじゃなくて、
2つの互換性のない型を使う処理に必要って言ってる

そうやって意図的に曲解する事でしか反論できんの?w
残念だけどゴミなのはお前のコードとその頭のようだよ

780 :デフォルトの名無しさん:2013/11/17(日) 14:39:34.88
じゃあObjectとプリミティブ型で処理を分けたいときはどうするの?

781 :デフォルトの名無しさん:2013/11/17(日) 15:03:35.76
プリミティブを特殊化する。

782 :デフォルトの名無しさん:2013/11/17(日) 15:18:03.74
>>776
工数は減らすほうがいいよ。

そこで得られる報酬は
工数とは無関係。
価値に対して報酬は決まる。

君のように人月でしか考えてないと
わからないだろうけどさ。

783 :デフォルトの名無しさん:2013/11/17(日) 15:27:40.65
うわぁ本当に何も知らないのね
Java開発ってそういうもんだから
幻想は捨てたほうがいいよ

784 :デフォルトの名無しさん:2013/11/17(日) 15:30:47.15
工数なんていくらでも盛れるんですよ。
お客様は素人なんだから。
「よそで見積もりとっても同じだと思いますよ?」って言えばいいだけなんですよ。
ちなみに僕は実績工数*1.5で提出します。
そして営業はお客様に0.7で割って出すらしいですよ。
結局実績の2.14倍でふっかけるわけですよね。
どこも同じことやってるんだから大丈夫ですよ。

785 :デフォルトの名無しさん:2013/11/17(日) 15:34:40.47
デスマーチってあるじゃないですか。
あれきっと仕事の基本がわかっていないんですよね。
僕たちはできないことを引き受けることを一番恐ろしく思ってるわけじゃないですか。
でも低能ってそうじゃないんですよね。
俺スゲー俺スゲー何でもできる!って安請け合いしちゃう。
そしてできない。
出来ない人ほど安請け合いしちゃうんですよ。
安請け合いすると能力を高く見せれると思ってんですかね?
こっちにヘルプ求めないでね^^

786 :デフォルトの名無しさん:2013/11/17(日) 15:38:56.44
>>784-785
ストレスたまってるのか?

787 :デフォルトの名無しさん:2013/11/17(日) 15:41:57.95
Javaの良さを教えてあげただけだよ。
まあ使ったことないんだけど。

788 :デフォルトの名無しさん:2013/11/17(日) 15:58:19.88
ここまでまとめるとJCはJSの二倍速い

789 :デフォルトの名無しさん:2013/11/17(日) 16:07:54.71
初NGおめ

790 :デフォルトの名無しさん:2013/11/17(日) 16:36:13.19
JSはCの三倍は速いですよ。
やってみればすぐわかることなんですがね。
最近の中学生は実際にやってみないんですよね。
調べればわかると思っているんですよ。
インターネットのせいですかね。
やってみて初めて分かることは多いんですよ。
たとえばJSがCの三倍以上速いこととかね。

791 :デフォルトの名無しさん:2013/11/17(日) 16:49:09.61
>>785
安請け合いするのは営業では?

792 :デフォルトの名無しさん:2013/11/17(日) 17:04:39.80
あ、仕事ではそうなんですねwwww

793 :デフォルトの名無しさん:2013/11/17(日) 18:16:36.79
他の業者が逃げて売れ残った案件を目をつぶって掴みに行く営業がいたっていいぢうわなにをすr

794 :デフォルトの名無しさん:2013/11/17(日) 18:55:20.65
顧客も見てんのよ

795 :デフォルトの名無しさん:2013/11/17(日) 18:55:57.81
A or Bなパラメーターを受けるのにその場の技巧的にAdapterを使うことは少ないかなぁ。
普通にmethod(A a)とmethod(B b)と二つメソッド作る。
A, B or C or ...であればmethod(A a, B b), method(A a, C c), ... とすべての
組み合わせを列挙するか(比較的まじ)、APIが煩雑になるのであればBuilderパターンに
するのが実際に使われているJavaのAPIではよく見るパターンだと思う。

あとは必要なクラスだけ受けられるスーパークラスないしインターフェイスがあれば
それを使う。よく設計されたドメインクラス群を持つAPIの場合は大抵このパターンに
落ち着くので、「APIのユーザーは」上記のような煩雑さやinstanceof云々に遭遇する
ことは案外少ない。

で、Javaの場合APIの実装の中身の煩雑さを見ないことにするのもある程度は真実だと思う。
外の人の幸せのために中の人ががんばるのはどこの世界でも変わりません。

796 :デフォルトの名無しさん:2013/11/17(日) 19:04:56.86
バイトコードを直接弄りますとかDIとか中の人の頭の良さに付いていけない

797 :デフォルトの名無しさん:2013/11/17(日) 21:34:07.25
>>791
営業が自力でスケジュール立てるなら、それは営業の責任だから別にいいじゃないですか。
やはり無理でしたねwって言ってやればいい。
実際はそんなことないから防衛するんでしょ。
お互いに。

798 :デフォルトの名無しさん:2013/11/17(日) 22:48:26.40
誰が誰と言い争っているのかも分かり辛い
さすがアスペだらけな事はある

799 :デフォルトの名無しさん:2013/11/17(日) 23:57:36.33
言い争ってないでそ。
俺はJSはCの3倍ほど?いやもっと?速いって言いたいだけだし。
それさえ言わせてくれたらあとはどう反論されようとかまわないし。

800 :デフォルトの名無しさん:2013/11/18(月) 00:24:02.10
今まで
JSはCの二の舞い。
に見えてた

801 :デフォルトの名無しさん:2013/11/18(月) 00:51:46.08
2倍速いのは
asmjs-apps-lua_binarytrees-workload4
だけだな
http://arewefastyet.com/#machine=12&view=breakdown&suite=asmjs-apps

802 :デフォルトの名無しさん:2013/11/18(月) 01:02:08.24
>>795
そりゃ2種類そのまま使っていいなら、素直に分けた方がいいさ
Adapter必要って言ったのは、1つの型として扱うのを強制される場合だよ

803 :デフォルトの名無しさん:2013/11/18(月) 01:02:15.54
今ある言語仕様や夢見る将来の仕様を持ち出して曲芸大会をするのも結構だけど、ある程度
の規模になると結局ライブラリやフレームワークを持ち出して使うわけで。
つまり目的がまずあって、ライブラリやフレームワークといった道具を用意してその上で
開発をするわけで、そういった目的や道具立てといったコンテキストを抜きに小手先の
コード比較をしたところで娯楽以上の生産的意味は無いかな。

普通フレームワークの類いはやりたいことをターゲットの言語の枠内で無理なく出来るよう
作ってあるはずで、フレームワークに使われている大多数の人にとっては言語に無い機能を
取り上げて「どうよ」と問われたところで「いや、それ特に必要無いし」となるし、現実
そうだったりする。

Javaの文法は土方向きでも実際の適用範囲は土方分野から大規模分散処理まで幅広いわけで。
それもStrutsからHadoopソフトウェアスタックに至るよく使われて叩かれた道具があるため。
言語仕様による生産性の差は比較的限定的なもので、使える道具の厚みとかテストやコード
管理、CIといった運用の方がより生産性に影響すると思うけれどもね。

804 :デフォルトの名無しさん:2013/11/18(月) 01:08:10.08
asm.jsはオーバーヘッドが大きいみたいだね
http://jsperf.com/fib-asm-js/2
http://jsperf.com/fib-asm-js/4
ミリ秒かからないような処理だと普通の方がよくなるのか

805 :デフォルトの名無しさん:2013/11/18(月) 01:22:37.90
iPhone2.1だとasm使わない方が早かったぞー

806 :デフォルトの名無しさん:2013/11/18(月) 02:41:40.72
そもそも計測限界値ギリギリなんですけどそれは……

807 :デフォルトの名無しさん:2013/11/18(月) 02:44:21.58
Qt Quickの本を見たら、JSは遅いので、
出来るだけC++のライブラリを呼び出せって、書いてあったw

808 :デフォルトの名無しさん:2013/11/18(月) 09:47:24.25
Qtの場合はネイティブ側でデータ持ってるから
それをスクリプトとやりとりするのにコストがかかるからね
この辺り読むといい
http://qt-labs.jp/2013/04/evolution-of-the-qml-engine-part-1.html

809 :デフォルトの名無しさん:2013/11/18(月) 14:34:01.22
>>801
面白い
マクロベンチでもC++の2倍の性能出ることあるのか

810 :デフォルトの名無しさん:2013/11/18(月) 14:55:53.44
>>801
これc++のlua-vmとjsのlua-vmの比較って事?

811 :デフォルトの名無しさん:2013/11/18(月) 15:20:33.61
だね

812 :デフォルトの名無しさん:2013/11/18(月) 15:25:23.52
C++とそれをemscriptenでJSにしたコードとの比較だな
https://github.com/dvander/arewefastyet/tree/master/benchmarks/asmjs-apps

813 :デフォルトの名無しさん:2013/11/18(月) 17:23:23.56
asm.jsどころかasm.js無しのFFでもネイティブ並みに早くなっていて他方でChromeは
おいてけぼりなのが気になるなぁ。FFの何かがパコンとはまっている気がする。
GC周りかな。

814 :デフォルトの名無しさん:2013/11/18(月) 18:06:58.66
単純な話だよ
Modilla繋がりでemscriptenはFirefoxでよく最適化されるコードを積極的に吐くし
Firefoxはemscriptenのコードが早く動くよう積極的に最適化してるから
代表的なベンチではほぼ同じ
http://arewefastyet.com/

815 :デフォルトの名無しさん:2013/11/18(月) 18:15:46.83
皆さん良いですか?
Cで書かれたJS実行環境は、Cより速いんです。
ということはですよ。
JSで書かれたJS実行環境を、Cで書かれたJS実行環境上で走らせるともっと速いわけです。
さらにですよ。
Cで書かれたJS実行環境上で走るJSで書かれたJS実行環境上で、JSで書かれたJS実行環境を
走らせるともっともっと速いわけです。
これを繰り返すと無限に速くなるんですよ。
つまりですね、現代のコンピュータは記憶容量のみに律速されているんです。
なぜなら、現代にはJSがあるのだから。

816 :デフォルトの名無しさん:2013/11/18(月) 19:00:32.07
>>815
バカ

817 :デフォルトの名無しさん:2013/11/18(月) 19:01:52.15
単純かなぁ。プログラマならこれを単純として片づけるのはどうかなぁ。

818 :デフォルトの名無しさん:2013/11/18(月) 19:41:22.11
プログラマがみんな同程度の能力なら>>815の論理も成り立つが、
現実は極限られた超絶技巧のプログラマが鬼速の処理系を書くから、
その他大勢の>>815みたいなアホプログラマがCで直接書くよりも
高級言語で平凡以下のコードを書いて鬼速処理系が最適化したほうが速くなるんだよ。

819 :デフォルトの名無しさん:2013/11/18(月) 20:27:57.87
>>817
単純じゃない話なんてここでできないでしょw
一番分かりやすい話で言うとそうだよ

820 :デフォルトの名無しさん:2013/11/18(月) 21:22:38.00
JSエンジンがC言語バインドのインタプリタで必ずemscriptenで変換されたC->JSコードの性能がアップするのなら>>815は正しいが
実際はアセンブリまでコンパイルされての結果だからそっから高級言語に戻しても成り立たない

821 :デフォルトの名無しさん:2013/11/19(火) 14:16:23.08
>>813
そうは見えないが
黒と緑だぞ

822 :デフォルトの名無しさん:2013/11/19(火) 15:06:31.44
>>821
lua-binarytreesのワークロードね。後半に行くとno asm.jsもネイティブ並みに早く
なっている。緑の線だけが置いてけぼり。
で、こんなパターンが出ているのはこのlua-binarytreesだけで、asm.jsがネイティブ
を上回っているのもこれだけなのでやや気になった。

823 :デフォルトの名無しさん:2013/11/19(火) 16:02:04.17
JavaScriptが速いというより、単にネイティブ言語コンパイラより開発が活発で技術力が上というだけだよ。

824 :デフォルトの名無しさん:2013/11/19(火) 16:20:14.12
古いものを切り捨てるのに一切の躊躇いがいらないからな

825 :デフォルトの名無しさん:2013/11/19(火) 17:38:10.23
JavaScriptはかなり後方互換性高いと思うけど

826 :デフォルトの名無しさん:2013/11/19(火) 18:34:41.97
http://dqn.sakusakutto.jp/2013/11/php51to54.html

動的言語の悲惨さの一例
静的チェックができないと言語のバージョンアップすらこの有様

827 :デフォルトの名無しさん:2013/11/19(火) 18:54:51.82
それ読んだわ
静的動的は関係なく言語の問題だな

828 :デフォルトの名無しさん:2013/11/19(火) 22:31:18.51
>>827
もしかして互換性無い問題の話のことを言ってる?
確かに互換性がないのは言語の問題だよ。

でもそれは多かれ少なかれどの言語にもあることで、
重要なのは、互換性がないのは分かった。
じゃあ、それからどうするのだ?って話だと思う。

修正する時に重要なのは、影響範囲がどこまで及ぶかを調べること。
何かを修正した結果、想定しない箇所に影響が出たら困るからね。
テストがあれば、動的でも可能だけどテストに漏れがないことを保証する方法はない。
そもそも改修が必要な物は、何かしら問題を抱えているから
改修が必要なわけで、そこに完璧なテストを求めることは出来ない。

だからテスト以外の方法で客観的に影響範囲を把握でき、
できることなら機械的にコードを修正(リファクタリング)する方法が必要になる。

ここまで話をしたら、静的動的が関係あるってわかるでしょ?

829 :デフォルトの名無しさん:2013/11/20(水) 00:03:42.65
ま、静的型付け言語の方がリファクタリングしやすいのは当たり前だわ

830 :デフォルトの名無しさん:2013/11/20(水) 00:37:32.36
アイデア自体は動的から出るんだけど、
結局それをうまくこなすのは静的って構図だな。

831 :デフォルトの名無しさん:2013/11/20(水) 01:14:06.82
>>828
バカだなあ
言語仕様が変わったら静的型だろうが以前の動作は保証されないだろ
影響範囲だって、言語仕様の変更が明確でなければ静的検査では追いかけられない
結局はテストで把握するしかないんだよ

結局静的脳はおもちゃしか作れないんだなw

832 :デフォルトの名無しさん:2013/11/20(水) 01:15:31.03
>>830
動的が生み出すアイディアは本物で、
静的のは劣化コピーだけどなw

833 :デフォルトの名無しさん:2013/11/20(水) 01:30:43.20
煽ることしかできないやつは静的動的関係なく無能です

834 :デフォルトの名無しさん:2013/11/20(水) 03:03:22.31
静的動的は型でチェックするかだけでそんな崇高な何かじゃねーよ。
動的が至高ってのはピストでブレーキにとらわれない俺かっけーってのと同じレベルだろ

835 :デフォルトの名無しさん:2013/11/20(水) 03:10:48.63
>>834
ブレーキついてないのは静的型だろw
コンパイルしたら型情報は消し去るんだから
動的型のほうがランタイムにも型情報があって安全だ

836 :デフォルトの名無しさん:2013/11/20(水) 03:17:44.29
影響範囲ってメソッドを変えればいい程度なら別に動的でも十分調べられるよ
問題はデフォルト値や関数の挙動が微妙に変わっちゃってること
特にこの件はその挙動の違いに実装のバグも含まれてるどうしようもない事件
あとサーバーごと変えたからサーバーの設定にも手間取っての3年

837 :デフォルトの名無しさん:2013/11/20(水) 03:18:02.61
> コンパイルしたら型情報は消し去るんだから

??? RTTIが使える静的言語はいくらでもあるが・・・

838 :デフォルトの名無しさん:2013/11/20(水) 03:21:24.04
>>835
高性能ブレーキついてるから安全だぜぃとか言いながら歩道を飛ばしてるアホと同じだな (w

839 :デフォルトの名無しさん:2013/11/20(水) 03:38:40.14
そんな奴見たこと無いな
お前さんの友達か何か?

840 :デフォルトの名無しさん:2013/11/20(水) 03:39:08.86
>>835
その考えはいたるメソッドで非効率にバリデーション書きそうな発想だな

841 :デフォルトの名無しさん:2013/11/20(水) 04:03:45.80
>>835
動的型で書いてる方が実行時エラー出す頻度高いだろ
これ相当に頭悪い発言だな

842 :デフォルトの名無しさん:2013/11/20(水) 04:07:18.43
動的型はコンパイルと実行が同じ
つまり同じ数のテスト試行で2倍安定

843 :デフォルトの名無しさん:2013/11/20(水) 04:44:31.90
>>840 鏡に叫ぶのって楽しいか?バーカw

844 :デフォルトの名無しさん:2013/11/20(水) 04:45:38.17
>>841
エラー出したぐらいで止まっちゃうヘッポコ言語使ってるの?
かわいそうにw

845 :デフォルトの名無しさん:2013/11/20(水) 05:15:23.99
> コンパイルしたら型情報は消し去るんだから

というスタート地点の認識からして間違っているんだからもうこの線は諦めたら?

846 :デフォルトの名無しさん:2013/11/20(水) 05:45:05.91
>>844
動的でもエラーが出たら、
そのパスの実行は止めると思うが。

847 :デフォルトの名無しさん:2013/11/20(水) 08:19:40.19
エラーがあったら落ちるほうが良いと思うんだが
バグがあっても例外で握りつぶしてる人か?

848 :デフォルトの名無しさん:2013/11/20(水) 08:49:05.15
エラー検出して止める機構を持たない石器時代の原人がいると聞いて

849 :デフォルトの名無しさん:2013/11/20(水) 09:23:28.69
>>846
参考まで、動的型で、言語処理系としても動的性を究極まで探求したSmalltalkの場合、
テストとかで、わざと存在しないメソッド呼び出し書いて(コンパイル時エラーもあえて無視)、
そのテストの実行時エラーでデバッガを起動してその中でコード書いて実行を続けさせて
エラーをつぶし終わるとそのパスを通るコードが完成して正しい結果が返ってくるってやりかたをすることもある。
http://www.youtube.com/watch?v=ymITEeAOtEA

850 :デフォルトの名無しさん:2013/11/20(水) 09:50:13.74
エラー吐くだけいいだろ
Groovyとか無言で死ぬぞw

851 :デフォルトの名無しさん:2013/11/20(水) 11:36:41.99
言い方が乱暴
try-catchは止めて例えば失敗した時にはnullを返すとか
そういった柔軟なことが動的の方がやりやすいってことでしょ
それは分かるよ

852 :デフォルトの名無しさん:2013/11/20(水) 13:58:46.66
>>849
VB6/VBSのエディットコンティニューみたいなのか
.NETにもあるよ

853 :デフォルトの名無しさん:2013/11/20(水) 15:00:34.16
Eclispeにはそのエディットコンティニューよりもっと制約の少ないホットコード置換があるよ

854 :デフォルトの名無しさん:2013/11/20(水) 16:15:05.20
ここでEclipseを出したらダメだ。
Eclipseも元々は〜とか言い出してSmalltalkerが無駄に元気になっちゃうだろう。

最近はJavaの世界でもIntelliJ IDEAとか人気だし、Netbeansも含めたこの手のIDEは
プラグイン拡張で多言語対応が普通。単一の言語でプロジェクトが閉じないことも
最近は少なく無いから必然ではあるのだけど。
動的言語の開発時であってもこの手のJavaやC系の言語で書かれたIDEを利用している
人は少なくないんじゃないのかな。

855 :デフォルトの名無しさん:2013/11/20(水) 16:27:26.13
Smalltalkは普及してない時点でお察し

856 :デフォルトの名無しさん:2013/11/20(水) 17:56:11.07
>>851
所詮静的脳ではその程度の理解に留まるわけか
かわいそw

857 :デフォルトの名無しさん:2013/11/20(水) 17:59:30.47
>>853
わかりやすい劣化コピーの例w

858 :デフォルトの名無しさん:2013/11/20(水) 18:07:38.85
初心者はJSの速さを知らない。
JSを使いこなせるようになって初めて一人前と言える。

859 :デフォルトの名無しさん:2013/11/20(水) 19:05:06.60
スクリプト言語の王様JSを制するってことは
ライブラリを制するってことであり
プラットフォームを制するってことだな

860 :デフォルトの名無しさん:2013/11/20(水) 21:24:32.58
王様とか言い出したぞ

861 :デフォルトの名無しさん:2013/11/20(水) 21:26:52.47
スクリプトが言語大陸の一国の王位の知名度はあるだろうよ

862 :デフォルトの名無しさん:2013/11/20(水) 21:44:15.25
JSは普通に使うけどここに常駐するJSerのおかげでネタ化してかえって悪印象だな。

863 :デフォルトの名無しさん:2013/11/20(水) 21:58:48.56
JSの速度が2倍厨とかはJSerじゃないぞ
ただの荒らし

864 :デフォルトの名無しさん:2013/11/20(水) 23:34:38.76
荒らしorMozilla厨

865 :デフォルトの名無しさん:2013/11/20(水) 23:41:54.13
JSはawaitが入るES7になったら使ってやんよ

866 :デフォルトの名無しさん:2013/11/21(木) 00:19:00.72
たかし、目を合わせちゃいけません さ、お家に帰りましょ

867 :デフォルトの名無しさん:2013/11/21(木) 05:38:09.14
ES6になったら、ウェブ開発時のスクリプト言語としては、もう他の言語は不要だと思う

868 :デフォルトの名無しさん:2013/11/21(木) 12:24:55.96
と、言うか大規模進化って使う気が湧いてくるよな
ま実際に入るのは少しづつなわけだけれど

869 :デフォルトの名無しさん:2013/11/21(木) 12:36:11.92
>>864
Mozillaの書いた「asm.jsはネイティブの半分の速度」という記事を日本のニュースサイトが誤訳してそうなっただけだからMozillaはあまり関係ない
Mozilla Japanの人が誤訳を指摘してもいる

そもそもasm.jsは型を固定することで速度を出すんだから、速度面での動的型付けの弱さを露呈させた例だよねぇ?なんでこのスレにJS厨が来るんだろう?

870 :デフォルトの名無しさん:2013/11/21(木) 15:45:37.05
最初緩くてキツいオプション作る方が逆よりいいのではっていう話じゃ?

871 :デフォルトの名無しさん:2013/11/21(木) 16:00:19.31
>>869
静的型付け言語に未来はなく
JSみたいな動的型付け言語の方が潜在開発生産性が高いから見習えってことだろ
スレタイ忘れたのかよ

872 :デフォルトの名無しさん:2013/11/21(木) 16:07:29.30
>潜在開発生産性

今日のこのプロジェクトで潜在してたら意味ないんですが

873 :デフォルトの名無しさん:2013/11/21(木) 16:24:05.89
匿名掲示板で「今日のこのプロジェクト」is what
>>872

874 :デフォルトの名無しさん:2013/11/21(木) 16:50:14.59
>>871
スレタイ見直せば

875 :デフォルトの名無しさん:2013/11/21(木) 17:41:30.52
Apache Software Foundation等のプロジェクトの成果物が無ければJavaなんか使わないし、
逆に言えばASFがあるのがJavaの強み。
動的静的と全然関係ないけれども、生産性や適用可能分野は案外そういう関係ないところ
でも決まる。

876 :デフォルトの名無しさん:2013/11/21(木) 18:10:47.92
それは潜在ではなく顕在してるのでは?

877 :デフォルトの名無しさん:2013/11/21(木) 19:25:31.95
静的型付け言語の顕在開発生産性は今の動的言語100倍はオーバーにしても数倍はあるかも。

878 :デフォルトの名無しさん:2013/11/21(木) 19:31:50.71
今まで案が1つも出ないことから察して下さい

879 :デフォルトの名無しさん:2013/11/21(木) 19:39:41.94
一つだけ言っておこう。
ファーストコンタクトの時、地球を代表して会談に臨むのは地球王Javascriptだ。

880 :デフォルトの名無しさん:2013/11/21(木) 20:15:14.00
まあWebって分かりやすいしいいかもな
テレビ放送にも使われてるし
ごもっともだ

881 :デフォルトの名無しさん:2013/11/21(木) 20:20:21.05
ジャバスク水着は流行らない

882 :デフォルトの名無しさん:2013/11/21(木) 20:27:40.58
JavascriptなんてどうせLispに回帰すんだから最初からLisp乗せりゃよかったんだよ!

883 :デフォルトの名無しさん:2013/11/21(木) 20:32:45.54
変な視点だけど予約語のセンスはJavaを参考にしたかいがあったと思う
なのにgotoをES5で外しちゃって、再帰のためにES6で使える予約語が無くなって残念だったね

884 :デフォルトの名無しさん:2013/11/22(金) 02:08:15.75
githubの新規プロジェクト数やtrendを見る限り、
JavaScriptは現実にLL(それ以上を含めてもいい)で一番流行ってる
特にインドの技術者がどんどん使用を始めてるし、
そのうち仕事で使わざるを得ない時が来るだろうね
はぁ・・・

885 :デフォルトの名無しさん:2013/11/22(金) 02:12:54.23
JavaScriptって言ってもピンきり

886 :デフォルトの名無しさん:2013/11/22(金) 09:19:00.37
クライアントサイドでは趣味だろうが業務だろうが普通に使われているので、
今後はサーバーサイドにどの程度食い込めるかだろうな > JS
node.js界隈もhypeサイクルの幻滅期を乗り越えてRoRと同程度のポジションを
狙えるかが当面のマイルストーンかな。

887 :デフォルトの名無しさん:2013/11/22(金) 09:42:04.60
>>884
まぁその頃には最悪TypeScriptが1.0になってるだろうから動的地獄にハマることはないと思ってる

888 :デフォルトの名無しさん:2013/11/22(金) 12:55:20.61
>>887
どの言語を使っても君の脳みそは残念なままw
言語のせいにしてる間は進歩ナッシングw

889 :デフォルトの名無しさん:2013/11/22(金) 14:22:38.94
RubyやPerlと同様になってnpm地獄になるのは目に見えてる。
それに気が付かないのは新参だけ。

890 :デフォルトの名無しさん:2013/11/22(金) 14:37:14.28
>>888
もっといい言語がいくらでもあるのに。
マゾ?

891 :デフォルトの名無しさん:2013/11/22(金) 16:41:34.63
Hadoop事情で元々Javaが強い界隈で仕事をしているけれども、最近はScalaのプレゼンス
が凄く高まっているのを感じる。

MLやNLPを行う欧米のアカデミアに浸透していてそこからのスピンアウト技術が増えたのと、
関数型言語上の「動くDSL」を使ってワークフローを宣言的に記述させることで、フローの
静的解析や各部のプロファイリングなどを通じた最適化につなげるのに好都合とのこと。

特に後者はそういうフレームワークを開発しているグループに先日話を聞いて面白かった。
単に内部の実装技術としてだけでは無く、Scalaを利用して外部の開発者向けに積極的に
関数型のAPIを提供して利用してもらうという動きは今後も増えそう。

892 :デフォルトの名無しさん:2013/11/22(金) 17:07:14.95
scalaはなんであんな中途半端なんだろうな

893 :デフォルトの名無しさん:2013/11/22(金) 18:08:05.57
Rubyもインドの技術者に使われているので、業務で使わなければいけなくなる。
早めに勉強しとく必要がある。

894 :デフォルトの名無しさん:2013/11/22(金) 20:45:13.11
ガチでみんなClojureやれよ
あんないい嫁中々いないぞ?

895 :デフォルトの名無しさん:2013/11/22(金) 21:00:48.65
>>893
そんなインド人に頼まないといけないような仕事しばらくしないで良さそうだからやらんでいいわ

896 :デフォルトの名無しさん:2013/11/22(金) 21:07:22.60
関数型はメインストリームになるとは思えないね

897 :デフォルトの名無しさん:2013/11/22(金) 21:10:12.20
関数型って何がいいの?

898 :デフォルトの名無しさん:2013/11/22(金) 21:34:09.32
関数型というより
静的関数型がいい

899 :デフォルトの名無しさん:2013/11/22(金) 22:59:36.62
webとか並列実行じゃね

900 :デフォルトの名無しさん:2013/11/22(金) 23:02:46.32
Scalaの仕事をしてみたいな

901 :デフォルトの名無しさん:2013/11/23(土) 08:00:40.21
>>897
関数型やってますと言えば賢くみられる気分に浸れる。

902 :デフォルトの名無しさん:2013/11/23(土) 09:20:53.10
(関数型)やってる?
やってるやってる!

↑むしろバカっぽい感じするんだけど、そうでもないの??

903 :デフォルトの名無しさん:2013/11/23(土) 10:01:53.73
馬鹿っぽいのはオマエだ

904 :デフォルトの名無しさん:2013/11/23(土) 10:45:18.15
実際JVMは馬鹿に出来んな。

905 :デフォルトの名無しさん:2013/11/23(土) 20:57:57.06
良いとこどりしやすいから > JVM

ただ起動が遅いのとjar地獄(最近はpomのジャングルも)。
これだけは本当にどうにもならん。

906 :デフォルトの名無しさん:2013/11/23(土) 22:56:05.24
node.jsとかの非同期プログラミングも微妙
あれでモリモリ複雑なロジック書くのはお勧めできない

907 :デフォルトの名無しさん:2013/11/24(日) 02:32:00.65
そういう用途にはnode.jsを使わなければ良いだけ。

908 :デフォルトの名無しさん:2013/11/24(日) 02:51:15.95
nodeが便利なとこって何?
非同期とかならF#の方がよっぽど得手な気はするけど

909 :デフォルトの名無しさん:2013/11/24(日) 03:23:48.36
SMTP程度でも非同期だとものすごく乱雑な感じがしてくるよ。

910 :デフォルトの名無しさん:2013/11/24(日) 06:27:34.54
それは状態遷移を理解できてないだけw

911 :デフォルトの名無しさん:2013/11/24(日) 07:38:53.50
>>908
nodeにとって非同期な書き方は手段であって目的では無いと思うのね。
シングルスレッドでリクエストを捌くために非同期な書き方を必要とされているだけで。

生産性という観点からすればあえて非同期な書き方で書くのと普通に同期的な書き方で
書いて並列実行やスケジューリングは上位層に丸投げするのではどちらが書きやすいかが
問われると思うけど、概ね非同期な書き方はより面倒という評価じゃないのかな。

912 :デフォルトの名無しさん:2013/11/24(日) 08:03:51.66
>>911
んー、つうとF#がスキル的にも環境的にも使えるならそこでnodeを使う意味はないのかな

F#だと非同期にしたら効果的な箇所で、同期的な書き方とほぼ同じような感じでかける。

913 :デフォルトの名無しさん:2013/11/24(日) 08:52:08.66
F#で書くぐらいなら速度的にもOCamlのがいいんじゃないの

914 :デフォルトの名無しさん:2013/11/24(日) 09:16:17.88
目的によるがな。

915 :デフォルトの名無しさん:2013/11/24(日) 09:29:15.84
>>913
OCamlだと非同期に向いたモナドとかあるの?

916 :デフォルトの名無しさん:2013/11/24(日) 10:31:25.98
Lwtとか?

917 :デフォルトの名無しさん:2013/11/24(日) 11:48:09.29
関数バカの標本が集まったようだなw

918 :デフォルトの名無しさん:2013/11/24(日) 12:39:20.65
まあ、動的言語みたいないい加減なものほど流行るようじゃ
厳格な関数型言語なんて流行らないだろう

919 :デフォルトの名無しさん:2013/11/24(日) 13:15:11.63
厳格な言語が使い物になるという幻覚

920 :デフォルトの名無しさん:2013/11/24(日) 13:18:20.83
構築前に隅々まで見通せるという砂糖のように甘い思い込み
そこから目をそらし関数型は難しいという衒学趣味をひけらかす

921 :デフォルトの名無しさん:2013/11/24(日) 13:21:41.25
Bye Bye Ruby, Hello Scala

922 :デフォルトの名無しさん:2013/11/24(日) 13:23:35.82
>>921
仕事何やってるの?

いや、単に言語で遊んでるだけなら
簡単に乗り換えられるだろうねって思っただけ。
その言語が失敗しても、失うものは殆ど無いしね。

923 :デフォルトの名無しさん:2013/11/24(日) 13:23:39.82
>>919
開発進むと同時に仕様が変わることもあるし、柔軟性が大事だよね

924 :デフォルトの名無しさん:2013/11/24(日) 13:26:43.93
仕様変更があったとき、大切なのは柔軟性ではなく
安全に正しい設計に修正できる方法があるってことだよ。

仕様変更に無理やり対応して、どんどん設計とコードが
汚くなっていく。そういう柔軟性は不要

925 :デフォルトの名無しさん:2013/11/24(日) 13:46:49.24
>>924
つまり静的型の関数型は使い物にならないということだね。
関数型ではマトモな設計手法なんかないからね。

言語は安全を標榜していても、
プログラマは設計無用の天然カウボーイ、
それが関数型での開発の正体さw

926 :デフォルトの名無しさん:2013/11/24(日) 13:47:10.82
>>922
Twitterの話だよ

927 :デフォルトの名無しさん:2013/11/24(日) 13:54:25.37
>>925
> つまり静的型の関数型は

> マトモな設計手法なんかないからね。

「つまり」ってなに?
俺、静的型の関数型言語に
まともな手法がないなんて言ってないんだけど?

勝手に俺がそう言ったように見せかけるのやめてくれない?

928 :デフォルトの名無しさん:2013/11/24(日) 14:01:07.68
>>927
君、頭わるいね。w

929 :デフォルトの名無しさん:2013/11/24(日) 14:06:31.68
そもそもの話として、設計手法に言語が関係あるの?

930 :デフォルトの名無しさん:2013/11/24(日) 14:11:19.19
>>928
おいw 反論するのかと思ったら
それだけかよw

931 :デフォルトの名無しさん:2013/11/24(日) 14:11:45.60
>>929
あるよ。継承とか型とか言語によって違うから。

932 :デフォルトの名無しさん:2013/11/24(日) 14:20:56.12
継承や型が言語によって違っても
設計はそれとは無関係だよ。

関係あるという根拠も出てないしね。

933 :デフォルトの名無しさん:2013/11/24(日) 14:25:28.85
>>932
設計と関係ないという根拠も出てないじゃん。
何を根拠に無関係と言ってんだ。いいかげんなこと抜かすな。
var a = 1;
a = "a";
型がある言語ではできない芸当です。

934 :デフォルトの名無しさん:2013/11/24(日) 14:25:52.71
じゃあ関数型での実装に適した設計手法を挙げてみろw

935 :デフォルトの名無しさん:2013/11/24(日) 14:27:07.41
>>932
手続き型ベースの構造化分析設計の子孫は関数型とは決定的に合わないよ。
そんなこともわからないんじゃ、君は関数型も設計も、両方わかってないねw

936 :デフォルトの名無しさん:2013/11/24(日) 14:27:54.23
>>934
関数型は使わないなあ、難しいから。
動的言語なら簡単なんだが。

937 :デフォルトの名無しさん:2013/11/24(日) 14:30:14.69
>>933
それが退化だとわからない男の子って

938 :デフォルトの名無しさん:2013/11/24(日) 14:31:26.76
>>937
どこが?ねーどこが?
代数的データ型の代替として使えるだろ。
Javaのように中途半端な言語しか知らないとわからないだろうけどなw

939 :デフォルトの名無しさん:2013/11/24(日) 14:31:55.75
>>937
君ってよく「おまえは結論ありきだな」と言われるでしょ?

940 :デフォルトの名無しさん:2013/11/24(日) 14:35:22.82
>>933
> var a = 1;
> a = "a";
> 型がある言語ではできない芸当です。

ん?

「数値または文字」型 a = 1;
a = "a"

できるけど?

941 :デフォルトの名無しさん:2013/11/24(日) 14:36:27.18
関数型に適した設計手法なんて存在しないのに
「安全に正しい設計に修正できる方法がある」>>924
と思い込んでいる関数厨って本当にバカだねw

942 :デフォルトの名無しさん:2013/11/24(日) 14:36:30.80
>>940
やってみろよwJavaでコード書いてみろ。
さらっと嘘ついてんじゃねえぞ。

943 :デフォルトの名無しさん:2013/11/24(日) 14:38:53.62
>>942
Javaで書くならこんな感じかねぇ。

NumOrString a;
a.setValue(1);
a.setValue("a");

setValueの実装はオーバーロードで。

944 :デフォルトの名無しさん:2013/11/24(日) 14:40:15.13
やっぱりダメなのかしら
式を渡して結果をプリントするだけがプログラミングだと思い込んでいる男の子たちとは
理解し合えないものなのかしら

945 :デフォルトの名無しさん:2013/11/24(日) 14:41:09.41
>>943
は?そんなクソなコード思い浮かべてできるとぶっこいたのか?あ?
メソッド呼び出しとかバカじゃねw
NumOrStringの実装省いてんじゃねえぞw書けよちゃんと。

946 :デフォルトの名無しさん:2013/11/24(日) 14:43:05.56
>>945
君が最初の段階で気づかないのは仕方ない。
だけど、ここまでヒント上げて気づかない奴に
俺は興味ないかな。じゃあね。

947 :デフォルトの名無しさん:2013/11/24(日) 14:43:14.08
>>944
何を理解してほしいと思っているのかお前のプレゼンテーション能力が試されるときだな
お前の持てる力、全身全霊をかけて俺の固い頭を揺さぶってみろ!

948 :デフォルトの名無しさん:2013/11/24(日) 14:45:49.95
>>946
逃げたw きっと素敵なコードがあるんだろうと期待してたら
クソ丸出しのコード出してきやがったから戦慄しただけ、NumOrStringの
コードまでちゃんと載せろといったら一目散に逃げ出したw
最後にこんな言葉を残していきました。「俺は興味ないかな」 かっけーw 地獄のミサワさん現るw

949 :デフォルトの名無しさん:2013/11/24(日) 14:46:49.73
C#だったら、propertyの機能で
obj.value = 1 で
obj.setValue(1) と解釈されるから、

まさに、
> var a = 1;
> a = "a";
これがそのまま実装できるな。

950 :デフォルトの名無しさん:2013/11/24(日) 14:47:08.60
結論:関数型ではhello world以上のことを書こうとするなw

951 :デフォルトの名無しさん:2013/11/24(日) 14:47:21.07
>>948
弱い犬ほど(略

952 :デフォルトの名無しさん:2013/11/24(日) 14:48:32.45
>>949
状態を作る実装ってダサくないか?
静的関数で不変オブジェクト返すっていうのがスマートだろ。
動的言語厨の俺に指摘されてどうすんだっていうw

953 :デフォルトの名無しさん:2013/11/24(日) 14:48:33.94
>>951
ワロタw まさにw

954 :デフォルトの名無しさん:2013/11/24(日) 14:49:35.87
>>952
意味がわからん。

変数に代入する時点で
それがクラス型だろうが値型だろうが
状態を作ってるわけで同じことだろ。

何がいいたいんだ?

955 :デフォルトの名無しさん:2013/11/24(日) 14:52:14.18
>>952
もしかして状態を”変えられる”ことを
問題にしてるのか?

ならコンストラクタの初期化だけを認めて
setterなくせばいいんじゃね?

956 :デフォルトの名無しさん:2013/11/24(日) 14:52:30.52
>>910
具体的にどうやればいいの?

957 :デフォルトの名無しさん:2013/11/24(日) 14:52:40.87
関数型言語を叩く奴って芸歴の長い地味な経歴のプログラマに多い気がする

958 :デフォルトの名無しさん:2013/11/24(日) 14:52:41.93
静的厨について明らかになったこと
・設計技法がないくせに設計している気分になっている
・設計なんてしていない癖に設計していると嘘をつく
・静的型マンセーのくせに型付けされていないプロパティに代入してドヤ顔する

これって技術者失格ってこと?

959 :デフォルトの名無しさん:2013/11/24(日) 14:52:43.83
>>954
C#でもJavaでもいいんだが、NumOrStringの実装書いてみろよ。
オブジェクト作ってそのあと状態変えてるだろ。それが超絶ダセー昭和のコードだって言ってんだよ。
書いてみろよ。メソッドをプロパティに変えてお茶を濁すようなことするから成長しないんだよ。

960 :デフォルトの名無しさん:2013/11/24(日) 14:53:43.43
>>959
NumOrStringはライブラリにあります。
実装は隠蔽されて、使う側が気にすることではありません。

961 :デフォルトの名無しさん:2013/11/24(日) 14:54:47.58
>>955
そうだよ。激ダサなコード提示してヒント上げたとわけのわからない
こと抜かしてるバカに指摘してんだよ。

962 :デフォルトの名無しさん:2013/11/24(日) 14:56:11.43
>>961
へんなの?

型がある言語では実装不可能っていう話だっただろ?

実装可能と気づいた途端。
今度は、実装に文句つけるき?

まずは土下座して謝るべきだよね。
実装不可能じゃありませんでしたって。

963 :デフォルトの名無しさん:2013/11/24(日) 14:57:32.22
世の中には、自分が間違っていた時に
素直に謝ることが出来ない人もいるのです。

964 :デフォルトの名無しさん:2013/11/24(日) 14:57:48.01
>>960
それはライブラリの一般論。俺が言ってるのはNumOrStringの実装をここに書けってこと。
お前が言ってるのは詭弁っていって頭の悪い人間が使う逃げ口上。すごくダサいこと。
社会でやってはいけません。みんな冷めた目で君を見ることになる。

965 :デフォルトの名無しさん:2013/11/24(日) 14:58:22.46
> var a = 1;
> a = "a";
> 型がある言語ではできない芸当です。



実装不可能と知った途端
負け犬のようにわめき始めました。

966 :デフォルトの名無しさん:2013/11/24(日) 15:00:12.33
いや、素直に実装可能だと認めろよw

それが出来ない人は
社会でやっていけないぞ?

なんだろうね。自分が今どんだけ
気違いになってるのか気づいてないのかな?

967 :デフォルトの名無しさん:2013/11/24(日) 15:01:01.49
型がある言語でも書けるが

968 :デフォルトの名無しさん:2013/11/24(日) 15:01:02.69
ちょうど今、みんなが冷めた目で>>964を見ているところだw

969 :デフォルトの名無しさん:2013/11/24(日) 15:01:43.76
>>962
お前は実装可能の定義を変えてるだけ。
var a = 1;
a = "a";
俺が示したコードはこれだ。メソッド呼び出しなんて1ミリもない。
考えるまでもなくコードが全然違うじゃないか。だからお前は実装できなかったんだ。
土下座して謝れ。なんていうこともできてしまうわけでつまりはこれが会話のスレ違い。
言葉の再定義が行われるからこういうことが起こる。再代入の恐ろしさ、不変オブジェクトの
すばらしさはこういう日本語のやりとりからも学べるだろ。あれ、俺いますごくいいこと言ってね?

970 :デフォルトの名無しさん:2013/11/24(日) 15:02:41.18
C#ってa = 1が
setter呼び出しになるから
>>969のコードは実装可能。

971 :デフォルトの名無しさん:2013/11/24(日) 15:02:48.76
>>969
>メソッド呼び出しなんて1ミリもない。
ダウト。言語と"var"の意味による。

972 :デフォルトの名無しさん:2013/11/24(日) 15:03:13.44
型と関係ないってことに
まだ気づいていないのか。
哀れだな。

973 :デフォルトの名無しさん:2013/11/24(日) 15:03:48.19
>>967
じゃあ書いてみろよ、メソッド呼び出しの糞コードネタはすでに出たぞ、
とうぜんそれを踏まえて新たな切り口のネタがあるのだろうな、よし書いてみろ。

974 :デフォルトの名無しさん:2013/11/24(日) 15:03:54.07
頭が悪い。謝ることも出来ない。
わーわーわめく
社会不適合者

975 :デフォルトの名無しさん:2013/11/24(日) 15:04:10.28
>>960
つまり具体的な実装例を示すことができないってことかw

976 :デフォルトの名無しさん:2013/11/24(日) 15:04:57.39
逆に、型がない言語では実装不可能なことがあるよね。

int a = 1;
a = "a"; ← エラーになる。
型がない言語ではできない芸当です。

977 :デフォルトの名無しさん:2013/11/24(日) 15:05:44.17
>>973
オペレーターオーバーロードで書けるだろ。

978 :デフォルトの名無しさん:2013/11/24(日) 15:05:55.65
>>962
実装が示されていない以上、実装不可能だなw

静的厨はうそつきw

979 :デフォルトの名無しさん:2013/11/24(日) 15:06:28.19
>>976
それが人類の進歩の証だと気づかない男の子って

980 :デフォルトの名無しさん:2013/11/24(日) 15:06:46.95
>>976
君、言ってて恥ずかしくない?
何の恥ずかしさも感じないようなら、人間として終わってるよ。

981 :デフォルトの名無しさん:2013/11/24(日) 15:06:56.73
良く知らないけど、Haskellではこんなコードが通るみたい

main = do
  let x = 1
  let x = "a"
  print x

982 :デフォルトの名無しさん:2013/11/24(日) 15:07:13.14
>>970
は?コード書いてみろ、そういう官僚答弁のようなはぐらかしには
うんざりする、ちゃんとやれシロアリども。

>>971
言語と"var"の意味によるとするならば言語と"var"の意味によって
メソッド呼び出しなんて1ミリもなくなるのだから、
メソッド呼び出しが1ミリもない言語と"var"の意味の文脈であると知れ。

983 :デフォルトの名無しさん:2013/11/24(日) 15:07:18.13
まあまあ、落ち着け。

型がない言語には実装不可能なことがあるのだよ。

静的型付け言語の潜在開発生産性は今の100倍 ×5
http://toro.2ch.net/test/read.cgi/tech/1385273168/

984 :デフォルトの名無しさん:2013/11/24(日) 15:07:49.06
>>981
hidingって視点もあったね。
結局書けてるじゃん。

985 :デフォルトの名無しさん:2013/11/24(日) 15:08:57.05
スコープが違うだけなのに再代入できていると強弁するのって

人間として最低最悪のゴミ人間のやることだよね。恥を知れw

986 :デフォルトの名無しさん:2013/11/24(日) 15:08:59.11
>>981
こうなってるだけじゃないの
main = let x = 1 in let x = "a" in print x

987 :デフォルトの名無しさん:2013/11/24(日) 15:09:28.39
>>974
謝れ謝れうるせえ奴がいるな、謝罪を共用して牢屋ぶちこまれるのが流行ってるらしいが
お前の方がよっぽど社会不適合者、俺は動的言語が好きなただの常識人。

988 :デフォルトの名無しさん:2013/11/24(日) 15:10:32.54
あぁ、キチガイほど、
自分のほうが正しいって思うんだよ。
病院いってこい。

989 :デフォルトの名無しさん:2013/11/24(日) 15:12:08.36
静的厨はまだ自分の嘘をみとめないのか。

人間失格のクズ確定だなw

990 :デフォルトの名無しさん:2013/11/24(日) 15:12:22.20
>>973
http://ideone.com/Oh50C6

991 :デフォルトの名無しさん:2013/11/24(日) 15:12:51.51
>>976
脳みそシロアリに食われた白痴か?
そういう行為が生産性を落とすんだ。
エラーでたわーいわーいと遊んでる暇あったらコード書けタダ飯ぐらいが。

992 :デフォルトの名無しさん:2013/11/24(日) 15:12:59.19
>>990
糞コードワロタw

余計なものを書いてる時点で
それは実装したとはみなせない。

993 :デフォルトの名無しさん:2013/11/24(日) 15:14:04.17
関数動的オブジェクト指向の静的言語最強説

994 :デフォルトの名無しさん:2013/11/24(日) 15:14:25.91
うるせー

動的バンザイ!やったぞ勝利だ!

995 :デフォルトの名無しさん:2013/11/24(日) 15:14:55.98
>>990
c++はマルチパラダイムだから動的言語の範疇だ。
静的言語でやってみろ。

996 :デフォルトの名無しさん:2013/11/24(日) 15:16:16.95
>>995
声が震えてるぞw

997 :デフォルトの名無しさん:2013/11/24(日) 15:19:16.43
>>996
モニターから幻聴でも聴こえるのか?近くのパン屋さんに行ってパン切り包丁で
耳切り落としてもらえよ、モニターの調子良くなるんじゃねえの。

998 :デフォルトの名無しさん:2013/11/24(日) 15:19:54.28
>>997
顔が真っ赤だぞw

999 :デフォルトの名無しさん:2013/11/24(日) 15:20:00.03
>>1-1000 水面のサザナミ程度の隆起しかみられない浅い議論でしたね。

1000 :デフォルトの名無しさん:2013/11/24(日) 15:20:18.45
>>995
こんな名言を >>1000 で決められない男の子って

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

236 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)