やっぱり動的型付け言語は大規模開発で効率が悪い 2
せめて型を書いたときくらい厳密な型検査をしてほしいだけなのに > Dart
Hashable h = '1';
int n = h;
print(n + 1); # 出力：11
Hashable h = '1';
int n = h;
print(n + 1); # 出力：11
|
|
|
61 ：58：2011/10/22(土) 15:29:10.62
62 ：デフォルトの名無しさん：2011/10/22(土) 15:31:25.60
63 ：デフォルトの名無しさん：2011/10/22(土) 15:35:09.92
64 ：デフォルトの名無しさん：2011/10/22(土) 15:36:29.47
65 ：デフォルトの名無しさん：2011/10/22(土) 15:41:03.82
>>60にwarningも出さない言語が「完全な静的型付け」をサポートしてるとかありえん
66 ：デフォルトの名無しさん：2011/10/22(土) 15:43:36.94
Js_of_ocaml は OCaml と Javascript を混ぜて書けるよ
OCamlだけで書けば静的型安全だよ
Javascriptで書いた部分は動的型付けだよ
OCamlだけで書けば静的型安全だよ
Javascriptで書いた部分は動的型付けだよ
67 ：デフォルトの名無しさん：2011/10/22(土) 15:44:13.90
68 ：デフォルトの名無しさん：2011/10/22(土) 15:46:44.89
69 ：58：2011/10/22(土) 15:56:43.84
70 ：デフォルトの名無しさん：2011/10/22(土) 16:01:29.38
71 ：デフォルトの名無しさん：2011/10/22(土) 17:26:51.28
72 ：デフォルトの名無しさん：2011/10/22(土) 17:28:02.76
普通にACじゃだめか？ > 動的型→静的型
73 ：デフォルトの名無しさん：2011/10/22(土) 18:03:48.89
>>60は、HashableがintのSubtypeだから警告すら出ないんだね。
HashableをStringにすれば一応警告が出る。
HashableをStringにすれば一応警告が出る。
74 ：デフォルトの名無しさん：2011/10/22(土) 18:16:01.22
この程度は厳密に型をチェックするツールみたいなのが出てきて検出可能になるだろ
75 ：デフォルトの名無しさん：2011/10/22(土) 18:43:29.49
型情報がちゃんと書いてあるからできることだね。
76 ：デフォルトの名無しさん：2011/10/22(土) 18:54:59.05
プ
77 ：デフォルトの名無しさん：2011/10/22(土) 18:56:42.17
Dartが静的型？ふざけんなw
型付けできない式がある時点で静的型言語と言えるわけがねえだろw
型付けできない式がある時点で静的型言語と言えるわけがねえだろw
78 ：デフォルトの名無しさん：2011/10/22(土) 19:21:40.19
79 ：デフォルトの名無しさん：2011/10/22(土) 19:28:53.25
インターフェース全否定かよ
80 ：デフォルトの名無しさん：2011/10/22(土) 19:47:29.30
インターフェースは便利だよｗ
ただ、型推論無しの静的言語じゃ、変数をインターフェースだけで定義できないだろｗ
型推論の無いDartで変数の型を静的にチェックしてもらいたかったら、
具体的な型で変数を定義しろってことだ。
ただ、型推論無しの静的言語じゃ、変数をインターフェースだけで定義できないだろｗ
型推論の無いDartで変数の型を静的にチェックしてもらいたかったら、
具体的な型で変数を定義しろってことだ。
81 ：デフォルトの名無しさん：2011/10/22(土) 19:50:15.88
82 ：デフォルトの名無しさん：2011/10/22(土) 19:51:09.13
少なくとも>>60の例では、
式(n+1)の静的型intが誤解を生んでいるな。
これなら、静的型なんて無視して、動的型Stringのみを見るほうが
プログラムの動作を理解しやすい。
結論：Dartは静的型付言語ではなく、型注釈付き動的型付言語
式(n+1)の静的型intが誤解を生んでいるな。
これなら、静的型なんて無視して、動的型Stringのみを見るほうが
プログラムの動作を理解しやすい。
結論：Dartは静的型付言語ではなく、型注釈付き動的型付言語
83 ：デフォルトの名無しさん：2011/10/22(土) 19:53:23.38
84 ：デフォルトの名無しさん：2011/10/22(土) 19:54:26.74
+は数値だけじゃなく、文字列を結合する演算子でもあって、
片方にオブジェクト型が含まれていると、
toString()呼び出しで文字列として結合するようなもんかな。
片方にオブジェクト型が含まれていると、
toString()呼び出しで文字列として結合するようなもんかな。
85 ：デフォルトの名無しさん：2011/10/22(土) 19:55:02.94
>>83
intとstringがoperator+で足せるのはJavaやC#なんかもそうだ
好みの問題は別として、別におかしくない
問題は2行目だろｗ
int型の変数に代入してるのに、完全に何の意味もない
intとstringがoperator+で足せるのはJavaやC#なんかもそうだ
好みの問題は別として、別におかしくない
問題は2行目だろｗ
int型の変数に代入してるのに、完全に何の意味もない
86 ：デフォルトの名無しさん：2011/10/22(土) 19:56:57.09
int型の変数が'this'という値を持てて、それがエラーにすらならないのなら
Dartの静的型って屁の役にも立たないだろｗ
Dartの静的型って屁の役にも立たないだろｗ
87 ：デフォルトの名無しさん：2011/10/22(土) 19:57:01.29
変数の型は無視して、変数の中身のオブジェクトに従って+演算子が動作してるわけだ
88 ：デフォルトの名無しさん：2011/10/22(土) 19:58:27.14
89 ：デフォルトの名無しさん：2011/10/22(土) 20:00:10.92
>>86
単なる注釈だからな。そこが静的型付けと型注釈の決定的違い。
単なる注釈だからな。そこが静的型付けと型注釈の決定的違い。
90 ：デフォルトの名無しさん：2011/10/22(土) 20:01:09.50
Dartは本当に
int n = h;
のところで警告出さないのか？
int n = h;
のところで警告出さないのか？
91 ：デフォルトの名無しさん：2011/10/22(土) 20:01:26.61
intとStringがHashableのsubtypeだから何の警告も出ずに実行できてしまうわけで、
hの型を具体的なStringとかにしとけば、n=h;で一応警告がでる。
Dartの型システムがまるで役に立たないと言うわけでもない。
hの型を具体的なStringとかにしとけば、n=h;で一応警告がでる。
Dartの型システムがまるで役に立たないと言うわけでもない。
92 ：デフォルトの名無しさん：2011/10/22(土) 20:02:40.14
そもそも、Hashable って
どういう型なんだ？
どういう型なんだ？
93 ：デフォルトの名無しさん：2011/10/22(土) 20:03:04.40
JavaでいうObjectみたいなものなのでは？
94 ：デフォルトの名無しさん：2011/10/22(土) 20:06:03.19
>>90
すくなくとも今
http://www.dartlang.org/docs/getting-started/index.html
からWeb上で試せる実装では、
警告どころか実行時エラーにすらならない
すくなくとも今
http://www.dartlang.org/docs/getting-started/index.html
からWeb上で試せる実装では、
警告どころか実行時エラーにすらならない
95 ：デフォルトの名無しさん：2011/10/22(土) 20:06:13.81
subtypeやめますか
静的型やめますか
静的型やめますか
96 ：デフォルトの名無しさん：2011/10/22(土) 20:06:47.15
97 ：デフォルトの名無しさん：2011/10/22(土) 20:07:08.11
つうかさ、
int n = h;
はHashableからintへのナローキャストじゃないのか？
int n = h;
はHashableからintへのナローキャストじゃないのか？
98 ：デフォルトの名無しさん：2011/10/22(土) 20:08:00.14
>>96
自分の調べ方が足りないという自覚もないのか？
自分の調べ方が足りないという自覚もないのか？
99 ：デフォルトの名無しさん：2011/10/22(土) 20:08:17.89
>>91
Hashable -> int のcoercionはdowncastなわけだから、
型安全な言語なら、とうぜんそこで実行時型チェックするのが筋だろ
(C++でいうdynamic_cast<>やJavaのダウンキャスト）
Dartはベースが動的型言語である以上実行時型情報を持ってるはずなんだから
できないはずが無い
スルーしてintにそのまま入れるのがいいわけはないよ
Hashable -> int のcoercionはdowncastなわけだから、
型安全な言語なら、とうぜんそこで実行時型チェックするのが筋だろ
(C++でいうdynamic_cast<>やJavaのダウンキャスト）
Dartはベースが動的型言語である以上実行時型情報を持ってるはずなんだから
できないはずが無い
スルーしてintにそのまま入れるのがいいわけはないよ
100 ：デフォルトの名無しさん：2011/10/22(土) 20:10:35.71
>>98
世の中全てのことを知っていると言えるほど、傲慢じゃない
世の中全てのことを知っていると言えるほど、傲慢じゃない
101 ：デフォルトの名無しさん：2011/10/22(土) 20:13:13.02
>>100
Python type check decoratorでググレカス
Python type check decoratorでググレカス
102 ：デフォルトの名無しさん：2011/10/22(土) 20:15:12.69
103 ：デフォルトの名無しさん：2011/10/22(土) 20:15:54.55
>>99
正確には、値を変換しているわけじゃないから、coercionではなく、type conversionでしょ。
実行時に動的型検査するのが当然、には同意。
もっと言えば、静的型付けなら、コンパイル時に警告を出して当然。
正確には、値を変換しているわけじゃないから、coercionではなく、type conversionでしょ。
実行時に動的型検査するのが当然、には同意。
もっと言えば、静的型付けなら、コンパイル時に警告を出して当然。
104 ：デフォルトの名無しさん：2011/10/22(土) 20:16:49.48
105 ：デフォルトの名無しさん：2011/10/22(土) 20:16:58.63
HashableはPythonにあるな。オブジェクトのハッシュ値を返すメソッドを実装したインターフェース。
このインタフェースを実装してる型のオブジェクトは、
Pythonなら__hash__、DartならhashCode()で、オブジェクトのハッシュ値を返す。
このインタフェースを実装してる型のオブジェクトは、
Pythonなら__hash__、DartならhashCode()で、オブジェクトのハッシュ値を返す。
106 ：デフォルトの名無しさん：2011/10/22(土) 20:17:11.89
107 ：デフォルトの名無しさん：2011/10/22(土) 20:18:19.60
キャストしないと弾かれる、キャストしても実行時型が一致しなければ弾かれる
というのが普通だな
というのが普通だな
108 ：デフォルトの名無しさん：2011/10/22(土) 20:22:47.04
Dart、Web上の実行で色々試してみたが、ダウンキャストで警告が出ないのがおかしいんだなこれ。
class foo;
class bar extends foo;
で、
bar tmp = new foo;
ってのが警告無しでできてしまう。
まぁ多分Web上のコンパイラがおかしいんだろう。本物のコンパイラなら、オプションなりでちゃんと警告ないしはエラーが出ると思いたい
class foo;
class bar extends foo;
で、
bar tmp = new foo;
ってのが警告無しでできてしまう。
まぁ多分Web上のコンパイラがおかしいんだろう。本物のコンパイラなら、オプションなりでちゃんと警告ないしはエラーが出ると思いたい
109 ：デフォルトの名無しさん：2011/10/22(土) 20:24:32.96
Webドカタ言語を目指すのなら、警告だけでは意味ないだろうな。
ちゃんとコンパイルエラーにしないと。
ちゃんとコンパイルエラーにしないと。
110 ：デフォルトの名無しさん：2011/10/22(土) 20:27:22.69
>>101
なんじゃこりゃああ！
なんじゃこりゃああ！
111 ：デフォルトの名無しさん：2011/10/22(土) 20:27:48.27
>>109
お前はなにドカタ言語を使ってるの？
お前はなにドカタ言語を使ってるの？
112 ：デフォルトの名無しさん：2011/10/22(土) 20:29:51.50
109じゃないけど、PHP使っててローカル変数に型指定ができなくて発狂中ですｗ
インテリセンスがきかねーんだ
インテリセンスがきかねーんだ
113 ：デフォルトの名無しさん：2011/10/22(土) 20:37:47.43
>>108
残念ながらダウンキャストで警告が出ないのはDartのドキュメントに書かれてる
残念ながらダウンキャストで警告が出ないのはDartのドキュメントに書かれてる
114 ：デフォルトの名無しさん：2011/10/22(土) 20:39:40.74
115 ：デフォルトの名無しさん：2011/10/22(土) 20:43:40.19
そして動的型付けがベースだから変数束縛時の型チェックはしてない、という事か
116 ：デフォルトの名無しさん：2011/10/22(土) 20:44:13.75
何故haXeのような静的型付け言語にしなかったんだGoogle……
117 ：デフォルトの名無しさん：2011/10/22(土) 20:44:16.53
動的型付けはデメリットしか
もたらさないな。
もたらさないな。
118 ：デフォルトの名無しさん：2011/10/22(土) 20:48:26.64
119 ：デフォルトの名無しさん：2011/10/22(土) 20:50:52.28
結論が出たようだな。
動的型付け言語が世界を支配する！
動的型付け言語が世界を支配する！
120 ：デフォルトの名無しさん：2011/10/22(土) 20:59:01.38
監査機関がいるから、不正がバレるんだ。
監査機関がいなければ、不正は起こらない！
監査機関がいなければ、不正は起こらない！
121 ：デフォルトの名無しさん：2011/10/22(土) 21:01:28.54
122 ：デフォルトの名無しさん：2011/10/22(土) 21:03:53.85
Dartの聞き齧り情報で鬼の首を取ったように
「ググルが静的型付けが優れていると証明した！」
と言いふらしていたのが、
Dartの型注釈のダメなところが指摘されたとたんに
「Dartは動的型だからダメダメだぁー!」
楽しそうな人生だねw
「ググルが静的型付けが優れていると証明した！」
と言いふらしていたのが、
Dartの型注釈のダメなところが指摘されたとたんに
「Dartは動的型だからダメダメだぁー!」
楽しそうな人生だねw
123 ：デフォルトの名無しさん：2011/10/22(土) 21:04:02.41
int add(int x, int y) => x + y;
main() {
Hashable x = 'Hello, ';
Hashable y = 'World!';
print(add(x, y)); # -> Hello, World!を印字する
}
正直こんな型注釈が一体何の役に立つのか理解に苦しむわ……
main() {
Hashable x = 'Hello, ';
Hashable y = 'World!';
print(add(x, y)); # -> Hello, World!を印字する
}
正直こんな型注釈が一体何の役に立つのか理解に苦しむわ……
124 ：デフォルトの名無しさん：2011/10/22(土) 21:04:39.98
ほとんど意味の無い監査や認証の事務に労力をすり減らす企業は実在する。
125 ：デフォルトの名無しさん：2011/10/22(土) 21:06:41.44
>>124
静的型付言語でシコシコ書いてるドカタのことだね！
静的型付言語でシコシコ書いてるドカタのことだね！
126 ：デフォルトの名無しさん：2011/10/22(土) 21:07:42.66
>>123
なんでHashableが流行ってるんだよｗ普通にStringって書けよ警告してもらえるからｗ
なんでHashableが流行ってるんだよｗ普通にStringって書けよ警告してもらえるからｗ
127 ：デフォルトの名無しさん：2011/10/22(土) 21:09:16.02
ダウンキャストに警告が出ないのが問題の本質だからHashableは関係ない
128 ：デフォルトの名無しさん：2011/10/22(土) 21:09:37.46
129 ：デフォルトの名無しさん：2011/10/22(土) 21:09:59.60
これ、結局動的型情報で動いてるわけだから
intという型情報を用いた最適化も無理じゃん
stringが渡ってきたらstringの加算をやるんだろ？
静的型注釈が本気で何の役にも立ってない
intという型情報を用いた最適化も無理じゃん
stringが渡ってきたらstringの加算をやるんだろ？
静的型注釈が本気で何の役にも立ってない
130 ：デフォルトの名無しさん：2011/10/22(土) 21:10:54.01
煩い死ね
131 ：デフォルトの名無しさん：2011/10/22(土) 21:11:09.30
>>129
ま、ドキュメント程度の意味しかないだろうね。
ま、ドキュメント程度の意味しかないだろうね。
132 ：デフォルトの名無しさん：2011/10/22(土) 21:17:20.03
133 ：デフォルトの名無しさん：2011/10/22(土) 21:18:07.92
HaskellとPython
134 ：デフォルトの名無しさん：2011/10/22(土) 21:20:25.37
Smalltalkの仕事があったけど毎月400時間労働の酷い仕事だったよ
135 ：デフォルトの名無しさん：2011/10/22(土) 21:22:32.09
136 ：デフォルトの名無しさん：2011/10/22(土) 21:48:08.21
137 ：デフォルトの名無しさん：2011/10/22(土) 21:48:11.08
138 ：デフォルトの名無しさん：2011/10/22(土) 21:52:52.20
>>122
そこで過ちを認められず、意固地になるほうがおかしいと思うが？
そこで過ちを認められず、意固地になるほうがおかしいと思うが？
139 ：デフォルトの名無しさん：2011/10/22(土) 22:06:00.27
140 ：デフォルトの名無しさん：2011/10/22(土) 22:16:11.96
規格pdf一通り読んだんだが、ダウンキャストに警告ださないって明言されてるの何ページめ？
141 ：デフォルトの名無しさん：2011/10/22(土) 22:30:09.16
ググる様のドキュメントにはしっかり動的型付言語と書いてあるんだが…
142 ：デフォルトの名無しさん：2011/10/22(土) 22:31:38.67
>>141
そりゃ、動的か静的かと言われれば動的に決まってんだろ。JS互換あんだし
そりゃ、動的か静的かと言われれば動的に決まってんだろ。JS互換あんだし
143 ：デフォルトの名無しさん：2011/10/22(土) 22:35:42.59
>>140
規格には、どういったケースでstatic type warningを出すかだけが書かれてるようだね。
ダウンキャストについてはDartのトップページ -> Articles -> Optional Types in Dart
って進んだところにある The static checker というパラグラフに書いてある。
規格には、どういったケースでstatic type warningを出すかだけが書かれてるようだね。
ダウンキャストについてはDartのトップページ -> Articles -> Optional Types in Dart
って進んだところにある The static checker というパラグラフに書いてある。
144 ：デフォルトの名無しさん：2011/10/22(土) 22:41:40.07
145 ：デフォルトの名無しさん：2011/10/22(土) 22:48:56.33
>>144
使いたくなければ静的型付け使わなければいいだけなのに、駄目な部分が加えられたとはこれいかに？？
使いたくなければ静的型付け使わなければいいだけなのに、駄目な部分が加えられたとはこれいかに？？
146 ：デフォルトの名無しさん：2011/10/22(土) 22:53:48.27
>>145は他人のコードの面倒見たりしないんだろうな…
147 ：デフォルトの名無しさん：2011/10/22(土) 22:54:10.71
>>143
あれ？
The static checker のさっそく最初に
String s1 = '9';
String s2 = '1';
...
int n = s1 + s2;
print(n);
これはstatic checkerが警告を発する
って書いてあるぞ？
あれ？
The static checker のさっそく最初に
String s1 = '9';
String s2 = '1';
...
int n = s1 + s2;
print(n);
これはstatic checkerが警告を発する
って書いてあるぞ？
148 ：デフォルトの名無しさん：2011/10/22(土) 22:55:16.42
>>147
それStringだからじゃね
それStringだからじゃね
149 ：デフォルトの名無しさん：2011/10/22(土) 22:55:35.14
>>147
あたりまえだろ、intとStringは直接のsubtype関係にないのだから。
あたりまえだろ、intとStringは直接のsubtype関係にないのだから。
すまん、ダウンキャストとはまた別問題だった
>>148ですな
>>148ですな
151 ：デフォルトの名無しさん：2011/10/22(土) 23:01:18.68
既存の古典的な型システムとは違い、ダウンキャストの際は警告を発しませんって明記されてた。
要らんｗ
要らんｗ
152 ：デフォルトの名無しさん：2011/10/22(土) 23:02:52.14
153 ：デフォルトの名無しさん：2011/10/22(土) 23:08:54.47
型推論によって型注釈が無くても型安全な言語すらあるのに、
型注釈を付けても型安全じゃないDart……
型注釈を付けても型安全じゃないDart……
154 ：デフォルトの名無しさん：2011/10/22(土) 23:15:18.56
155 ：デフォルトの名無しさん：2011/10/22(土) 23:21:58.42
結局Dartの一連の話では、静的厨の無知っぷりが引き立ったな。
Dartのどこが原則静的型だかw
Dartのどこが原則静的型だかw
156 ：デフォルトの名無しさん：2011/10/22(土) 23:23:07.29
157 ：デフォルトの名無しさん：2011/10/22(土) 23:29:12.37
警告出すためのマーカーみたいなもんだな
158 ：デフォルトの名無しさん：2011/10/22(土) 23:31:48.05
よくわかんないんだけど結局Dartはゆるまんってこと？
159 ：デフォルトの名無しさん：2011/10/22(土) 23:32:58.77
Dart作った本人が大規模システムじゃ静的な型付けが必要って言ってるんだから。Dartについてはこれ以上どうこう言っても仕方ないだろう。
160 ：デフォルトの名無しさん：2011/10/22(土) 23:34:45.89
グーグル様の御威光ふりかざしてドヤ顔で静的型マンセーしていたのが
掌かえしたように逆ギレしてグーグルをドヤ顔よばわり
おもしろいねえw
掌かえしたように逆ギレしてグーグルをドヤ顔よばわり
おもしろいねえw
161 ：デフォルトの名無しさん：2011/10/22(土) 23:35:56.24
162 ：デフォルトの名無しさん：2011/10/22(土) 23:38:07.03
>>159
でもDart自体はどう転んでも動的型付言語だわな。
「大規模開発だろうが、動的型付けをベースに考えざるを得ない。
型注釈ぐらいなら動的型の柔軟性を損わない範囲内で許すけど。」
というグーグルの判断でしょw
でもDart自体はどう転んでも動的型付言語だわな。
「大規模開発だろうが、動的型付けをベースに考えざるを得ない。
型注釈ぐらいなら動的型の柔軟性を損わない範囲内で許すけど。」
というグーグルの判断でしょw
163 ：デフォルトの名無しさん：2011/10/22(土) 23:38:49.40
>>161
ひれ伏さなかったから、君の無知さ加減が暴かれたわけだがw
ひれ伏さなかったから、君の無知さ加減が暴かれたわけだがw
164 ：デフォルトの名無しさん：2011/10/22(土) 23:39:51.90
>>162
そりゃ、ブラウザ上で動く（実質）唯一無二の言語であるJSに相乗りする以上、動的型付けをベースに考えざるを得ないだろ
そりゃ、ブラウザ上で動く（実質）唯一無二の言語であるJSに相乗りする以上、動的型付けをベースに考えざるを得ないだろ
165 ：デフォルトの名無しさん：2011/10/22(土) 23:42:31.76
>>164
トランスータなんだから、JSを吐こうがネイティブコード吐こうが、Dart自体は静的型付けにできる。
極端に言えば、JSでHaskell処理系を実装すれば完全に静的型付けされたコードをJS上で動かせるだろ。
トランスータなんだから、JSを吐こうがネイティブコード吐こうが、Dart自体は静的型付けにできる。
極端に言えば、JSでHaskell処理系を実装すれば完全に静的型付けされたコードをJS上で動かせるだろ。
166 ：デフォルトの名無しさん：2011/10/22(土) 23:42:50.13
なんで動的厨って『動的はこう素晴らしい』って語らないで『静的厨は頭が悪い』みたいな人格攻撃しかしないの？
静的厨としては、動的厨が動的の素晴らしさをアピールできるなら、是非それにのりたいのだが
静的厨としては、動的厨が動的の素晴らしさをアピールできるなら、是非それにのりたいのだが
167 ：デフォルトの名無しさん：2011/10/22(土) 23:43:39.71
ところがどっこい、Javascriptにコンバート出来れば良いなら
haXeやjs_of_ocamlのような静的型付け言語がある
haXeやjs_of_ocamlのような静的型付け言語がある
168 ：デフォルトの名無しさん：2011/10/22(土) 23:43:42.57
それは静的厨が頼まれてもいないのに馬鹿晒すからだろwww
169 ：デフォルトの名無しさん：2011/10/22(土) 23:45:41.98
170 ：デフォルトの名無しさん：2011/10/22(土) 23:45:49.76
171 ：デフォルトの名無しさん：2011/10/22(土) 23:47:09.88
172 ：デフォルトの名無しさん：2011/10/22(土) 23:47:35.19
>>169
そうなんだよな。静的型付けはドカタ言語としてはピッタリなんだよ。
そうなんだよな。静的型付けはドカタ言語としてはピッタリなんだよ。
173 ：デフォルトの名無しさん：2011/10/22(土) 23:49:48.02
一人、動的厨を装った荒らしが混じってるみたいだな
トリップつけてくんねーかな
トリップつけてくんねーかな
174 ：デフォルトの名無しさん：2011/10/22(土) 23:50:35.32
>>173
だからさあ、馬鹿にされたくなかったら、馬鹿なこと言わなきゃいいの。わかった？
だからさあ、馬鹿にされたくなかったら、馬鹿なこと言わなきゃいいの。わかった？
175 ：デフォルトの名無しさん：2011/10/22(土) 23:51:32.54
176 ：デフォルトの名無しさん：2011/10/22(土) 23:53:10.62
自分の経験は示さずに他人に職歴示せと言う。ドカタって本当に馬鹿だね。
177 ：デフォルトの名無しさん：2011/10/22(土) 23:53:21.99
178 ：デフォルトの名無しさん：2011/10/22(土) 23:56:51.15
むしろ静的を望むのはドカタに制約を課したい人間だと思うんだが……
179 ：デフォルトの名無しさん：2011/10/22(土) 23:58:39.45
これからは、C#も動的型付け言語に含まれるわけだな。
180 ：デフォルトの名無しさん：2011/10/22(土) 23:59:27.34
静的か動的かに関係なく、
アーキテクチャってものをしっかり考えている所（良いところ）は
自然と開発のルールが出来る。それがいわゆる制約なわけ。
これはアジャイル開発でも同じ事。
何も考えずに適当に好きかって作っていいのは
自分一人プロジェクトだけ。
アーキテクチャってものをしっかり考えている所（良いところ）は
自然と開発のルールが出来る。それがいわゆる制約なわけ。
これはアジャイル開発でも同じ事。
何も考えずに適当に好きかって作っていいのは
自分一人プロジェクトだけ。
181 ：デフォルトの名無しさん：2011/10/23(日) 00:01:05.57
emscriptenなんて使うとガチのCがjsになるぞw
開発速度は動的な言語のが高いし柔軟性あるし
折衷案的な選択だわな
互換性に縛られてるJSをオーバーホールするには
ありな仕様だと思うけどね
開発速度は動的な言語のが高いし柔軟性あるし
折衷案的な選択だわな
互換性に縛られてるJSをオーバーホールするには
ありな仕様だと思うけどね
182 ：デフォルトの名無しさん：2011/10/23(日) 00:02:59.99
> 開発速度は動的な言語のが高いし
それは小さいプログラムだけだよ。
システムとは呼べないような。
それは小さいプログラムだけだよ。
システムとは呼べないような。
183 ：デフォルトの名無しさん：2011/10/23(日) 00:04:02.27
いや、大規模開発で動的型付けより静的型付けが優れているのは、Googleに言われるまでもなく、当たり前のことだから。
184 ：デフォルトの名無しさん：2011/10/23(日) 00:04:30.80
185 ：デフォルトの名無しさん：2011/10/23(日) 00:06:51.53
>>183
その当たり前を納得しない動的厨がいたので、じゃあGoogleのDartでドヤ！ってやったらDartがひどい有様だったので逆ドヤされたのが今の状況ｗ
その当たり前を納得しない動的厨がいたので、じゃあGoogleのDartでドヤ！ってやったらDartがひどい有様だったので逆ドヤされたのが今の状況ｗ
186 ：デフォルトの名無しさん：2011/10/23(日) 00:07:09.62
数十行のファイルが2−3枚とか、そのレベルなら動的型付けの言語の方が開発速度速いと思うよ。確かに。
187 ：デフォルトの名無しさん：2011/10/23(日) 00:09:49.89
Dartについては不満もあるけど、ブラウザの対応を考慮せずにJSとDartとどちらか自由に選べるというなら、俺は断然Dartを取るね。
RubyとかPythonと比べてもDartの方が良いかもしれない。Dart向けのライブラリだったりドキュメントだったりの充実に期待を込めてだけど。
RubyとかPythonと比べてもDartの方が良いかもしれない。Dart向けのライブラリだったりドキュメントだったりの充実に期待を込めてだけど。
188 ：デフォルトの名無しさん：2011/10/23(日) 00:10:49.42
WebPageにちょっとしたギミックを埋め込みたい。
程度だったら、確かに静的型宣言とかはパワー過剰気味なんだよな
でもそんな小さな仕事、仕事として来ないからなあ・・・
程度だったら、確かに静的型宣言とかはパワー過剰気味なんだよな
でもそんな小さな仕事、仕事として来ないからなあ・・・
189 ：デフォルトの名無しさん：2011/10/23(日) 00:14:17.35
大規模だとどうしても全体がつかみにくくなる。
そういう場合静的だと情報の把握のスピードが違うんだよね。
なにがどれに依存していてどこで書き換えられてとか
影響範囲の追跡がかなり簡単になる。
仮にdataなんて名前のグローバル変数を使っていたとしても、（あくまで仮だからねｗ）
そこに書きこむコードはほんの数秒で判明するだろう。
そういう場合静的だと情報の把握のスピードが違うんだよね。
なにがどれに依存していてどこで書き換えられてとか
影響範囲の追跡がかなり簡単になる。
仮にdataなんて名前のグローバル変数を使っていたとしても、（あくまで仮だからねｗ）
そこに書きこむコードはほんの数秒で判明するだろう。
190 ：デフォルトの名無しさん：2011/10/23(日) 00:14:37.30
191 ：デフォルトの名無しさん：2011/10/23(日) 00:17:49.49
> 1人専任で設計からリリースまで半年ぐらいの条件でも
それ小さくね？
設計からリリースまでで半年なら
開発は2人月ぐらいだろ？
それ小さくね？
設計からリリースまでで半年なら
開発は2人月ぐらいだろ？
192 ：デフォルトの名無しさん：2011/10/23(日) 00:18:32.90
一人だと、他人の書いた未知コードを把握する必要もないしね。
193 ：デフォルトの名無しさん：2011/10/23(日) 00:19:32.14
なんか静的な型の言語に幻想持ってるのが多いな
perlとかphpで泣き見たんか
ヘボに混じってデスマやらされたか。
perlとかphpで泣き見たんか
ヘボに混じってデスマやらされたか。
194 ：デフォルトの名無しさん：2011/10/23(日) 00:23:29.84
>>193
PHPで泣き見たわｗ
PHPで泣き見たわｗ
195 ：デフォルトの名無しさん：2011/10/23(日) 00:23:43.41
196 ：デフォルトの名無しさん：2011/10/23(日) 00:24:57.62
>>190
ああ、そうだね。それは同意する。
でも、実際にはプログラマーが型を意識できない、スコープを意識できない、だから動的型付けな言語を採用するってパターンなんだよね。
ウェブの開発やってるとそうだとしか思えない。
ああ、そうだね。それは同意する。
でも、実際にはプログラマーが型を意識できない、スコープを意識できない、だから動的型付けな言語を採用するってパターンなんだよね。
ウェブの開発やってるとそうだとしか思えない。
197 ：デフォルトの名無しさん：2011/10/23(日) 00:26:07.43
ウェブ開発者を馬鹿にするなｗ
動的型付けばかり使ってるわけじゃねーよｗ．
動的型付けばかり使ってるわけじゃねーよｗ．
198 ：デフォルトの名無しさん：2011/10/23(日) 00:28:50.67
動的型付けプログラマのほうが型付けやスコープで痛い目に合いやすく、
それゆえに詳しいことが多い。
「痛くなければ覚えませぬ」
それゆえに詳しいことが多い。
「痛くなければ覚えませぬ」
199 ：デフォルトの名無しさん：2011/10/23(日) 00:29:25.05
>>193
> なんか静的な型の言語に幻想持ってるのが多いな
逆だ。他人が作った動的型付け言語で作られたシステムを修正するときに
影響範囲がわかりづらいなどの問題点を嫌というほど味わった。
静的型付けの幻想ではなく、動的型付けに幻滅したんだよ。
そもそも昔からCやC++やJavaなどの型付き言語をメインの開発言語で
やってきたんだ。今更幻想なんてものはない。
ただ俺にとってはそれが標準なだけ。
> なんか静的な型の言語に幻想持ってるのが多いな
逆だ。他人が作った動的型付け言語で作られたシステムを修正するときに
影響範囲がわかりづらいなどの問題点を嫌というほど味わった。
静的型付けの幻想ではなく、動的型付けに幻滅したんだよ。
そもそも昔からCやC++やJavaなどの型付き言語をメインの開発言語で
やってきたんだ。今更幻想なんてものはない。
ただ俺にとってはそれが標準なだけ。
200 ：デフォルトの名無しさん：2011/10/23(日) 00:30:35.17
201 ：デフォルトの名無しさん：2011/10/23(日) 00:35:00.39
世の中には、痛くてもそれが好きな人や
痛くてもすぐに忘れてしまう人がいることを
知っていおいたほうがいい。
痛くてもすぐに忘れてしまう人がいることを
知っていおいたほうがいい。
202 ：デフォルトの名無しさん：2011/10/23(日) 00:35:24.10
動的だと適当にやっても当面は動くからなあ。
動かなくなったときには、どうしようもなくなっている。
動かなくなったときには、どうしようもなくなっている。
203 ：デフォルトの名無しさん：2011/10/23(日) 00:37:00.32
>>200
別に型付けの静的/動的だけが言語の選択条件じゃないから
別に型付けの静的/動的だけが言語の選択条件じゃないから
204 ：デフォルトの名無しさん：2011/10/23(日) 00:39:33.78
205 ：デフォルトの名無しさん：2011/10/23(日) 00:41:05.45
ま、言語仕様だけで言語を選ぶなら
いまどきJavaなんて誰も選択しないわなw
いまどきJavaなんて誰も選択しないわなw
206 ：デフォルトの名無しさん：2011/10/23(日) 00:42:56.04
あー、またただの言語オタクがｗ
207 ：デフォルトの名無しさん：2011/10/23(日) 00:43:39.10
影響範囲が解りづらいってよく言うけどそんなに違うか？
確かにIDE駆使した静的型付け言語に比べりゃ多少手間はかかるかもしれんけど
絞り切れないなんて状況は滅多に無いと思うが
確かにIDE駆使した静的型付け言語に比べりゃ多少手間はかかるかもしれんけど
絞り切れないなんて状況は滅多に無いと思うが
208 ：デフォルトの名無しさん：2011/10/23(日) 00:44:53.49
ドカタだからスパゲティコード量産してるに決まってるじゃん
209 ：デフォルトの名無しさん：2011/10/23(日) 00:50:27.60
>>207
全然違うよ
ほんの数秒で、全プロジェクトの中から
あるクラスのメソッドを的確に調べてくれたりする。
もちろんそのメソッド名がgetであったりしても、無関係のgetと迷うことはない。
動的型付け言語だと対処法的に冗長な名前をつけることがよくある。
タイプ数が増えて、めんどくせぇｗ
全然違うよ
ほんの数秒で、全プロジェクトの中から
あるクラスのメソッドを的確に調べてくれたりする。
もちろんそのメソッド名がgetであったりしても、無関係のgetと迷うことはない。
動的型付け言語だと対処法的に冗長な名前をつけることがよくある。
タイプ数が増えて、めんどくせぇｗ
210 ：デフォルトの名無しさん：2011/10/23(日) 00:53:36.14
Dartの一件からも分かるように、ドカタはドキュメントも読まずに
思い込みで決め付けて容易に間違える。
こういった輩は静的型付けで縛る以外に無いだろう。
思い込みで決め付けて容易に間違える。
こういった輩は静的型付けで縛る以外に無いだろう。
211 ：デフォルトの名無しさん：2011/10/23(日) 00:54:58.77
さっきからドカタドカタとうるさい奴に
何のシステム作っているのか聞いたが
レスがないようだ。
何のシステム作っているのか聞いたが
レスがないようだ。
212 ：デフォルトの名無しさん：2011/10/23(日) 01:02:07.01
経験が浅いと、多人数でシステムを作った経験がないと
書くことにばかり目が言ってしまう。
実際は、書くことよりも読むことのほうがずっと多い。
過去に自分が書いたコードにバグがある。
他人の書いたソースコードを修正する。
他人が書いたソースコードをレビューする。
読むときのことを考えているかという点を見れば
その人がどれくらい出来るの人なのかがわかる。
書くことにばかり目が言ってしまう。
実際は、書くことよりも読むことのほうがずっと多い。
過去に自分が書いたコードにバグがある。
他人の書いたソースコードを修正する。
他人が書いたソースコードをレビューする。
読むときのことを考えているかという点を見れば
その人がどれくらい出来るの人なのかがわかる。
213 ：デフォルトの名無しさん：2011/10/23(日) 01:03:58.22
ま、Javaは冗長で可読性も最悪ですがねw
214 ：デフォルトの名無しさん：2011/10/23(日) 01:05:19.84
なんか必死にJavaに対抗しようとしている虫が一匹いるなｗ
215 ：デフォルトの名無しさん：2011/10/23(日) 01:07:07.51
Javaといえばドカタの代名詞だからな
216 ：デフォルトの名無しさん：2011/10/23(日) 01:10:30.45
まともな型推論が無い静的型付け言語は、
型の記述が冗長になりすぎて読みにくかったりするのは確かにあるね。
その冗長な記述を読み解く方が近道だったりもすることも多いが。
型の記述が冗長になりすぎて読みにくかったりするのは確かにあるね。
その冗長な記述を読み解く方が近道だったりもすることも多いが。
217 ：デフォルトの名無しさん：2011/10/23(日) 01:14:31.77
さっきからドカタドカタとうるさい奴に
何のシステム作っているのか聞いたが
レスがないようだ。
何のシステム作っているのか聞いたが
レスがないようだ。
218 ：デフォルトの名無しさん：2011/10/23(日) 01:21:36.38
ドカタじゃないのは大抵趣味グラマーだから
219 ：デフォルトの名無しさん：2011/10/23(日) 01:23:59.24
dartはdartネイティブで実行する場合は少しはマシなのかな
JSにトランスレートする場合も原理的にはもう少し型チェックを厳格にできそうだけど
多分そうしないのは効率だよな
JSにトランスレートする場合も原理的にはもう少し型チェックを厳格にできそうだけど
多分そうしないのは効率だよな
220 ：デフォルトの名無しさん：2011/10/23(日) 06:54:43.72
型推論は言語仕様に含める必要ないだろ
ツールやエディタがやればいい
コーディングルールにしても余計なスペースなんて入れずとも
エディタが調整して見やすくするのが正しい進化だった
読みやすさのためにスペースを何度も叩くのはバカらしい
言語仕様に何もかもを含めすぎてる
もっとツールやIDEのことを考えろ
ツールやエディタがやればいい
コーディングルールにしても余計なスペースなんて入れずとも
エディタが調整して見やすくするのが正しい進化だった
読みやすさのためにスペースを何度も叩くのはバカらしい
言語仕様に何もかもを含めすぎてる
もっとツールやIDEのことを考えろ
221 ：デフォルトの名無しさん：2011/10/23(日) 07:01:31.86
自動インデントとかエディタ内蔵フォーマッタなんて
20年以上前からある機能
型推論とフォーマットを同列にしてる時点で
20年以上前からある機能
型推論とフォーマットを同列にしてる時点で
222 ：デフォルトの名無しさん：2011/10/23(日) 07:26:24.03
ドカタと呼ばれると、自分のことだと認識しているドカタがいるようだwww
223 ：デフォルトの名無しさん：2011/10/23(日) 07:32:45.09
結局、動的型を叩いてるバカって、自分の力量の無さを言語のせいにしているだけか。
ドカタが「オマエノカイハツケイケンヲイエー！」とか喚いていたから、
まずはお前の経験を書くのが先だろと訊いてみたのに、未だ回答がない。
つまり、そういうことだ。
ドカタが「オマエノカイハツケイケンヲイエー！」とか喚いていたから、
まずはお前の経験を書くのが先だろと訊いてみたのに、未だ回答がない。
つまり、そういうことだ。
224 ：デフォルトの名無しさん：2011/10/23(日) 07:36:37.75
225 ：デフォルトの名無しさん：2011/10/23(日) 07:41:14.03
動的型付けのメリットは大規模になると何もなくなる。
226 ：デフォルトの名無しさん：2011/10/23(日) 07:42:37.49
大規模開発で動的型言語を使いにくいのは、人を集めるのが大変だから。
動的言語で良質なコードを書けるプログラマは単価がドカタの2倍はいくし、
工期全体でスケジュールを押さえるのが難しい。
技術的興味のないプロジェクトは断わるか、ふっかけるのが普通だし。
ドカタ動員で押し切れたほうが管理する側はラクなんだよ。
動的言語で良質なコードを書けるプログラマは単価がドカタの2倍はいくし、
工期全体でスケジュールを押さえるのが難しい。
技術的興味のないプロジェクトは断わるか、ふっかけるのが普通だし。
ドカタ動員で押し切れたほうが管理する側はラクなんだよ。
227 ：デフォルトの名無しさん：2011/10/23(日) 07:45:08.29
>>225
君が言う動的型のメリットと、なぜそれが大規模で消えるのかを説明せよ
君が言う動的型のメリットと、なぜそれが大規模で消えるのかを説明せよ
228 ：デフォルトの名無しさん：2011/10/23(日) 07:52:00.85
型推論が静的言語で普及した現在、動的言語のいいところなんてない。
229 ：デフォルトの名無しさん：2011/10/23(日) 08:06:25.49
230 ：デフォルトの名無しさん：2011/10/23(日) 08:12:25.99
>>228
真の型推論が実装されているのはMLやHaskellといった一部の関数型言語だけ
とても型推論が普及したなんて言える現状ではない
また、C#/Java/C++のような「動的型付けな静的言語」のいい加減さを考えれば、
動的型付け言語の開発効率の良さは検討に値する
真の型推論が実装されているのはMLやHaskellといった一部の関数型言語だけ
とても型推論が普及したなんて言える現状ではない
また、C#/Java/C++のような「動的型付けな静的言語」のいい加減さを考えれば、
動的型付け言語の開発効率の良さは検討に値する
231 ：デフォルトの名無しさん：2011/10/23(日) 08:14:00.26
静的型言語で表現可能なクラス = 型推論可能な表現のクラス ⊂ 動的型言語で表現可能なクラス
例： Yコンビネータ
例： Yコンビネータ
232 ：デフォルトの名無しさん：2011/10/23(日) 08:18:46.19
>>230
Haskellの型推論は完全じゃないよ。MLの型推論は完全だけど。
Haskellの型推論は完全じゃないよ。MLの型推論は完全だけど。
233 ：デフォルトの名無しさん：2011/10/23(日) 08:21:25.42
言葉に詰まって発言者の人格や職をなじる奴はバカだし
効率は価値があるけど動的静的の選択には価値がない
型推論と開発ツールの二択なら開発ツールの方が効率がいいから価値がある
開発効率を考えるなら全ての型推論を持つ言語はVBに劣る
カードの性質を理解してない奴が語るな
型推論という戦術はIDEという戦略の前では無価値に等しい
効率は価値があるけど動的静的の選択には価値がない
型推論と開発ツールの二択なら開発ツールの方が効率がいいから価値がある
開発効率を考えるなら全ての型推論を持つ言語はVBに劣る
カードの性質を理解してない奴が語るな
型推論という戦術はIDEという戦略の前では無価値に等しい
234 ：デフォルトの名無しさん：2011/10/23(日) 08:24:16.70
>>233
ドカタにとってはそうなんだろうね
ドカタにとってはそうなんだろうね
235 ：デフォルトの名無しさん：2011/10/23(日) 08:28:55.40
MSの小部屋に籠って出てこないで下さい
236 ：デフォルトの名無しさん：2011/10/23(日) 08:39:53.35
>>220
ツールやエディタがそれぞれ個別に型推論を実装するなんて無駄もいいところだろ
きちんと言語仕様で決めて、コンパイラが型推論するほうが良いに決まってる
エディタが型情報を必要とするならコンパイラに問い合わせれば良い
ツールやエディタがそれぞれ個別に型推論を実装するなんて無駄もいいところだろ
きちんと言語仕様で決めて、コンパイラが型推論するほうが良いに決まってる
エディタが型情報を必要とするならコンパイラに問い合わせれば良い
237 ：デフォルトの名無しさん：2011/10/23(日) 08:41:38.98
>>234
>言葉に詰まって発言者の人格や職をなじる奴はバカだし
崇高な芸術プログラミングを追及するなら、lispという結末が見えている
選民思想に染まったコミュニティは常に少数派になる
それを主張する奴が、地雷が埋まってるとわかってて踏む美学の持ち主なら
その選択肢の末は滅びしかないだろう
ランチェスターの法則を理解するなら
多数のドカタに価値があって
崇高なプログラミングの価値はそれ以下だということも理解できる
まずは多数のドカタを上回る成果を挙げられる何かを提示してみなさい
それができないなら多数のドカタが最強ということだ
>言葉に詰まって発言者の人格や職をなじる奴はバカだし
崇高な芸術プログラミングを追及するなら、lispという結末が見えている
選民思想に染まったコミュニティは常に少数派になる
それを主張する奴が、地雷が埋まってるとわかってて踏む美学の持ち主なら
その選択肢の末は滅びしかないだろう
ランチェスターの法則を理解するなら
多数のドカタに価値があって
崇高なプログラミングの価値はそれ以下だということも理解できる
まずは多数のドカタを上回る成果を挙げられる何かを提示してみなさい
それができないなら多数のドカタが最強ということだ
238 ：デフォルトの名無しさん：2011/10/23(日) 08:49:57.78
>>236
型推論にはコストに見合った価値がない
それを実装し活用する労力以上の価値がない
型推論を言語仕様に含めることで
プログラミング言語、開発ツールそれら全てに実装が必要となる
その実装コストを上回る成果が型推論の採用で得られるとは思えない
その程度ならコード整形ツールのおまけ機能として実装すればいいだけ
俺の主観では
型推論を採用した理由はIDEの実装を困難にすることで
競争を発生させること
IDEによる開発者の囲い込みを行うことで
開発ツールから利益を得ること
つまりバカを騙して効率低下させて金を得ようという
そういう悪意にしか見えない
簡単にIDE作れたら金儲けできないよね
型推論にはコストに見合った価値がない
それを実装し活用する労力以上の価値がない
型推論を言語仕様に含めることで
プログラミング言語、開発ツールそれら全てに実装が必要となる
その実装コストを上回る成果が型推論の採用で得られるとは思えない
その程度ならコード整形ツールのおまけ機能として実装すればいいだけ
俺の主観では
型推論を採用した理由はIDEの実装を困難にすることで
競争を発生させること
IDEによる開発者の囲い込みを行うことで
開発ツールから利益を得ること
つまりバカを騙して効率低下させて金を得ようという
そういう悪意にしか見えない
簡単にIDE作れたら金儲けできないよね
239 ：デフォルトの名無しさん：2011/10/23(日) 08:53:44.74
240 ：デフォルトの名無しさん：2011/10/23(日) 09:06:39.70
>>239
お前は無駄を主張した
だから型推論を採用する方が無駄になるという反論をすればいいのか
>型推論にはコストに見合った価値がない
つまり無駄だ
企業は営利目的で動く
企業が主導している言語の仕様は営利を優先する
金になるなら言語仕様を歪める選択肢がある
java c# dart全て企業主導
なら当然、余計なものが含まれる可能性がある
あの人たちが純粋にすばらしい言語を作り出すために動いている
そう考えるのはちょっと甘いんじゃないの
型推論が罠仕様だと疑う俺の考えの方が自然だよ
最強言語cに型推論がない
これだけでも十分すぎる理由だ
存在が理不尽で無駄でメリットがなくても、多数に受け入れられたら
それは金になるし存在理由になる
そういうものはこの世界にありふれている
型推論は世界にありふれている無駄な金儲けの手段になりうる
お前は無駄を主張した
だから型推論を採用する方が無駄になるという反論をすればいいのか
>型推論にはコストに見合った価値がない
つまり無駄だ
企業は営利目的で動く
企業が主導している言語の仕様は営利を優先する
金になるなら言語仕様を歪める選択肢がある
java c# dart全て企業主導
なら当然、余計なものが含まれる可能性がある
あの人たちが純粋にすばらしい言語を作り出すために動いている
そう考えるのはちょっと甘いんじゃないの
型推論が罠仕様だと疑う俺の考えの方が自然だよ
最強言語cに型推論がない
これだけでも十分すぎる理由だ
存在が理不尽で無駄でメリットがなくても、多数に受け入れられたら
それは金になるし存在理由になる
そういうものはこの世界にありふれている
型推論は世界にありふれている無駄な金儲けの手段になりうる
241 ：デフォルトの名無しさん：2011/10/23(日) 09:13:38.84
最強言語C++には型推論があるがな
242 ：デフォルトの名無しさん：2011/10/23(日) 09:16:01.59
243 ：デフォルトの名無しさん：2011/10/23(日) 09:17:24.74
型推論があるほうがコードが簡潔
http://queue.acm.org/detail.cfm?id=2038036
http://queue.acm.org/detail.cfm?id=2038036
244 ：デフォルトの名無しさん：2011/10/23(日) 09:27:50.96
型の記述を排除するデメリットがあまりにも大きすぎる
型推論を採用するメリットはほんの少し、それすらもツールで補える
可読性の低い一行に価値があるというのならそれを使えばいい
俺は可読性の高い十行に価値があると考えるからそれを使う
IDEや開発ツールを駆使して長くて読みやすいコードを書く
俺は可読性の高い十行を理解する人の方が
人類の中では圧倒的多数派であると確信するし
そっちの方が目的達成の近道だと考えてるだけ
型推論を採用するメリットはほんの少し、それすらもツールで補える
可読性の低い一行に価値があるというのならそれを使えばいい
俺は可読性の高い十行に価値があると考えるからそれを使う
IDEや開発ツールを駆使して長くて読みやすいコードを書く
俺は可読性の高い十行を理解する人の方が
人類の中では圧倒的多数派であると確信するし
そっちの方が目的達成の近道だと考えてるだけ
245 ：デフォルトの名無しさん：2011/10/23(日) 09:35:27.42
型推論が銀の弾丸であるかのように思い込んでいる静的厨がいるようだが、
おそらくマトモなサイズのコードを書いたことないのだろう。
HaskellやMLで型推論に頼ったコードの型エラーを直すのは、
動的型言語の実行時エラーを直すよりずっと難しい。
だから、本当にHaskellやMLでまとまったサイズのコードを書く香具師は
できるだけ型を明示的に宣言する。
おそらくマトモなサイズのコードを書いたことないのだろう。
HaskellやMLで型推論に頼ったコードの型エラーを直すのは、
動的型言語の実行時エラーを直すよりずっと難しい。
だから、本当にHaskellやMLでまとまったサイズのコードを書く香具師は
できるだけ型を明示的に宣言する。
246 ：デフォルトの名無しさん：2011/10/23(日) 09:44:24.92
型推論で省略できるけど、別に型を書いてもいい
つーか、トップレベルの関数は型注釈を書くのが当たり前
ただし、自分で一から型を書かなくても、処理系が推論した型を出力させて、
それをそのままコードとして使うなんて日常的に行われてる
OCamlは型エラーがでても、その直前までの型推論の結果を出力してくれる
（そしてエディタで表示できる）から、型注釈を省略してもデバッグが大変にはならない
使った事も無いのに聞きかじりでテキトーなこと書くなよ
つーか、トップレベルの関数は型注釈を書くのが当たり前
ただし、自分で一から型を書かなくても、処理系が推論した型を出力させて、
それをそのままコードとして使うなんて日常的に行われてる
OCamlは型エラーがでても、その直前までの型推論の結果を出力してくれる
（そしてエディタで表示できる）から、型注釈を省略してもデバッグが大変にはならない
使った事も無いのに聞きかじりでテキトーなこと書くなよ
247 ：デフォルトの名無しさん：2011/10/23(日) 10:00:10.96
248 ：デフォルトの名無しさん：2011/10/23(日) 10:14:39.20
静的厨には型安全厨だけじゃなくて
型注釈厨（別名Dart厨）がいるから
型注釈厨（別名Dart厨）がいるから
249 ：デフォルトの名無しさん：2011/10/23(日) 10:15:31.79
動的と静的と中立
250 ：デフォルトの名無しさん：2011/10/23(日) 10:16:26.22
251 ：デフォルトの名無しさん：2011/10/23(日) 10:23:25.28
このスレにおける分類（-> は支持する言語）
静的型安全性が欲しい人 -> 静的型付け言語
型注釈を強制したい人 -> 型推論の無い静的型付け言語
簡潔に書きたい/読みたい人 -> 動的型付け言語、型推論のある言語
実行時メタプログラミングしたい人 -> 動的型付け言語
静的型安全性が欲しい人 -> 静的型付け言語
型注釈を強制したい人 -> 型推論の無い静的型付け言語
簡潔に書きたい/読みたい人 -> 動的型付け言語、型推論のある言語
実行時メタプログラミングしたい人 -> 動的型付け言語
252 ：デフォルトの名無しさん：2011/10/23(日) 10:25:49.31
253 ：デフォルトの名無しさん：2011/10/23(日) 10:28:04.40
型推論は、簡潔に書くためのもので、無理して型を指定しないのは本末転倒。
型が指定できないのは、問題外。
型が指定できないのは、問題外。
254 ：デフォルトの名無しさん：2011/10/23(日) 10:32:33.21
>>253
型注釈を明示できない言語って無いだろうから杞憂では？ > 型推論
型注釈を明示できない言語って無いだろうから杞憂では？ > 型推論
255 ：デフォルトの名無しさん：2011/10/23(日) 10:42:13.79
それ以前の話として、関数型言語スタイルでは
インスタンス変数からメソッドを補完することが無いから、
補完そのものが難しくない
（動的型付け言語でも"モジュール名.関数名"の補完は難しくないのと同じ）
少なくとも関数型言語では型推論はメリットのほうが遥かに大きい
OOPにおける型推論がどうあるべきかは、まだ多いに議論の余地があるだろう
型推論しないのも一つの答えかもしれない
インスタンス変数からメソッドを補完することが無いから、
補完そのものが難しくない
（動的型付け言語でも"モジュール名.関数名"の補完は難しくないのと同じ）
少なくとも関数型言語では型推論はメリットのほうが遥かに大きい
OOPにおける型推論がどうあるべきかは、まだ多いに議論の余地があるだろう
型推論しないのも一つの答えかもしれない
256 ：デフォルトの名無しさん：2011/10/23(日) 11:23:32.41
個人的にはC#のvarがスコープぐらいでの挙動で十分かなー。
257 ：デフォルトの名無しさん：2011/10/23(日) 11:33:25.62
型が指定できるだけで何がいいんだ？
PHP最高だろ
PHP最高だろ
258 ：デフォルトの名無しさん：2011/10/23(日) 11:37:29.64
> 型が指定できるだけで何がいいんだ？
そこからかなりいろんなことが出来るようになるよ。
型がなくても人間には自明だから、いいじゃないかというやつもいる。
でもコンピュータにとって自明にすることで、
様々なコンピュータ処理が可能になる。
そこからかなりいろんなことが出来るようになるよ。
型がなくても人間には自明だから、いいじゃないかというやつもいる。
でもコンピュータにとって自明にすることで、
様々なコンピュータ処理が可能になる。
259 ：デフォルトの名無しさん：2011/10/23(日) 11:39:22.15
PHPも5.4からIntとかのプリミティブ型もタイプヒンティングで指定出来るようになる（らしい）。トレイトとか無名関数なんかより、よっぽど重要な機能だと思う。
260 ：デフォルトの名無しさん：2011/10/23(日) 11:39:38.97
補完に使う「モジュール」とチェックに使う「型」を区別できない言語が
動的型付け言語を批判する資格があるだろうか
動的型付け言語を批判する資格があるだろうか
261 ：デフォルトの名無しさん：2011/10/23(日) 11:49:39.07
別にモジュールを補完に使う。型はチェックに使うとか決まってないだろｗ
それに、モジュールと型が区別できない言語なんて聞いたことがない。
それに、モジュールと型が区別できない言語なんて聞いたことがない。
262 ：デフォルトの名無しさん：2011/10/23(日) 12:01:51.87
静的型付け言語は処理が追いやすいっていうけど
最近は大規模な開発になるとフレームワークがオブジェクトの生成を隠蔽したり
共通の処理はインターフェースや基底クラスを使って記述したりするから
あんまり追いやすいって感じはしないな
型うんぬんよりフレームワークやパッケージなんかの基礎知識のほうが重要だと思う
最近は大規模な開発になるとフレームワークがオブジェクトの生成を隠蔽したり
共通の処理はインターフェースや基底クラスを使って記述したりするから
あんまり追いやすいって感じはしないな
型うんぬんよりフレームワークやパッケージなんかの基礎知識のほうが重要だと思う
263 ：デフォルトの名無しさん：2011/10/23(日) 12:03:32.22
静的型付けオブジェクト指向言語では、単一ディスパッチと
名前空間の指定（クラスは一種の名前空間として機能する）を
同じ構文 obj.func() でやってしまう
動的型付け言語でこれと同じ事をすると、型宣言を省略したついでに
名前空間の宣言も省略することになるので、補完ができなくなる
しかし、本来型と名前空間は別のものなので、マルチメソッドを採用して
module.func(obj) という構文を使えば補完できるようになる
名前空間の指定（クラスは一種の名前空間として機能する）を
同じ構文 obj.func() でやってしまう
動的型付け言語でこれと同じ事をすると、型宣言を省略したついでに
名前空間の宣言も省略することになるので、補完ができなくなる
しかし、本来型と名前空間は別のものなので、マルチメソッドを採用して
module.func(obj) という構文を使えば補完できるようになる
264 ：デフォルトの名無しさん：2011/10/23(日) 12:06:13.81
CでWordPressと同等のものを作ってみろよ
効率委員だろ
効率委員だろ
265 ：デフォルトの名無しさん：2011/10/23(日) 12:13:24.64
>>262
言ってることがずれてるぞ。
オブジェクトの生成をフレームワークがしたからといって
その生成を入れる変数に型は書いてある。
インターフェースや基底クラスを使って記述しているならば、
そのインターフェースや基底クラスを使ってるクラスを
見つけ出さないといけないわけだが、
その見付け出す行為も、型があれば簡単にできる。
基礎知識は大事だからというがそれは別の話で関係ない。型は大事だ。
○○の方が重要だからといって、もう一方の方はどうでもいいと思わせるのは
ただのミスリード。
言ってることがずれてるぞ。
オブジェクトの生成をフレームワークがしたからといって
その生成を入れる変数に型は書いてある。
インターフェースや基底クラスを使って記述しているならば、
そのインターフェースや基底クラスを使ってるクラスを
見つけ出さないといけないわけだが、
その見付け出す行為も、型があれば簡単にできる。
基礎知識は大事だからというがそれは別の話で関係ない。型は大事だ。
○○の方が重要だからといって、もう一方の方はどうでもいいと思わせるのは
ただのミスリード。
266 ：デフォルトの名無しさん：2011/10/23(日) 12:15:29.90
267 ：デフォルトの名無しさん：2011/10/23(日) 12:17:51.26
>>262の言ってることは確かにずれてる。そういう次元の話じゃない。
268 ：デフォルトの名無しさん：2011/10/23(日) 12:23:52.99
269 ：デフォルトの名無しさん：2011/10/23(日) 12:42:14.17
○○で××と同等のものを作ってみろよ
効率委員だろ
○○に嫌いな言語を
××に無茶な要求を入れてください
効率委員だろ
○○に嫌いな言語を
××に無茶な要求を入れてください
270 ：デフォルトの名無しさん：2011/10/23(日) 12:46:30.90
○○でLinuxと同等のものを作ってみろよ
公立医員だろ？
公立医員だろ？
271 ：デフォルトの名無しさん：2011/10/23(日) 12:46:52.52
272 ：デフォルトの名無しさん：2011/10/23(日) 12:48:49.03
>>271
こんなの
オープンソースのJAVAで作られたCMS「Apache Lenya」
http://blog.verygoodtown.com/2010/03/open-source-java-cms-apache-lenya/
エンタープライズでも使えるJava製CMS「Magnolia」
http://www.moongift.jp/2008/09/magnolia/
こんなの
オープンソースのJAVAで作られたCMS「Apache Lenya」
http://blog.verygoodtown.com/2010/03/open-source-java-cms-apache-lenya/
エンタープライズでも使えるJava製CMS「Magnolia」
http://www.moongift.jp/2008/09/magnolia/
273 ：デフォルトの名無しさん：2011/10/23(日) 13:09:11.33
Java名物のXML地獄
274 ：デフォルトの名無しさん：2011/10/23(日) 13:11:05.89
それ、5年ぐらい前の知識だろｗ
やっぱ止まってんのな。否定する人ってその頃から知識が。
やっぱ止まってんのな。否定する人ってその頃から知識が。
275 ：デフォルトの名無しさん：2011/10/23(日) 13:18:06.48
アノテーション使うようになっても大差なくてワロスwww
276 ：デフォルトの名無しさん：2011/10/23(日) 13:25:14.93
>>272
それしかねえのかよ
それしかねえのかよ
277 ：デフォルトの名無しさん：2011/10/23(日) 14:03:53.92
動的型言語で10-20年前に開拓したものを再実装するのが静的ドカタ言語の使い方
278 ：デフォルトの名無しさん：2011/10/23(日) 14:20:00.14
279 ：デフォルトの名無しさん：2011/10/23(日) 14:25:12.54
>>272がJavaでCMS作ってくれるらしいから期待しとこうぜ
280 ：デフォルトの名無しさん：2011/10/23(日) 15:01:45.27
動的言語で何が開拓されたんだ？
281 ：デフォルトの名無しさん：2011/10/23(日) 15:09:36.59
リスト操作系は大概動的言語のが強いイメージがあるな
282 ：デフォルトの名無しさん：2011/10/23(日) 15:16:16.14
283 ：デフォルトの名無しさん：2011/10/23(日) 15:26:37.29
284 ：デフォルトの名無しさん：2011/10/23(日) 15:28:22.27
LispもSmalltalkも動的型付け言語
285 ：デフォルトの名無しさん：2011/10/23(日) 15:29:37.15
関数型と動的型の区別もついてないのかな。
286 ：デフォルトの名無しさん：2011/10/23(日) 16:06:46.85
287 ：デフォルトの名無しさん：2011/10/23(日) 16:08:45.88
動的型付けの方が言語の実装は簡単。
288 ：デフォルトの名無しさん：2011/10/23(日) 16:10:20.08
だから？
289 ：デフォルトの名無しさん：2011/10/23(日) 16:15:19.76
>>286
成る程、確かにそうだな
成る程、確かにそうだな
290 ：デフォルトの名無しさん：2011/10/23(日) 16:27:58.11
291 ：デフォルトの名無しさん：2011/10/23(日) 16:34:50.75
292 ：デフォルトの名無しさん：2011/10/23(日) 16:38:42.54
MVC
メタプログラミング/レフレクション
イベント駆動
連想配列
も、だいたいLISP/Scheme/Smalltalk界隈だな。
メタプログラミング/レフレクション
イベント駆動
連想配列
も、だいたいLISP/Scheme/Smalltalk界隈だな。
293 ：デフォルトの名無しさん：2011/10/23(日) 16:42:41.70
294 ：デフォルトの名無しさん：2011/10/23(日) 16:58:47.47
GCもLISP発だっけ？
295 ：デフォルトの名無しさん：2011/10/23(日) 17:07:21.49
Ｌｉｓｐと言えば、昔のＣｏｍｍｏｎＬｉｓｐは手続き型言語の機能を取り込んでたらしいね。
（forとかの実装はその頃らしい）
何の言語の影響受けたんだろ？Ｆｏｒｔｌａｎ？
（forとかの実装はその頃らしい）
何の言語の影響受けたんだろ？Ｆｏｒｔｌａｎ？
296 ：デフォルトの名無しさん：2011/10/23(日) 17:10:00.23
297 ：デフォルトの名無しさん：2011/10/23(日) 17:19:56.44
>>294
1960に論文が出て、後にLISPに実装された。
1960に論文が出て、後にLISPに実装された。
298 ：デフォルトの名無しさん：2011/10/23(日) 18:45:32.38
やっぱり、静的型付け言語の方が
生産性高いな。
具体的なデータもあるんだから
しょうがない。
生産性高いな。
具体的なデータもあるんだから
しょうがない。
299 ：デフォルトの名無しさん：2011/10/23(日) 18:56:10.38
どうして生産性が高いといえるのか根拠を述べなさい
300 ：デフォルトの名無しさん：2011/10/23(日) 19:02:07.46
大規模だとどうしても全体がつかみにくくなる。
そういう場合静的だと情報の把握のスピードが違うんだよね。
なにがどれに依存していてどこで書き換えられてとか
影響範囲の追跡がかなり簡単になる。
仮にdataなんて名前のグローバル変数を使っていたとしても、（あくまで仮だからねｗ）
そこに書きこむコードはほんの数秒で判明するだろう。
そういう場合静的だと情報の把握のスピードが違うんだよね。
なにがどれに依存していてどこで書き換えられてとか
影響範囲の追跡がかなり簡単になる。
仮にdataなんて名前のグローバル変数を使っていたとしても、（あくまで仮だからねｗ）
そこに書きこむコードはほんの数秒で判明するだろう。
301 ：デフォルトの名無しさん：2011/10/23(日) 19:11:28.69
RubyもPython も言語仕様に静的型を全面導入しても問題なさそうだが。
302 ：デフォルトの名無しさん：2011/10/23(日) 19:20:01.08
303 ：デフォルトの名無しさん：2011/10/23(日) 19:22:28.47
304 ：デフォルトの名無しさん：2011/10/23(日) 19:23:06.85
コンパイル時メタプログラミングといっても、
C++みたいなのはだめだよ。
C++は数学的と言うか、定義でメタプログラミングしている。
はっきり言って、定義でメタプログラミングするのは難しい。
じゃなくて、コードでメタプログラミングする。
コンパイル時に（実行時メタプログラミングみたいに）
コードを実行し、そのコードで書き換える。
C++みたいなのはだめだよ。
C++は数学的と言うか、定義でメタプログラミングしている。
はっきり言って、定義でメタプログラミングするのは難しい。
じゃなくて、コードでメタプログラミングする。
コンパイル時に（実行時メタプログラミングみたいに）
コードを実行し、そのコードで書き換える。
305 ：デフォルトの名無しさん：2011/10/23(日) 19:26:53.90
コンパイル時メタプログラミングが
出来る言語としてPerlがある。
ただ惜しいことに、静的型付け言語ではない。
出来る言語としてPerlがある。
ただ惜しいことに、静的型付け言語ではない。
306 ：デフォルトの名無しさん：2011/10/23(日) 19:27:34.03
>>300
> 仮にdataなんて名前のグローバル変数を使っていたとしても、（あくまで仮だからねｗ）
> そこに書きこむコードはほんの数秒で判明するだろう。
え？まさか、動的型付け言語では、それができないと思っている？
おまえみたいのがいるから静的型はドカタとか無知とか言われるんだよ (-_-#)
> 仮にdataなんて名前のグローバル変数を使っていたとしても、（あくまで仮だからねｗ）
> そこに書きこむコードはほんの数秒で判明するだろう。
え？まさか、動的型付け言語では、それができないと思っている？
おまえみたいのがいるから静的型はドカタとか無知とか言われるんだよ (-_-#)
307 ：デフォルトの名無しさん：2011/10/23(日) 19:28:32.06
>>302
少なくともPythonの場合、型デコレータはコンパイル時メタプログラミングで実装されているが？
少なくともPythonの場合、型デコレータはコンパイル時メタプログラミングで実装されているが？
308 ：デフォルトの名無しさん：2011/10/23(日) 19:33:31.29
309 ：デフォルトの名無しさん：2011/10/23(日) 19:36:04.39
だから身内のアフォを黙らせてんだよ
310 ：デフォルトの名無しさん：2011/10/23(日) 19:55:11.85
PHPに仕事を奪われて肩身の狭い思いをしているJavaerの先輩こんばんわｗ
311 ：デフォルトの名無しさん：2011/10/23(日) 20:05:49.44
PHPはウェブ界のVBと言われるほど普及してる。
312 ：デフォルトの名無しさん：2011/10/23(日) 20:18:47.06
昨日の話がDartスレにも飛び火していたみたいだな
313 ：デフォルトの名無しさん：2011/10/23(日) 21:18:51.71
なんで、Apache Projectが作るものって
Javaが多いのか考えたことある？
Javaが多いのか考えたことある？
314 ：デフォルトの名無しさん：2011/10/23(日) 23:16:58.97
なんでAmazonがPerlをよく使うのか
考えたことある？
考えたことある？
315 ：デフォルトの名無しさん：2011/10/23(日) 23:24:13.68
316 ：デフォルトの名無しさん：2011/10/24(月) 02:56:59.28
PHPって、Javaとか.NETとは競合してないだろう。多分、PythonとかRuby使いたいなあと思いつつ、仕方なくPHP使ってる感じだろう。
317 ：デフォルトの名無しさん：2011/10/24(月) 03:34:36.79
PerlとPHPは通称ウェブドカタ言語だからｗ
318 ：デフォルトの名無しさん：2011/10/24(月) 07:10:33.01
JavaはGosling著の"The Feel of Java"(1997)において「ブルーカラーのための言語」と明記されてる
つまり最初からドカタのための言語として設計されてる
だからJavaドカタがドカタなのは正しい姿なんだよ
つまり最初からドカタのための言語として設計されてる
だからJavaドカタがドカタなのは正しい姿なんだよ
319 ：デフォルトの名無しさん：2011/10/24(月) 09:57:16.83
マスコミによるブルーカラー＝ドカタ、という刷り込みを信じ込んでる人は、ホワイトカラー犯罪課が何故あるのか知らないだろうな。
当時のアメリカのブルーカラーは、生産現場に近い、ぐらいの意味。
当時は単純な事務計算は機械化が進んでいたが、より広い分野の生産現場で使える適切な言語がなかった。
当時のアメリカのブルーカラーは、生産現場に近い、ぐらいの意味。
当時は単純な事務計算は機械化が進んでいたが、より広い分野の生産現場で使える適切な言語がなかった。
320 ：デフォルトの名無しさん：2011/10/24(月) 10:21:59.56
動的言語で大規模プロジェクトのシェアあるのってなに？
321 ：デフォルトの名無しさん：2011/10/24(月) 10:36:52.93
グローバル変数の件で無知をさらしたので
必死になって話をそらしてるんですね、わかります
必死になって話をそらしてるんですね、わかります
322 ：デフォルトの名無しさん：2011/10/24(月) 12:52:38.34
効率でまともな事言ってるのはIDEに好意的な連中だけだな
他の連中は人格攻撃や揚げ足取りばかりで聞いてられない
結論は出たね
他の連中は人格攻撃や揚げ足取りばかりで聞いてられない
結論は出たね
323 ：デフォルトの名無しさん：2011/10/24(月) 13:11:47.72
誤)まともな事言ってる
正)自分の耳に心地よいだけ
正)自分の耳に心地よいだけ
324 ：デフォルトの名無しさん：2011/10/24(月) 13:30:12.80
JavaでWordPressやDrupalやXOOPなど高機能なCMSがない理由を教えてください＾＾
スレタイワロター
ずいぶん譲歩してきたな
一般的な手法での大規模開発では効率悪いよ
JAVAなんかと同じ方法で大規模開発しようとしたら乙ル
動的言語で大規模開発やるなら、ファイル単位でかなり細かく分ける必要がある
設計できる子が少ない
ずいぶん譲歩してきたな
一般的な手法での大規模開発では効率悪いよ
JAVAなんかと同じ方法で大規模開発しようとしたら乙ル
動的言語で大規模開発やるなら、ファイル単位でかなり細かく分ける必要がある
設計できる子が少ない
326 ：デフォルトの名無しさん：2011/10/24(月) 14:38:37.82
CMSの話題を持ち出されると急に反論できないのが静的お片づけ言語愛好者（笑い）
327 ：デフォルトの名無しさん：2011/10/24(月) 14:42:46.53
それだとPHP最高ってことか
328 ：デフォルトの名無しさん：2011/10/24(月) 15:34:59.70
Liferayって日本であまり流行らないよね何でだろね。
329 ：デフォルトの名無しさん：2011/10/24(月) 16:05:58.79
330 ：デフォルトの名無しさん：2011/10/24(月) 16:35:37.36
>>324
というか「PHP以外で」...など高機能なOSSのCMSがない理由を教えてください、
の方が適切な質問だと思う。
CMSに関しては動的静的云々以前にPHPの特殊事情だと考えた方が良い。
RubyやPerlのCMSもPHPのそれらに比べたら知名度や活発度は比較的悲惨だと思うし、
逆にエンタープライズに行くとJavaやASP.NETになる。
http://en.wikipedia.org/wiki/List_of_content_management_systems
で、理由だけれども、これは言語の性質云々以前に「人口」だと思う。
前提としてPHPNukeやMediaWikiを使う沢山のユーザがかつて沢山いて、その中から
プラグインに手を入れたり自作をし始めるユーザが出てきて、そのうち既存のCMSに
不満で心機一転して自分のCMS開発しちゃうぞ〜という人が出てくる。
ユーザが多い分そういうサイクルが頻繁に回って、結果的にDrupalみたいなのが生き
残るんじゃないのかな。
というか「PHP以外で」...など高機能なOSSのCMSがない理由を教えてください、
の方が適切な質問だと思う。
CMSに関しては動的静的云々以前にPHPの特殊事情だと考えた方が良い。
RubyやPerlのCMSもPHPのそれらに比べたら知名度や活発度は比較的悲惨だと思うし、
逆にエンタープライズに行くとJavaやASP.NETになる。
http://en.wikipedia.org/wiki/List_of_content_management_systems
で、理由だけれども、これは言語の性質云々以前に「人口」だと思う。
前提としてPHPNukeやMediaWikiを使う沢山のユーザがかつて沢山いて、その中から
プラグインに手を入れたり自作をし始めるユーザが出てきて、そのうち既存のCMSに
不満で心機一転して自分のCMS開発しちゃうぞ〜という人が出てくる。
ユーザが多い分そういうサイクルが頻繁に回って、結果的にDrupalみたいなのが生き
残るんじゃないのかな。
331 ：デフォルトの名無しさん：2011/10/24(月) 16:37:23.43
PHPでないと、レンタルサーバーが許さなかったから。
332 ：デフォルトの名無しさん：2011/10/24(月) 17:10:48.33
必死にPythonベースを避けているところが可愛いねえ♪
333 ：デフォルトの名無しさん：2011/10/24(月) 17:16:57.77
相変わらずこのスレは曜日関係なしだな。
334 ：デフォルトの名無しさん：2011/10/24(月) 17:21:21.33
PythonベースのCMSなんてあったのか。
いや無いわけはないのだが完全に視野の外だわ。
いや無いわけはないのだが完全に視野の外だわ。
335 ：デフォルトの名無しさん：2011/10/24(月) 18:00:42.97
そのCMSとやらはDSLだろ
汎用言語の仕様の話からずいぶんと離れたな
それで、そのCMSとやらはチューリング完全なんだよな
そうでないならBrainfuckの方がよほどましなんだけど
汎用言語の仕様の話からずいぶんと離れたな
それで、そのCMSとやらはチューリング完全なんだよな
そうでないならBrainfuckの方がよほどましなんだけど
336 ：デフォルトの名無しさん：2011/10/24(月) 18:43:50.11
IDEをありがたがってる→底が知れてる。
それだけかな。
それだけかな。
337 ：デフォルトの名無しさん：2011/10/24(月) 18:46:08.83
PythonのCMSか
威張れるほどのものはないんじゃないのか
http://stackoverflow.com/questions/184742/what-is-a-good-cms-written-in-python-and-not-plone
Ploneはbloatedだから避けたいんだけど他になんかいいのないのって質問
威張れるほどのものはないんじゃないのか
http://stackoverflow.com/questions/184742/what-is-a-good-cms-written-in-python-and-not-plone
Ploneはbloatedだから避けたいんだけど他になんかいいのないのって質問
338 ：デフォルトの名無しさん：2011/10/24(月) 18:53:46.02
CMSがDSLだとか、DSLにチューリング完全を求めるとか、わけわからん。
339 ：デフォルトの名無しさん：2011/10/24(月) 19:02:26.50
静的型ドカタにCMSの常識求めても無駄ってことだ
340 ：デフォルトの名無しさん：2011/10/24(月) 19:35:29.13
動的静的以前の問題だろ
普通は両方使い分けるし
必要ならチューリング完全でないDSLも作るw
普通は両方使い分けるし
必要ならチューリング完全でないDSLも作るw
341 ：デフォルトの名無しさん：2011/10/24(月) 19:47:41.23
要するに>>335はCMSについて何もしらないけど口だけ出してみたってことだろう
TeXやPostScriptはチューリング完全だけど、ドキュメントフォーマットとして
停止性が判定できないのはまずいから、PDFってわざとループや再帰を外したんだよな
確か
TeXやPostScriptはチューリング完全だけど、ドキュメントフォーマットとして
停止性が判定できないのはまずいから、PDFってわざとループや再帰を外したんだよな
確か
342 ：デフォルトの名無しさん：2011/10/24(月) 20:10:00.58
pythonでCMSなんて見栄張りたい奴だけ
Rubyなんてrorとredmineを除いて素晴らしいフレームワークもCMSも皆無
Rubyなんてrorとredmineを除いて素晴らしいフレームワークもCMSも皆無
343 ：デフォルトの名無しさん：2011/10/24(月) 20:14:04.40
rubyはcmsはないがtwitterが大きいな
性能稼ぐためにjavaに行くみたいだけど
性能稼ぐためにjavaに行くみたいだけど
344 ：デフォルトの名無しさん：2011/10/24(月) 20:27:31.83
PythonだとGoogleとFacebookあたりがメジャーどころかな
345 ：デフォルトの名無しさん：2011/10/24(月) 22:25:04.70
>>343
ぶっちゃけRubyはワンライナーテキストフィルタ特化の言語でいいと思う
ぶっちゃけRubyはワンライナーテキストフィルタ特化の言語でいいと思う
346 ：デフォルトの名無しさん：2011/10/24(月) 23:06:38.53
それならperlで十分
347 ：デフォルトの名無しさん：2011/10/25(火) 00:15:08.72
>>343
島根県CMS - Wikipedia
http://ja.wikipedia.org/wiki/島根県CMS
島根県CMS公式サイト
http://projects.netlab.jp/PrefShimaneCMS/
島根県CMS - Wikipedia
http://ja.wikipedia.org/wiki/島根県CMS
島根県CMS公式サイト
http://projects.netlab.jp/PrefShimaneCMS/
348 ：デフォルトの名無しさん：2011/10/25(火) 00:23:02.44
それマイナーなCMSっすよ
349 ：デフォルトの名無しさん：2011/10/25(火) 00:24:31.36
なんでこんな過疎化しそうな名前にしたんだ
350 ：デフォルトの名無しさん：2011/10/25(火) 00:47:07.75
>>342
Sinatra,Ramaze,Rackなど増えてるだろ
Sinatra,Ramaze,Rackなど増えてるだろ
351 ：デフォルトの名無しさん：2011/10/25(火) 00:47:32.96
Radiant CMS - 公式ホーム [in English]
http://radiantcms.org/
【ハウツー】10分でサイト構築? Radiantで簡単CMS
http://journal.mycom.co.jp/articles/2006/09/16/radiant2/index.html
Radiant CMS Japan - Ruby on Rails製オープンソースCMSの日本語サポートサイト
http://www.radiantcms.jp/
Design Recipe 別館 Blog - Radiant CMS - フレキシブルな Ruby On Rails ベースの CMS
http://blog.designrecipe.jp/2009/7/27/about-radiant/
http://radiantcms.org/
【ハウツー】10分でサイト構築? Radiantで簡単CMS
http://journal.mycom.co.jp/articles/2006/09/16/radiant2/index.html
Radiant CMS Japan - Ruby on Rails製オープンソースCMSの日本語サポートサイト
http://www.radiantcms.jp/
Design Recipe 別館 Blog - Radiant CMS - フレキシブルな Ruby On Rails ベースの CMS
http://blog.designrecipe.jp/2009/7/27/about-radiant/
352 ：デフォルトの名無しさん：2011/10/25(火) 00:52:07.47
ださ
354 ：デフォルトの名無しさん：2011/10/25(火) 06:14:54.31
325=uy ファイル単位で担当分けろ！
329 担当分けするな、こまめにコミットしてCIしろ！
どう考えたら同じに見えるんだろうwww
329 担当分けするな、こまめにコミットしてCIしろ！
どう考えたら同じに見えるんだろうwww
355 ：デフォルトの名無しさん：2011/10/25(火) 07:36:10.48
>>346
てか、Rubyってそのポジションを狙ってる言語なんじゃないの？
てか、Rubyってそのポジションを狙ってる言語なんじゃないの？
356 ：デフォルトの名無しさん：2011/10/25(火) 07:55:44.09
357 ：デフォルトの名無しさん：2011/10/25(火) 12:12:57.87
358 ：デフォルトの名無しさん：2011/10/25(火) 14:14:12.88
>>357
何もわかってないドカタだから
> 担当者を分けるためじゃなく、可読性向上のために
> ファイル単位に細分化する（細かすぎるのも良くないが）
みたいな、主語がないクソ文を書いてドヤ顔ができるんだろうな。
何もわかってないドカタだから
> 担当者を分けるためじゃなく、可読性向上のために
> ファイル単位に細分化する（細かすぎるのも良くないが）
みたいな、主語がないクソ文を書いてドヤ顔ができるんだろうな。
359 ：デフォルトの名無しさん：2011/10/25(火) 20:16:50.02
どこにキレるポイントがあったんだよw
好戦的すぎるだろwww
好戦的すぎるだろwww
360 ：デフォルトの名無しさん：2011/10/25(火) 21:42:27.86
361 ：デフォルトの名無しさん：2011/10/25(火) 23:33:44.90
人はなぜ大規模とかグローバルとかセカイとか言いたがるのか
362 ：デフォルトの名無しさん：2011/10/25(火) 23:40:41.73
グローバルには現実感ないが大規模は死活問題
363 ：デフォルトの名無しさん：2011/10/26(水) 03:30:26.59
「最初に作った時にはこんなに大規模になる予定ではなかったのにー」っていうのは、とてもありがち。
それが、便利だったから、予定以上に使われたわけだが。
それが、便利だったから、予定以上に使われたわけだが。
364 ：デフォルトの名無しさん：2011/10/26(水) 06:34:36.24
かわいそうなuyゲラゲラ
365 ：デフォルトの名無しさん：2011/10/26(水) 10:40:28.61
関数型＝静的という勘違いはどこから？
http://www.haskell.org/haskellwiki/Comparison
http://www.haskell.org/haskellwiki/Comparison
366 ：デフォルトの名無しさん：2011/10/26(水) 12:25:43.06
>>365
それはハスケラ特有の症例で、心の病の一つ
ハスケルという言語を使っていると、世の中のあらゆる事柄すべてが
ハスケルを中心に廻っているように見えるらしい
従って、あらゆる関数型言語は静的実行かつ静的型付けでなければならないし、
遅延評価が常識であり、一切の副作用は認めようとしない
ハスケラにとって関数型言語とはハスケルのことであり、
その窓から見える世界が彼らのすべて
それはハスケラ特有の症例で、心の病の一つ
ハスケルという言語を使っていると、世の中のあらゆる事柄すべてが
ハスケルを中心に廻っているように見えるらしい
従って、あらゆる関数型言語は静的実行かつ静的型付けでなければならないし、
遅延評価が常識であり、一切の副作用は認めようとしない
ハスケラにとって関数型言語とはハスケルのことであり、
その窓から見える世界が彼らのすべて
367 ：デフォルトの名無しさん：2011/10/26(水) 12:29:30.75
ポケモンにいそうだな
ハスケル
ハスケラ
ハスケル
ハスケラ
368 ：デフォルトの名無しさん：2011/10/26(水) 12:34:42.64
コボラ、ジャバラ、ハスケラ
どれも思考停止という意味では仲間同士
どれも思考停止という意味では仲間同士
369 ：デフォルトの名無しさん：2011/10/26(水) 14:22:28.42
＞コボラ、ジャバラ、ハスケラ
どこの怪獣だよ
どこの怪獣だよ
370 ：デフォルトの名無しさん：2011/10/26(水) 16:52:34.34
最強はMS怪獣ドットネトラー
371 ：デフォルトの名無しさん：2011/10/26(水) 19:33:29.01
>>369
小さい頃はまだ可愛いんだけれども大きくなってプロジェクトを仕切るように
なったりすると個体によっては怪獣になりがち。
特に老齢体のコボラが若いジャバラをいじめている光景は時々散見される。
怪獣クラスのハスケラはまだ見たことが無いなぁ。
小さい頃はまだ可愛いんだけれども大きくなってプロジェクトを仕切るように
なったりすると個体によっては怪獣になりがち。
特に老齢体のコボラが若いジャバラをいじめている光景は時々散見される。
怪獣クラスのハスケラはまだ見たことが無いなぁ。
372 ：デフォルトの名無しさん：2011/10/26(水) 19:36:17.39
ハスケラーはいつ絶滅してもおかしくない個体数だからな
373 ：デフォルトの名無しさん：2011/10/26(水) 20:28:02.82
まだだ、まだ判らんよ。
人類だって、地球上に数百人しかいなかった時期があったからな！
人類だって、地球上に数百人しかいなかった時期があったからな！
374 ：デフォルトの名無しさん：2011/10/26(水) 23:09:02.25
ネアンデルタールとエッチ出来るから問題ない
>>354
ええええ・・・・・・・やばいよお前
>>325の、どこに「担当」なんて言葉があるの
マジ大丈夫か･･･････
一応、俺の考えとほぼ同じなわけで、uyコテの形式上、ど派手に煽るわけにもいかないから
一人で勘違いして突っ走っちゃうと･･･
対処に･･･困るんすけど･･･
ええええ・・・・・・・やばいよお前
>>325の、どこに「担当」なんて言葉があるの
マジ大丈夫か･･･････
一応、俺の考えとほぼ同じなわけで、uyコテの形式上、ど派手に煽るわけにもいかないから
一人で勘違いして突っ走っちゃうと･･･
対処に･･･困るんすけど･･･
>>357 は、分かってる
>>358 は、分かってない
ここまで、圧倒的に知識劣ってる相手が
しかも俺ではなく、他の名無しに論破されて発狂しちゃう様を見ると･･･ とても切ない気持ちになる
俺が１レスでトドメをさして論破してやれば、他の名無しに痛いところつかれたレスをくらうこともなかったかもしれない
かれの心のダメージを最小限に抑えられたかもしれない
次からは、やっぱり長文になっても１レスで論破してやるようにするよ。みててかわいそーだ
冬は寒いな.......
>>358 は、分かってない
ここまで、圧倒的に知識劣ってる相手が
しかも俺ではなく、他の名無しに論破されて発狂しちゃう様を見ると･･･ とても切ない気持ちになる
俺が１レスでトドメをさして論破してやれば、他の名無しに痛いところつかれたレスをくらうこともなかったかもしれない
かれの心のダメージを最小限に抑えられたかもしれない
次からは、やっぱり長文になっても１レスで論破してやるようにするよ。みててかわいそーだ
冬は寒いな.......
377 ：デフォルトの名無しさん：2011/10/27(木) 06:05:35.20
uyの自演が必死すぎて可哀想…
378 ：デフォルトの名無しさん：2011/10/27(木) 07:31:49.91
キモいな
379 ：デフォルトの名無しさん：2011/10/27(木) 11:11:57.04
罵声
人格攻撃
特定の集団を攻撃
職業や身体的特徴などで差別
主観の押し付け
議論と関係ありそうで無関係な事実を突きつけて反論を要求する
エア敵を作り出して攻撃し始める
議論のルールを守れない奴にプログラムのルールを守れるのだろうか
人格攻撃
特定の集団を攻撃
職業や身体的特徴などで差別
主観の押し付け
議論と関係ありそうで無関係な事実を突きつけて反論を要求する
エア敵を作り出して攻撃し始める
議論のルールを守れない奴にプログラムのルールを守れるのだろうか
380 ：デフォルトの名無しさん：2011/10/27(木) 12:04:35.20
>>379
纏めると、「詭弁」。
纏めると、「詭弁」。
>>377
うわあああああああああｗｗｗｗｗｗｗｗｗｗ
ついに自演とかいいはじめちゃったよおおおおおおおおｗｗｗｗｗｗｗｗ
病気ｗｗｗｗｗｗｗｗｗｗｗｗｗｗ発覚ｗｗｗｗｗｗｗｗｗｗｗｗ
どうするのおまえ？？？？？？？ｗｗｗｗｗｗＷＷＷＷＷＷｗｗ
自分を煽る奴は全員uyかｗｗｗｗｗｗｗｗｗｗｗ 自分を煽る名無しは全員uyかｗｗｗｗｗｗｗｗｗ都合がいいなうぇｗｗｗｗｗｗｗｗｗ
病気かよ・・・・・・・・
うわあああああああああｗｗｗｗｗｗｗｗｗｗ
ついに自演とかいいはじめちゃったよおおおおおおおおｗｗｗｗｗｗｗｗ
病気ｗｗｗｗｗｗｗｗｗｗｗｗｗｗ発覚ｗｗｗｗｗｗｗｗｗｗｗｗ
どうするのおまえ？？？？？？？ｗｗｗｗｗｗＷＷＷＷＷＷｗｗ
自分を煽る奴は全員uyかｗｗｗｗｗｗｗｗｗｗｗ 自分を煽る名無しは全員uyかｗｗｗｗｗｗｗｗｗ都合がいいなうぇｗｗｗｗｗｗｗｗｗ
病気かよ・・・・・・・・
驚いた
最近はこんな奴がいるんだな
そのうちリアルで誰かに説教されても
「こいつuyだろ･････」とか思いはじめそうで怖い
病気だよそれ病気
治療方法は･･･なんだ？？？
この業界から消えろとしか
最近はこんな奴がいるんだな
そのうちリアルで誰かに説教されても
「こいつuyだろ･････」とか思いはじめそうで怖い
病気だよそれ病気
治療方法は･･･なんだ？？？
この業界から消えろとしか
383 ：デフォルトの名無しさん：2011/10/27(木) 12:49:05.71
ゴールのないマラソン
勝利目標のない戦争
走り続けていたらいつかゴールが見えてくる
敵を倒し続けていればいつか戦争は終わる
そうやって全ての人生を費やそうとする無数の人たち
その人たちにゴールがないことを教えてあげたい
敵を倒し続けても戦争は終わらないことを伝えてあげたい
すべてのにちゃんねらーにありがとう
そしてuy君、卒業おめでとう
勝利目標のない戦争
走り続けていたらいつかゴールが見えてくる
敵を倒し続けていればいつか戦争は終わる
そうやって全ての人生を費やそうとする無数の人たち
その人たちにゴールがないことを教えてあげたい
敵を倒し続けても戦争は終わらないことを伝えてあげたい
すべてのにちゃんねらーにありがとう
そしてuy君、卒業おめでとう
384 ：デフォルトの名無しさん：2011/10/27(木) 16:31:31.91
自分から「俺の」と書いておきながら必死で否定するuy…
ﾌﾞｻﾞﾏ (・∇ ・)
ﾌﾞｻﾞﾏ (・∇ ・)
385 ：デフォルトの名無しさん：2011/10/27(木) 21:01:25.71
自演かなんかしらんがキモ過ぎる
自宅の壁とお話してて下さいね
自宅の壁とお話してて下さいね
386 ：デフォルトの名無しさん：2011/10/28(金) 23:25:48.23
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?RubyAtThoughtWorks
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?DynamicTypeCheck
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?DynamicTypeCheck
387 ：デフォルトの名無しさん：2011/10/29(土) 10:04:03.52
平均より上のレベルのチームが使えば
動的言語で効率は上がるけど、
ドカタが使っても効率的かは分からない、か
妥当な結論だな
動的言語で効率は上がるけど、
ドカタが使っても効率的かは分からない、か
妥当な結論だな
388 ：デフォルトの名無しさん：2011/10/29(土) 10:09:11.52
平均より上でも、人数多くて大規模になれば
動的言語は効率下がるよ。
ただ、人数が多くなると、高いレベルの人ばかり
集めるのはコストもかかるし現実的ではないから
必然的にレベルも下がる。
そこがレベルが原因だと勘違いする元凶だけど、
実際は人数が多くて大規模になれば
レベルに関係なく、効率は下がる。
動的言語は効率下がるよ。
ただ、人数が多くなると、高いレベルの人ばかり
集めるのはコストもかかるし現実的ではないから
必然的にレベルも下がる。
そこがレベルが原因だと勘違いする元凶だけど、
実際は人数が多くて大規模になれば
レベルに関係なく、効率は下がる。
390 ：デフォルトの名無しさん：2011/10/29(土) 10:48:50.31
主観の押し付け
職業や身体的特徴などで差別
個人の能力の評価
プログラムに関係する話をしていない
文体を丁寧にしたところで
発言の目的が見え透いているから何を考えてるか手に取るようにわかる
自分を天才だと認めて欲しい、自己顕示欲
他人を見下して優越感に浸って虚栄心を満たしたい
自己顕示欲を満たすためにドカタに対するレイシズムを展開する
みんなが黙ってるのはお前に反論できないからじゃなく
関わりたくないから
俺がお前に関わってるのは他人の精神を分析する能力を向上させたいから
お前のために無償の労力や賞賛を投げかける奴はいない
こういう行動で金になるのは政治的目的や企業活動を妨害する目的、ヤクザだな
ネットヤクザ
職業や身体的特徴などで差別
個人の能力の評価
プログラムに関係する話をしていない
文体を丁寧にしたところで
発言の目的が見え透いているから何を考えてるか手に取るようにわかる
自分を天才だと認めて欲しい、自己顕示欲
他人を見下して優越感に浸って虚栄心を満たしたい
自己顕示欲を満たすためにドカタに対するレイシズムを展開する
みんなが黙ってるのはお前に反論できないからじゃなく
関わりたくないから
俺がお前に関わってるのは他人の精神を分析する能力を向上させたいから
お前のために無償の労力や賞賛を投げかける奴はいない
こういう行動で金になるのは政治的目的や企業活動を妨害する目的、ヤクザだな
ネットヤクザ
391 ：デフォルトの名無しさん：2011/10/29(土) 10:49:20.16
>>389
要約になってませんよｗ
要約になってませんよｗ
392 ：デフォルトの名無しさん：2011/10/29(土) 10:53:49.01
> 我々の強みは、典型的なIT企業では引き込めないような非常に有能な人たちを雇用しているという点だ。
> Rubyには、あまり有能ではない開発者をエラーから守るよりも、 有能な開発者が
> さらにうまく物事を成し遂げられる環境のほうがよいという哲学がある。
> 我々がRubyについてよく耳にするのは、動的型付、メタプログラミングのサポート、追いにくいコードを任せられるツールの欠如である。
> 実際にこれらが我々にとって問題となったことはない。 聞いた話によると、主流の言語と比べ、
> 同じ機能を書くときのコードの量が少なく、より簡単にコードをクリーンに保てるようだ。
> とは言うものの、我々の状況を忘れないで欲しい。 ThoughtWorksの開発者たちは、
> 能力という点では平均よりも高く、エクストリームプログラミングのような規律ある手法に熱心な者ばかりである。
> 我々はテスティングに非常に重きを置いており（Rubyコミュニティでも大切だとされている）、
> テストによってコードをよりクリアに保つことができている。
> つまり、我々の経験が、能力や規律の少ない開発者でもうまくいくのかどうかは分からない。
> Rubyには、あまり有能ではない開発者をエラーから守るよりも、 有能な開発者が
> さらにうまく物事を成し遂げられる環境のほうがよいという哲学がある。
> 我々がRubyについてよく耳にするのは、動的型付、メタプログラミングのサポート、追いにくいコードを任せられるツールの欠如である。
> 実際にこれらが我々にとって問題となったことはない。 聞いた話によると、主流の言語と比べ、
> 同じ機能を書くときのコードの量が少なく、より簡単にコードをクリーンに保てるようだ。
> とは言うものの、我々の状況を忘れないで欲しい。 ThoughtWorksの開発者たちは、
> 能力という点では平均よりも高く、エクストリームプログラミングのような規律ある手法に熱心な者ばかりである。
> 我々はテスティングに非常に重きを置いており（Rubyコミュニティでも大切だとされている）、
> テストによってコードをよりクリアに保つことができている。
> つまり、我々の経験が、能力や規律の少ない開発者でもうまくいくのかどうかは分からない。
393 ：デフォルトの名無しさん：2011/10/29(土) 11:02:43.44
> Rubyプロジェクトはほとんどの場合、他のプロジェクトよりも短く、小規模のようだ。
結局これに尽きるわｗ
結局これに尽きるわｗ
394 ：デフォルトの名無しさん：2011/10/29(土) 11:04:10.26
図1: 2006年から2008年におけるThoughtWorksでのRubyプロジェクトに関わった人数（ピーク時）と期間の散布図
図2: 各年ごとのプロジェクトの工数を表したストリップチャート
図3: 国別のプロジェクトの工数を表したストリップチャート
デーはこれだけ。
あとは、個人の感想ばかり。
グラフがあれば、客観的なデータだと勘違いする奴は
死んでほしい。
図2: 各年ごとのプロジェクトの工数を表したストリップチャート
図3: 国別のプロジェクトの工数を表したストリップチャート
デーはこれだけ。
あとは、個人の感想ばかり。
グラフがあれば、客観的なデータだと勘違いする奴は
死んでほしい。
395 ：デフォルトの名無しさん：2011/10/29(土) 11:06:51.12
卑怯な書き方だな
我々天才は
○○を必要としない
××を使う
つまり我々と同じことをやってもバカだと失敗する
反論した奴には、それはお前がバカだからだと最初に釘をさしておいただろう
まじで軽蔑する、支持しない
我々天才は
○○を必要としない
××を使う
つまり我々と同じことをやってもバカだと失敗する
反論した奴には、それはお前がバカだからだと最初に釘をさしておいただろう
まじで軽蔑する、支持しない
396 ：デフォルトの名無しさん：2011/10/29(土) 11:07:23.57
397 ：デフォルトの名無しさん：2011/10/29(土) 11:17:36.20
>>396
人格否定しかできないの？
人格否定しかできないの？
398 ：デフォルトの名無しさん：2011/10/29(土) 11:20:17.38
Groovy、F#、Python、Smalltalkでも同じような結果（生産性が向上する）
になるかもしれないって書いてるから、ことさら動的型付け言語だけを
贔屓してるわけじゃないんだな
になるかもしれないって書いてるから、ことさら動的型付け言語だけを
贔屓してるわけじゃないんだな
399 ：デフォルトの名無しさん：2011/10/29(土) 11:24:16.50
動的でも静的でも大体同じだよ
同じというのは肯定でも否定でもないよ
同じというのは肯定でも否定でもないよ
400 ：デフォルトの名無しさん：2011/10/29(土) 11:27:52.93
全ての言語は等しいのか?
http://practical-scheme.net/trans/icad-j.html
http://practical-scheme.net/trans/icad-j.html
401 ：デフォルトの名無しさん：2011/10/29(土) 11:47:44.07
Javaがぶっちぎりでウンコなだけで
動的型言語が優れてるわけじゃない
動的型言語が優れてるわけじゃない
402 ：デフォルトの名無しさん：2011/10/29(土) 11:48:53.38
やっぱりJavaにコンプレックス持ってるやつかｗ
403 ：デフォルトの名無しさん：2011/10/29(土) 12:12:15.36
404 ：デフォルトの名無しさん：2011/10/29(土) 12:28:41.57
他人を自分の思いのままにコントロールすることで得られる全能感でも味わいたいのじゃないの
この争いはわしが育てた
もしくはまじめな話になるのを妨害しているのか
荒らしてる奴の精神分析して理解しておけば
リアルでいやな目に遭うのを回避できるからもっとやって欲しい
この争いはわしが育てた
もしくはまじめな話になるのを妨害しているのか
荒らしてる奴の精神分析して理解しておけば
リアルでいやな目に遭うのを回避できるからもっとやって欲しい
405 ：デフォルトの名無しさん：2011/10/29(土) 12:49:35.76
>>395
それ、静的型厨房の常套句だねえ♪
それ、静的型厨房の常套句だねえ♪
406 ：デフォルトの名無しさん：2011/10/29(土) 13:07:16.42
特定の個人の詭弁を
鸚鵡返しして
集団の見解とみなして攻撃するのか
挑発が目的ってところだな
明確な敵がいて戦って勝ち続ければ俺の勝利と考えてるのなら
>>383
end
議論と討論の区別がついてなくて
議論している人に討論しかけてるというパターンか
鸚鵡返しして
集団の見解とみなして攻撃するのか
挑発が目的ってところだな
明確な敵がいて戦って勝ち続ければ俺の勝利と考えてるのなら
>>383
end
議論と討論の区別がついてなくて
議論している人に討論しかけてるというパターンか
407 ：デフォルトの名無しさん：2011/10/29(土) 13:19:38.84
討論にしてもルールすら守ってないし
虚栄心を満たしたいのだろうか
自分がバカにしてる他人に認められてうれしいわけないから
ストレス解消程度にしか考えてないのだろうな
もしくは他人に時間を無駄に使わせることに喜びを感じたり
他人が自分のために時間を割くことに喜びを感じてるのだろうか
寂しいからかかまってかまって欲しいの
虚栄心を満たしたいのだろうか
自分がバカにしてる他人に認められてうれしいわけないから
ストレス解消程度にしか考えてないのだろうな
もしくは他人に時間を無駄に使わせることに喜びを感じたり
他人が自分のために時間を割くことに喜びを感じてるのだろうか
寂しいからかかまってかまって欲しいの
408 ：デフォルトの名無しさん：2011/10/29(土) 16:03:18.69
GoogleとかTwitterみたいな優秀なプログラマー揃いの企業でもDartでJavaScriptに型を導入しようとしたり、Rubyを捨ててScalaへ移行してるわけだからな。
409 ：デフォルトの名無しさん：2011/10/29(土) 16:07:25.70
まだDartは静的型だとか言ってる馬鹿がいるぞw
410 ：デフォルトの名無しさん：2011/10/29(土) 16:16:15.17
GoogleがDartで明らかにしたのは、あんな仕様でも
馬鹿な静的厨はあっさり騙されてくれるってこと
馬鹿な静的厨はあっさり騙されてくれるってこと
411 ：デフォルトの名無しさん：2011/10/29(土) 16:27:08.02
JavaSriptには型がないから大規模開発に向かない、だからDartに型を導入した。これがGoogleの言ってる事だから。
412 ：デフォルトの名無しさん：2011/10/29(土) 16:37:08.49
>>411
そういうマヌケなことはECの仕様書読んでからにしたら？
そういうマヌケなことはECの仕様書読んでからにしたら？
413 ：デフォルトの名無しさん：2011/10/29(土) 16:48:21.52
414 ：デフォルトの名無しさん：2011/10/29(土) 16:53:42.74
型があればより安全に書ける、その代わり、型による制約で記述量が増える。小規模な開発なら型がない方が適してるだろうし、大規模な開発なら型がある方が適してる。
415 ：デフォルトの名無しさん：2011/10/29(土) 16:54:40.62
馬鹿は型注釈と静的型の区別がつかないので
動的型言語に型注釈を追加しました。
ぶっちゃけコメントと大差ないですが、馬鹿には十分でしょ？ < Googleの言い分
動的型言語に型注釈を追加しました。
ぶっちゃけコメントと大差ないですが、馬鹿には十分でしょ？ < Googleの言い分
416 ：デフォルトの名無しさん：2011/10/29(土) 16:56:19.02
で型注釈を取り入れた理由は？
417 ：デフォルトの名無しさん：2011/10/29(土) 16:57:55.57
馬鹿は騙されてくれるから。
418 ：デフォルトの名無しさん：2011/10/29(土) 16:59:17.11
あ、やっぱりその程度の認識だったんだ。
Googleがそんな事するわけがないだろ。
常識で考えろやｗ
Googleがそんな事するわけがないだろ。
常識で考えろやｗ
419 ：デフォルトの名無しさん：2011/10/29(土) 17:07:47.89
プログラマの常識で考えると、Dartの規格を見て静的型だと間違えるはずないんだが
土方はその常識の範疇を超えてるからな・・・
ここは土方のレベルすら読み切ったGoogleを褒めるべき。
土方はその常識の範疇を超えてるからな・・・
ここは土方のレベルすら読み切ったGoogleを褒めるべき。
420 ：デフォルトの名無しさん：2011/10/29(土) 17:31:21.72
Googleを褒めるのは静的型付け言語のメリットに気づいた所で、
お前の言うゲスな考えをGoogleがしていることじゃないんだがｗ
お前の言うゲスな考えをGoogleがしていることじゃないんだがｗ
421 ：デフォルトの名無しさん：2011/10/29(土) 17:37:47.49
>>421
お前はよくわかってるからもう来なくていいよ。
お前はよくわかってるからもう来なくていいよ。
422 ：デフォルトの名無しさん：2011/10/29(土) 17:50:17.84
423 ：デフォルトの名無しさん：2011/10/29(土) 17:52:44.44
いや この中でよくわかってるのは>>423に違いない。
424 ：デフォルトの名無しさん：2011/10/29(土) 18:20:43.55
おれが見た中だと
>>425あたりが一番わかってそうだが、
>>425あたりが一番わかってそうだが、
425 ：デフォルトの名無しさん：2011/10/29(土) 18:25:58.09
はい、Googleも静的型付け言語のメリットを見出して
難しいのに動的言語にもそれなりに取り入れました。
本当に不要なものであれば、入れる必要はなかったものです。
もともとGoogleはJava使ってる会社ですしね。
難しいのに動的言語にもそれなりに取り入れました。
本当に不要なものであれば、入れる必要はなかったものです。
もともとGoogleはJava使ってる会社ですしね。
426 ：デフォルトの名無しさん：2011/10/29(土) 18:40:37.77
Googleがスクリプト言語でもRubyじゃなくPythonを重用してるのが象徴的だな。
427 ：デフォルトの名無しさん：2011/10/29(土) 20:08:57.51
>>425
>>60に警告すら出さないのは静的型付けの観点から見て何のメリットがあるの？
実行時にすら型チェックしないのは何のメリットがあるの？
>>129の言うように型情報を用いた最適化も無理なことに何のメリットがあるの？
>>60に警告すら出さないのは静的型付けの観点から見て何のメリットがあるの？
実行時にすら型チェックしないのは何のメリットがあるの？
>>129の言うように型情報を用いた最適化も無理なことに何のメリットがあるの？
428 ：デフォルトの名無しさん：2011/10/29(土) 20:21:08.06
> >>60に警告すら出さないのは静的型付けの観点から見て何のメリットがあるの？
> 実行時にすら型チェックしないのは何のメリットがあるの？
ないよ。これはJavaScriptに変換するための制限か
もしくは、まだベータ版だからだだろう。
> 実行時にすら型チェックしないのは何のメリットがあるの？
ないよ。これはJavaScriptに変換するための制限か
もしくは、まだベータ版だからだだろう。
429 ：デフォルトの名無しさん：2011/10/30(日) 06:25:47.82
>>428
> ないよ。これはJavaScriptに変換するための制限か
コンパイラ(トランスレータ)が静的型検査するのにターゲット言語の制限なんて関係ねえだろカス
動的型検査だってJavaScriptで実装しようと思えばできる
でもググルは敢えて、検査しなかった
静的型付けのデメリットをよく知っていて、それが致命的なものと考えたからだ
> もしくは、まだベータ版だからだだろう。
ぷ
> ないよ。これはJavaScriptに変換するための制限か
コンパイラ(トランスレータ)が静的型検査するのにターゲット言語の制限なんて関係ねえだろカス
動的型検査だってJavaScriptで実装しようと思えばできる
でもググルは敢えて、検査しなかった
静的型付けのデメリットをよく知っていて、それが致命的なものと考えたからだ
> もしくは、まだベータ版だからだだろう。
ぷ
430 ：デフォルトの名無しさん：2011/10/30(日) 11:57:24.07
> Googleを褒めるのは静的型付け言語のメリットに気づいた所
ドカタがGoogleに上から目線でワロタwww
ドカタがGoogleに上から目線でワロタwww
431 ：デフォルトの名無しさん：2011/10/30(日) 12:12:19.02
432 ：デフォルトの名無しさん：2011/10/30(日) 12:34:49.83
>>431
上から目線なのは文型のせいだと思っちゃうほどドカタなの？
上から目線なのは文型のせいだと思っちゃうほどドカタなの？
433 ：デフォルトの名無しさん：2011/10/30(日) 12:52:31.60
結局C++はゴミってことでよろしいか
434 ：デフォルトの名無しさん：2011/10/30(日) 13:40:28.37
はい
435 ：デフォルトの名無しさん：2011/10/31(月) 12:30:15.75
静的なチェックはもう少し厳しくなるんじゃね
実行時のチェックはjs変換ではしないよな
専用vmならやるかもだが
実行時のチェックはjs変換ではしないよな
専用vmならやるかもだが
436 ：デフォルトの名無しさん：2011/10/31(月) 22:46:39.91
C++にコンプレックスあんのか
437 ：デフォルトの名無しさん：2011/11/01(火) 00:27:13.26
まあコンプレックスな言語ではある
438 ：デフォルトの名無しさん：2011/11/01(火) 01:44:36.74
C++を捨てた時のことを思い出す。テンプレを使い込んだプログラミング
にはまった時のことだったな。考え方を抽象化してそれをプログラミング
にしていくと、あまりにも手に負えなくなったので言語を切り替えた。
しばらく前にOcamlとC#の例が紹介された論文があったが、あれ状態で
もういらん。。。 となってしまったな。
にはまった時のことだったな。考え方を抽象化してそれをプログラミング
にしていくと、あまりにも手に負えなくなったので言語を切り替えた。
しばらく前にOcamlとC#の例が紹介された論文があったが、あれ状態で
もういらん。。。 となってしまったな。
439 ：デフォルトの名無しさん：2011/11/01(火) 04:13:06.78
性的な型チェック。。。 なんだかやらしいな
440 ：デフォルトの名無しさん：2011/11/01(火) 09:05:06.90
テンプレート使わなきゃいい話
441 ：デフォルトの名無しさん：2011/11/01(火) 10:22:23.69
他人のコード直す時は、そうはいかない
442 ：デフォルトの名無しさん：2011/11/01(火) 10:43:47.43
テンプレートが無いC++なんてただの面倒くさいJavaみたいなもの
443 ：デフォルトの名無しさん：2011/11/01(火) 12:44:31.33
>>440
目的がその場限りの取り組みならそれでOKだが、柔軟性を求めた
作りを考えだすと、途端にシンタックスノイズがすごく邪魔になる。
そんな状況ならば、もっと抽象的な記述が得意な方をやればいい
のではないか？と考えたくらいかな。僕はLispの方に向かったけど
OcamlやHaskellでもよかったかなとは思うところはあるな。
抽象化の記述が弱ければ、とたんに建設資材を組み立てるだけみたいな
プログラミングになりがちで余り頭がいらないから、それならそんな人
に任せばいいだけかな。そうゆうことが好きな人も多いみたいだし。
目的がその場限りの取り組みならそれでOKだが、柔軟性を求めた
作りを考えだすと、途端にシンタックスノイズがすごく邪魔になる。
そんな状況ならば、もっと抽象的な記述が得意な方をやればいい
のではないか？と考えたくらいかな。僕はLispの方に向かったけど
OcamlやHaskellでもよかったかなとは思うところはあるな。
抽象化の記述が弱ければ、とたんに建設資材を組み立てるだけみたいな
プログラミングになりがちで余り頭がいらないから、それならそんな人
に任せばいいだけかな。そうゆうことが好きな人も多いみたいだし。
444 ：デフォルトの名無しさん：2011/11/01(火) 12:52:28.89
余り頭がいらないというのは言い過ぎか、頭を使う方向が違うという
ふうに訂正しておく。
とかく、一歩二歩先を考えたプログラミングにC++とかJavaは向いて
ないんだよな。。。。
ふうに訂正しておく。
とかく、一歩二歩先を考えたプログラミングにC++とかJavaは向いて
ないんだよな。。。。
445 ：デフォルトの名無しさん：2011/11/01(火) 13:58:34.89
プリミティブ型もテンプレートも時代遅れだろう
メモリは余ってるし、処理速度は並列で稼げるし
積極的に使う理由がない
メモリは余ってるし、処理速度は並列で稼げるし
積極的に使う理由がない
446 ：デフォルトの名無しさん：2011/11/01(火) 14:03:11.90
おんなじことを複数回書くのを防ぐ事と
メモリや実行効率は何の関係もない
メモリや実行効率は何の関係もない
447 ：デフォルトの名無しさん：2011/11/01(火) 14:25:59.52
重複する理由の多くはプリミティブ型の問題
プリミティブ型があるからテンプレートが必要になった
プリミティブ型を残したのは速度やメモリが理由
プリミティブ型があるからテンプレートが必要になった
プリミティブ型を残したのは速度やメモリが理由
448 ：デフォルトの名無しさん：2011/11/01(火) 15:23:31.92
皮かむってるかどうかの違いだろ
直実行出来ない以上どこかでプリミティブに行き着く
まC++がゴミというのに異存ないがね
直実行出来ない以上どこかでプリミティブに行き着く
まC++がゴミというのに異存ないがね
449 ：デフォルトの名無しさん：2011/11/01(火) 16:17:45.73
ゴミなのはおまえの頭の程度だと
いい加減気づけよw
いい加減気づけよw
450 ：デフォルトの名無しさん：2011/11/01(火) 16:47:46.70
プリミティブ型が無かろうが、C++で型安全な汎用コンテナ作ろうと思ったらテンプレート必須
451 ：デフォルトの名無しさん：2011/11/01(火) 16:48:36.56
プログラミング言語や製品や企業や政党や宗教なんかに
過剰な思い入れをする人たちはそれらを物や組織を、その観念を超えて
一つの人格だと認識するようになる傾向にあるらしい
病的なレベルになると「俺がガンダムだ」と言うような
自分そのものだと自称する傾向にあるらしいな
つまり449は自分のことをc++だと思い込んでいるのだと俺は結論付ける
過剰な思い入れをする人たちはそれらを物や組織を、その観念を超えて
一つの人格だと認識するようになる傾向にあるらしい
病的なレベルになると「俺がガンダムだ」と言うような
自分そのものだと自称する傾向にあるらしいな
つまり449は自分のことをc++だと思い込んでいるのだと俺は結論付ける
452 ：デフォルトの名無しさん：2011/11/01(火) 17:22:36.54
頭大丈夫？
453 ：デフォルトの名無しさん：2011/11/01(火) 18:37:26.54
この世界の人って、頭のネジが壊れてるほうがいい仕事をする。
454 ：デフォルトの名無しさん：2011/11/01(火) 18:58:31.89
巨大なプロジェクトになるなら、静的な方が開発効率もパフォーマンスも高い。
455 ：デフォルトの名無しさん：2011/11/01(火) 19:40:54.52
無限ループだな
456 ：デフォルトの名無しさん：2011/11/01(火) 19:56:07.29
C++はどうしても速度が必要な人だけが使えば良い
Scalaは動的型言語並みに簡潔な上にパフォーマンスも良いので流行ると嬉しい
http://www.readwriteweb.com/hack/2011/06/cpp-go-java-scala-performance-benchmark.php
Scalaは動的型言語並みに簡潔な上にパフォーマンスも良いので流行ると嬉しい
http://www.readwriteweb.com/hack/2011/06/cpp-go-java-scala-performance-benchmark.php
457 ：デフォルトの名無しさん：2011/11/01(火) 19:56:17.16
フレーマーによるフレーマーのためのフレーマーなスレですから
458 ：デフォルトの名無しさん：2011/11/01(火) 20:33:48.85
c++は衰退する
html5が動くブラウザのシェアが各osのシェア以上になることは確定してるから
ほとんどのアプリケーションはウェブアプリになる
するとjavascriptが自動的に覇権を得る
それを見越したdartだろう
html5が動くブラウザのシェアが各osのシェア以上になることは確定してるから
ほとんどのアプリケーションはウェブアプリになる
するとjavascriptが自動的に覇権を得る
それを見越したdartだろう
459 ：デフォルトの名無しさん：2011/11/01(火) 20:45:46.70
>>454
「静的型」と書いて「ドカタ」と読むかんじだな
「静的型」と書いて「ドカタ」と読むかんじだな
460 ：デフォルトの名無しさん：2011/11/01(火) 20:55:44.28
どっちかっつうと
動的型→ドウテキカタ→ドカタ
じゃないのか
動的型→ドウテキカタ→ドカタ
じゃないのか
461 ：デフォルトの名無しさん：2011/11/01(火) 21:02:26.20
動的言語とか型推論系の言語って 大人数より少人数で開発するのに向いてる
言語だから454のいう事も少し理解できる。無駄に人数が必要な言語ってコスト
の面でもあまりよくないけど、その無駄をふくらませて作らせるのが正しいの
かもね。俺には理解できんが。問題は少数精鋭形に向いてると言っても、その
精鋭を集めるのが大変というジレンマがあるくらいかな。
言語だから454のいう事も少し理解できる。無駄に人数が必要な言語ってコスト
の面でもあまりよくないけど、その無駄をふくらませて作らせるのが正しいの
かもね。俺には理解できんが。問題は少数精鋭形に向いてると言っても、その
精鋭を集めるのが大変というジレンマがあるくらいかな。
462 ：デフォルトの名無しさん：2011/11/01(火) 21:05:34.07
html5が動くブラウザはどれもC++で書かれているんだが
463 ：デフォルトの名無しさん：2011/11/01(火) 21:18:22.36
金さえ出せば少数精鋭を集めるのは難しくないだろう。
相場の数倍とかになるだろうけどなｗ
で、そうやって高い金だして雇っても
費用対効果をうまく出すのは難しいんだよね。
なぜならプロジェクト全体を見ると難しい所と簡単な所がある。
難しい所ってのは、プロジェクトの基盤の部分だが、量としては少ない。
それに対して、簡単なところは、単純作業的な所は、量は多い。
簡単な所を高い金だして雇った人にさせても無駄が多い。
プロジェクト全体の効率を考えると、簡単なところは新人、下請け、
オフショアなどにやらせるという考えがでてくる。
そうなると、どうしてもコードをコントロールしやすい静的言語になっちゃうんだよね。
相場の数倍とかになるだろうけどなｗ
で、そうやって高い金だして雇っても
費用対効果をうまく出すのは難しいんだよね。
なぜならプロジェクト全体を見ると難しい所と簡単な所がある。
難しい所ってのは、プロジェクトの基盤の部分だが、量としては少ない。
それに対して、簡単なところは、単純作業的な所は、量は多い。
簡単な所を高い金だして雇った人にさせても無駄が多い。
プロジェクト全体の効率を考えると、簡単なところは新人、下請け、
オフショアなどにやらせるという考えがでてくる。
そうなると、どうしてもコードをコントロールしやすい静的言語になっちゃうんだよね。
464 ：デフォルトの名無しさん：2011/11/01(火) 21:36:52.83
対人費用のことを考えると 低価格大人数と高価格少人数じゃかわらん
という意見ももっともだな。どこに最適な所があるかはなんとも言えないけど
言ってることはわかるよ。１割の凄腕系と９割のアリで十分という考えは
成り立つかもね。
宇曽かマコトか解からんけど、
ただ、モチベーションが保てない開発言語から別のに移して飛躍的に生産性が
伸びたという報告もあるからなぁ。ScalaとかClojureはそのへんの最右翼なん
だけど、その違いって触った人しかわからないのと、保守的すぎる風土が多い
日本というのが一番問題かもね。
という意見ももっともだな。どこに最適な所があるかはなんとも言えないけど
言ってることはわかるよ。１割の凄腕系と９割のアリで十分という考えは
成り立つかもね。
宇曽かマコトか解からんけど、
ただ、モチベーションが保てない開発言語から別のに移して飛躍的に生産性が
伸びたという報告もあるからなぁ。ScalaとかClojureはそのへんの最右翼なん
だけど、その違いって触った人しかわからないのと、保守的すぎる風土が多い
日本というのが一番問題かもね。
465 ：デフォルトの名無しさん：2011/11/01(火) 21:47:09.39
モチベーションが保てない言語
Java、PHP
Java、PHP
466 ：デフォルトの名無しさん：2011/11/01(火) 22:00:24.37
>>464
> ただ、モチベーションが保てない開発言語から別のに移して飛躍的に生産性が
> 伸びたという報告もあるからなぁ。ScalaとかClojureはそのへんの最右翼なん
たぶん、それは、何かのライブラリやフレームワークといった
「パソコンの仕組みを知らない人」が使わない物の開発じゃないかな？
パソコンの仕組みを知らない人が使うシステムだと、
そんなのYAML形式の設定ファイルをいじるだけじゃん、SQL実行するだけじゃんていう箇所の
インターフェースを作るなどというつまらない作業がたくさん出てくるはず。
どんな言語を使っても、基盤ができたあとは
つまらない開発ばっかりになるはずなんだ。
基盤を作るっていうのは、その他の部分でバグが入り込まないようとか
少ないコードで書けるようにして、残りは特に解決すべき課題もない
単純作業にまで落としこむのが目的だからね。
> ただ、モチベーションが保てない開発言語から別のに移して飛躍的に生産性が
> 伸びたという報告もあるからなぁ。ScalaとかClojureはそのへんの最右翼なん
たぶん、それは、何かのライブラリやフレームワークといった
「パソコンの仕組みを知らない人」が使わない物の開発じゃないかな？
パソコンの仕組みを知らない人が使うシステムだと、
そんなのYAML形式の設定ファイルをいじるだけじゃん、SQL実行するだけじゃんていう箇所の
インターフェースを作るなどというつまらない作業がたくさん出てくるはず。
どんな言語を使っても、基盤ができたあとは
つまらない開発ばっかりになるはずなんだ。
基盤を作るっていうのは、その他の部分でバグが入り込まないようとか
少ないコードで書けるようにして、残りは特に解決すべき課題もない
単純作業にまで落としこむのが目的だからね。
467 ：デフォルトの名無しさん：2011/11/01(火) 23:12:31.56
彼らの真偽は知らんけど、Clojure スレの16と39を見てみ。このハナシは
対話環境が大きな影響を与えたそうな。
対話環境が大きな影響を与えたそうな。
468 ：デフォルトの名無しさん：2011/11/01(火) 23:29:30.48
精鋭と10倍の兵隊なら精鋭の勝ちなんだよな
コードの多寡にかかわらず。
でも精鋭は数が少なくてバラけてるし
集めるが大変
でも10倍も払わなくていい
コードの多寡にかかわらず。
でも精鋭は数が少なくてバラけてるし
集めるが大変
でも10倍も払わなくていい
469 ：デフォルトの名無しさん：2011/11/02(水) 15:12:32.44
表向きの理由→少数精鋭であるっ(ｷﾘｯ
本当の理由→たくさん雇ったら金がかかるから、バカを天才扱いしてサビ残させて節約すっか
バカ達の会話→俺たち天才だしな、凡人とは違うのだよ凡人とは
ああ、もちろんこのスレの人たちはみんな天才だと思いますけど
たまにいるんですよね勘違いする人が、九割ぐらいの人は勘違いする
でもこのスレの人たちのほとんどは一割の天才だから気にしないでください
本当の理由→たくさん雇ったら金がかかるから、バカを天才扱いしてサビ残させて節約すっか
バカ達の会話→俺たち天才だしな、凡人とは違うのだよ凡人とは
ああ、もちろんこのスレの人たちはみんな天才だと思いますけど
たまにいるんですよね勘違いする人が、九割ぐらいの人は勘違いする
でもこのスレの人たちのほとんどは一割の天才だから気にしないでください
470 ：デフォルトの名無しさん：2011/11/02(水) 15:26:25.98
＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿／
,,-―--、 .)ノ
|:::::::::::::;;;ﾉ
|::::::::::( 」
ﾉﾉﾉ ヽ_l
,,-┴―┴- 、 ∩_
／,|┌-[]─┐| ＼ ( ﾉ
/ ヽ| | バ | '、／＼ / /
/ `./| | カ | |＼ /
＼ ヽ| lゝ | | ＼__/
.＼| ￣￣￣ |
,,-―--、 .)ノ
|:::::::::::::;;;ﾉ
|::::::::::( 」
ﾉﾉﾉ ヽ_l
,,-┴―┴- 、 ∩_
／,|┌-[]─┐| ＼ ( ﾉ
/ ヽ| | バ | '、／＼ / /
/ `./| | カ | |＼ /
＼ ヽ| lゝ | | ＼__/
.＼| ￣￣￣ |
471 ：デフォルトの名無しさん：2011/11/02(水) 15:41:09.23
反論できないからレッテル貼って挑発してるようにしか見えない
少数精鋭がすごいなんて根拠もデータもないし
歴史上は数の多い勢力が大抵の場合は勝ってる
金がないから少数を育てて少数精鋭にするしかないというのが事実
少数精鋭が常に勝つのであればマイクロソフトもグーグルもアップルも
なんであんなに大きいのだろうな
少数精鋭の方が効率がいいのに
俺は頭が悪いからわからないよ
少数精鋭よりも多人数の方がつおいんじゃないの
少数精鋭がすごいなんて根拠もデータもないし
歴史上は数の多い勢力が大抵の場合は勝ってる
金がないから少数を育てて少数精鋭にするしかないというのが事実
少数精鋭が常に勝つのであればマイクロソフトもグーグルもアップルも
なんであんなに大きいのだろうな
少数精鋭の方が効率がいいのに
俺は頭が悪いからわからないよ
少数精鋭よりも多人数の方がつおいんじゃないの
472 ：デフォルトの名無しさん：2011/11/02(水) 15:43:15.82
人月の神話
473 ：デフォルトの名無しさん：2011/11/02(水) 15:47:34.33
多人数の精鋭が一番強いからに決まってんだろ
474 ：デフォルトの名無しさん：2011/11/02(水) 15:50:47.62
グーグルは。。。 精鋭系が大人数だからな。facebookもだが、
だから一部で恐れられた。まともとのハンティングもしようとしてたけど、
Pythonの本拠だからな。グーグルって。
最近はアイデアが枯渇してるように見える。
少数系の話がよく上げる例だったら、グレアムのviawebの件を調べてみれ
ばいい。少数精鋭でやった機動力の高さが効いてる例だった。
日本で、rubyハッカー系ばかり集めてる所ってどこなんだろう。
だから一部で恐れられた。まともとのハンティングもしようとしてたけど、
Pythonの本拠だからな。グーグルって。
最近はアイデアが枯渇してるように見える。
少数系の話がよく上げる例だったら、グレアムのviawebの件を調べてみれ
ばいい。少数精鋭でやった機動力の高さが効いてる例だった。
日本で、rubyハッカー系ばかり集めてる所ってどこなんだろう。
475 ：デフォルトの名無しさん：2011/11/02(水) 15:53:28.11
少数でする方が向いてる言語を扱ってる人たちが大人数でやると
多頭に船状態になるから、期待できない。
サッカーのビッグクラブで監督が選手をまとめきれない状態に近い。
多頭に船状態になるから、期待できない。
サッカーのビッグクラブで監督が選手をまとめきれない状態に近い。
476 ：デフォルトの名無しさん：2011/11/02(水) 15:56:50.61
思考停止してるんじゃないの
金がなくて人をたくさん雇えないから権威にすがったり
少数精鋭だと虚勢を張ってるだけじゃないの
そして現状に妥協した結果
人が多くなると管理が難しくなるのは当然
少数精鋭でいいという考えはその難しさから逃げてるだけ
資産を増やして数を増やして管理を考えるのが正道
その道を通ったから大企業になるだろ
大企業になればあらゆる主導権を握るから
弱小企業は常に大企業に振り回される
俺は自分で規模の大きいプログラムを効率よく作る方法を模索してるけど
お前は違うよな
周りがそういってるから
権威が言った、有名な著書にそう書いてあるから
人月の神話を銀の弾丸のように使い出したら、それはギャグでしかないだろ
無数ある戦略を一つに絞って複数の目的に対応しようというのは
組織運営に反している、愚考だろ
金がなくて人をたくさん雇えないから権威にすがったり
少数精鋭だと虚勢を張ってるだけじゃないの
そして現状に妥協した結果
人が多くなると管理が難しくなるのは当然
少数精鋭でいいという考えはその難しさから逃げてるだけ
資産を増やして数を増やして管理を考えるのが正道
その道を通ったから大企業になるだろ
大企業になればあらゆる主導権を握るから
弱小企業は常に大企業に振り回される
俺は自分で規模の大きいプログラムを効率よく作る方法を模索してるけど
お前は違うよな
周りがそういってるから
権威が言った、有名な著書にそう書いてあるから
人月の神話を銀の弾丸のように使い出したら、それはギャグでしかないだろ
無数ある戦略を一つに絞って複数の目的に対応しようというのは
組織運営に反している、愚考だろ
477 ：デフォルトの名無しさん：2011/11/02(水) 16:09:09.31
なんだかあまり最適化を考えそうにないコメントに見える。
478 ：デフォルトの名無しさん：2011/11/02(水) 16:19:22.64
指摘のようでただの一方的な決め付けによる憶測ってところがミソな
479 ：デフォルトの名無しさん：2011/11/02(水) 16:39:49.39
その批判した奴の意見が多数に支持されるようになったら
おまえはそれを素直に受け入れることができるのだろうか
自分の未来を削る覚悟がないのなら他人を批判なんてしないほうがいいよ
お前の否定した技術が必須になったときに受け入れられずに出遅れる
お前の否定した連中と同じ立場になったら発狂するしかないだろ
俺は少数精鋭は選択肢の一つに過ぎず銀の弾丸ではないと主張しただけ
過去のいろいろなジャンルの本を読んで理解した重要な部分を
各所にちりばめてそれをやってるから
俺の発言をすべて批判したら、お前の選択肢が大幅になくなる
そのための長文だ
俺は技術的に減るものはないけど、おれの発言や人格を批判した奴は
様々な選択肢に制約がかかるだろうな
だから存分に俺をバカにしなさい、俺にデメリットはない
部分的な批判されると困るけど、ここまで言われてそれをすると
その無駄に高いプライドに傷がつくよね
おまえはそれを素直に受け入れることができるのだろうか
自分の未来を削る覚悟がないのなら他人を批判なんてしないほうがいいよ
お前の否定した技術が必須になったときに受け入れられずに出遅れる
お前の否定した連中と同じ立場になったら発狂するしかないだろ
俺は少数精鋭は選択肢の一つに過ぎず銀の弾丸ではないと主張しただけ
過去のいろいろなジャンルの本を読んで理解した重要な部分を
各所にちりばめてそれをやってるから
俺の発言をすべて批判したら、お前の選択肢が大幅になくなる
そのための長文だ
俺は技術的に減るものはないけど、おれの発言や人格を批判した奴は
様々な選択肢に制約がかかるだろうな
だから存分に俺をバカにしなさい、俺にデメリットはない
部分的な批判されると困るけど、ここまで言われてそれをすると
その無駄に高いプライドに傷がつくよね
480 ：デフォルトの名無しさん：2011/11/02(水) 16:45:24.89
481 ：デフォルトの名無しさん：2011/11/02(水) 16:47:00.51
よくわからんのだけど、彼の違う意見を持つのは一人という感覚に見える。
482 ：デフォルトの名無しさん：2011/11/02(水) 17:04:41.75
原発が爆発してからよくわかった
普段から空気読めよと主張している奴が風評ひょーうと言って押し付けてる
明らかに異常な状態の中でクールな俺ら最強じゃねというアホども
何騒いでんだよみっともない、たかが原発が爆発しただけじゃねーか
自分の命を削ってまで周りに合わせようという努力
汚染された空気を読めないくせに俺みたいに空気読めよと押し付ける
ついでに汚染された食い物も押し付ける
これを見てると自分で考えない人たちがいかに危険かがわかる
だから全部疑うことにした
メリットデメリットがはっきりわからないものは全て疑うことにした
そうしなければただちに死ぬ
お前の押し付けているその考えは汚染されている可能性があります
普段から空気読めよと主張している奴が風評ひょーうと言って押し付けてる
明らかに異常な状態の中でクールな俺ら最強じゃねというアホども
何騒いでんだよみっともない、たかが原発が爆発しただけじゃねーか
自分の命を削ってまで周りに合わせようという努力
汚染された空気を読めないくせに俺みたいに空気読めよと押し付ける
ついでに汚染された食い物も押し付ける
これを見てると自分で考えない人たちがいかに危険かがわかる
だから全部疑うことにした
メリットデメリットがはっきりわからないものは全て疑うことにした
そうしなければただちに死ぬ
お前の押し付けているその考えは汚染されている可能性があります
483 ：デフォルトの名無しさん：2011/11/02(水) 17:21:48.45
なんだ霊感商法か
484 ：デフォルトの名無しさん：2011/11/02(水) 17:30:27.86
elizaに世話になったほうが・・・。
485 ：デフォルトの名無しさん：2011/11/02(水) 17:43:09.33
>>482
お前の押し付けているその考えは汚染されている可能性があります
お前の押し付けているその考えは汚染されている可能性があります
486 ：デフォルトの名無しさん：2011/11/02(水) 17:45:58.76
あの人頭おかしいから言ってることは聞かないほうがいいよ
いまさら反原発なんてできるわけがない
原発は絶対安全だって東大の偉い人たちだって言ってるし
大丈夫だよ、空気読めよ
逆らったらお前も頭 が お か し いことにしてやるからな
いまさら反原発なんてできるわけがない
原発は絶対安全だって東大の偉い人たちだって言ってるし
大丈夫だよ、空気読めよ
逆らったらお前も頭 が お か し いことにしてやるからな
487 ：デフォルトの名無しさん：2011/11/02(水) 17:53:47.32
多数派の意見を尊重して権力に媚て
少数派の意見をバカにして軽視するハッカーの皆さんへ
もう一度読み返してみてはいかがでしょうか
結局、チキンだから多数派にいなければ落ち着かないんだろ
空気を尊重し多数派に媚びるチキンハッカー
今からハッキングですかお疲れ様です、チキンは照り焼きでお願いします
少数派の意見をバカにして軽視するハッカーの皆さんへ
もう一度読み返してみてはいかがでしょうか
結局、チキンだから多数派にいなければ落ち着かないんだろ
空気を尊重し多数派に媚びるチキンハッカー
今からハッキングですかお疲れ様です、チキンは照り焼きでお願いします
488 ：デフォルトの名無しさん：2011/11/02(水) 18:02:11.00
あ、ついでに俺の分も頼むわ。
テリヤキ二つな。
テリヤキ二つな。
489 ：デフォルトの名無しさん：2011/11/02(水) 18:07:16.12
勿論代金はお前持ちでな
490 ：デフォルトの名無しさん：2011/11/02(水) 18:44:45.17
空気に流されるな、か…
「サービスインに間に合わない？増員だ！ 」
というドカタ現場の常識に染まって
自分こそ空気に流されていることにすら気付かない奴が言うと
説 得 力 が 違 う な ！
「サービスインに間に合わない？増員だ！ 」
というドカタ現場の常識に染まって
自分こそ空気に流されていることにすら気付かない奴が言うと
説 得 力 が 違 う な ！
491 ：デフォルトの名無しさん：2011/11/02(水) 18:51:27.10
なんか明らかに煽ってる意見が出てる。この人のことをおもちゃだとおもってっだろ？
492 ：デフォルトの名無しさん：2011/11/02(水) 18:52:40.08
マトモに出来る人間と絡んだことないんだろ
ドカタの中の出来る奴なんて
やっとこ普通レベルだしな
ドカタの中の出来る奴なんて
やっとこ普通レベルだしな
493 ：デフォルトの名無しさん：2011/11/02(水) 20:26:01.99
精鋭と兵隊が一緒に働くにしろ、スキルも違えば作るものも違うんだから
皆で仲良く同じ言語使う必要無いんだけどなー
今時、大規模なシステムを1個の複雑なソフトとして作ることの方が稀だし
つーか、プロジェクトの難しい部分って、ぼんくらの頭数だけ揃えて時間かけても解けないんだよね
効率とか以前の問題で、可能か不可能かのレベルで違う
だから兵隊だけ集めてもプロジェクトは廻らん
皆で仲良く同じ言語使う必要無いんだけどなー
今時、大規模なシステムを1個の複雑なソフトとして作ることの方が稀だし
つーか、プロジェクトの難しい部分って、ぼんくらの頭数だけ揃えて時間かけても解けないんだよね
効率とか以前の問題で、可能か不可能かのレベルで違う
だから兵隊だけ集めてもプロジェクトは廻らん
494 ：デフォルトの名無しさん：2011/11/02(水) 20:29:12.68
あと、うちでは難しい部分は静的型付け言語でキッチリ書いて、
簡単なところは動的型付け言語でサクッとやっちゃってるんだけど
このスレでは逆の方が良いって論調？
簡単なところは動的型付け言語でサクッとやっちゃってるんだけど
このスレでは逆の方が良いって論調？
495 ：デフォルトの名無しさん：2011/11/02(水) 21:25:58.27
Haskellだって静的型ですよ。
バグを出さないと言っている天才さんはおいておいて、
型の間違いを検出してくれる方がいいでしょ。
それなりの頭があれば理解できる事だと思うんだけど。
プログラマのくせに楽をするのが悪だと思ってるのかねえ…。
バグを出さないと言っている天才さんはおいておいて、
型の間違いを検出してくれる方がいいでしょ。
それなりの頭があれば理解できる事だと思うんだけど。
プログラマのくせに楽をするのが悪だと思ってるのかねえ…。
496 ：デフォルトの名無しさん：2011/11/02(水) 21:47:23.22
Haskell >> ぬるぽの壁 >> Java >> ダウンキャストの壁 >> Dart
皆楽したいからJavaみたいな冗長かつぬるぽな言語を避けようとしてるんじゃん
皆楽したいからJavaみたいな冗長かつぬるぽな言語を避けようとしてるんじゃん
497 ：デフォルトの名無しさん：2011/11/02(水) 22:04:59.08
さらにその左には依存型の壁があったりする
具体的に言うとモナド則を保証するモナドしか受け付けない型とか書ける
具体的に言うとモナド則を保証するモナドしか受け付けない型とか書ける
498 ：デフォルトの名無しさん：2011/11/02(水) 22:09:46.93
いいよね依存型
仕事で使ったこと無いけど
仕事で使ったこと無いけど
499 ：デフォルトの名無しさん：2011/11/02(水) 22:15:21.12
ヌルやキャストは戦略的撤退のようなもので
それが下手糞なやつは、全滅するまで意地を張るから困る
それが下手糞なやつは、全滅するまで意地を張るから困る
500 ：デフォルトの名無しさん：2011/11/02(水) 22:20:47.43
Haskelなんか実用で使ってるとこあんの
501 ：デフォルトの名無しさん：2011/11/02(水) 22:23:19.73
アルゴリズムトレードのシステムとかで結構使用例があるみたいだよ
502 ：デフォルトの名無しさん：2011/11/02(水) 22:36:11.12
haskellはええぞ。haskellはええぞ。haskellはええぞ。haskellはええぞ。
でも、学習時間が比較的長くかかるような気がする。モナドまで理解しようと
しなくてもプログラミングはできる。でも、この言語実際に仕事で
使った人がブログで書いてたのはやっぱり少人数向けなんだなと思った。
haskeller位になるとそれなりにプライドもあるだろうから、俺が俺がになるん
かもしれん。金融系のほうでは関数型つかってるところがチラホラあるらしいね。
外資だったと思うが。
でも、学習時間が比較的長くかかるような気がする。モナドまで理解しようと
しなくてもプログラミングはできる。でも、この言語実際に仕事で
使った人がブログで書いてたのはやっぱり少人数向けなんだなと思った。
haskeller位になるとそれなりにプライドもあるだろうから、俺が俺がになるん
かもしれん。金融系のほうでは関数型つかってるところがチラホラあるらしいね。
外資だったと思うが。
503 ：デフォルトの名無しさん：2011/11/03(木) 06:12:42.98
一人でやる分にはどの言語使ってもいいしな
504 ：デフォルトの名無しさん：2011/11/03(木) 13:33:05.29
だから、引きこもり系ハッカーは動的言語か関数型に突っ走る。あれは
ヒッキーのための言語。だから、リッチーヒッキー(Clojureの作者)が教祖になる。
ヒッキーのための言語。だから、リッチーヒッキー(Clojureの作者)が教祖になる。
505 ：デフォルトの名無しさん：2011/11/03(木) 13:50:45.85
関数型は天才言語だから普及しないと思う
天才はやるまえから何もかもがわかるから
失敗する確立の高さを最初から知ってて成功確率が低い事案は積極的に行わない
だから関数型で偉大な成果が残ることはほとんどない
諦めの悪い凡人が使いそうな言語が一番成果が残る
だから凡人に理解できる言語がいいんだ
天才よりもオタクの方がいいんだ
天才はやるまえから何もかもがわかるから
失敗する確立の高さを最初から知ってて成功確率が低い事案は積極的に行わない
だから関数型で偉大な成果が残ることはほとんどない
諦めの悪い凡人が使いそうな言語が一番成果が残る
だから凡人に理解できる言語がいいんだ
天才よりもオタクの方がいいんだ
506 ：デフォルトの名無しさん：2011/11/03(木) 14:12:19.62
こんな高度な言語使える俺凄いみたいな奴ばっか
態度だけでかくて、まともなプログラム作れない
態度だけでかくて、まともなプログラム作れない
507 ：デフォルトの名無しさん：2011/11/03(木) 14:38:18.86
ブルーカラーの言語Javaと比べちゃうと、そういう傾向はあるな
508 ：デフォルトの名無しさん：2011/11/03(木) 14:43:42.40
無能系ドカタはJavaに走る。開発効率の悪さは
人数とサービス残業で埋め合わせる。
人数とサービス残業で埋め合わせる。
509 ：デフォルトの名無しさん：2011/11/03(木) 14:57:49.96
510 ：デフォルトの名無しさん：2011/11/03(木) 14:59:11.18
世の中の仕事は全部ドカタとかいう馬鹿がいるけど、
それってドカタの周りにはドカタ仕事しか集まらないだけだよね
それってドカタの周りにはドカタ仕事しか集まらないだけだよね
511 ：デフォルトの名無しさん：2011/11/03(木) 15:01:52.87
どうでも壁があるのは事実で、
fizzbuzzの壁、再帰の壁、高階関数の壁。。。 段階を追っていろいろある
高階関数については、最初にJavaとかCをやると面食らうのは当然だと思う。
最初から関数型をやる他人より敷居が高くなる原因の一つ。
高度な抽象化ができるような技量があれば、土方とは言われる状況に
ならんわな
fizzbuzzの壁、再帰の壁、高階関数の壁。。。 段階を追っていろいろある
高階関数については、最初にJavaとかCをやると面食らうのは当然だと思う。
最初から関数型をやる他人より敷居が高くなる原因の一つ。
高度な抽象化ができるような技量があれば、土方とは言われる状況に
ならんわな
512 ：デフォルトの名無しさん：2011/11/03(木) 15:03:42.02
cはポインタの壁があったな。ポインタを理解してたら、動的でも有利だけどな。
513 ：デフォルトの名無しさん：2011/11/03(木) 15:32:32.28
ポインタの壁を超えられないバカのためのJavaなのに
ぬるぽで苦しめられるとか皮肉だな
ぬるぽで苦しめられるとか皮肉だな
514 ：デフォルトの名無しさん：2011/11/03(木) 16:10:47.05
gcでポインタを上手に隠蔽した所で、隠し切れないところは出てくるからね。
でもこの板に来るような人って、最低限そのくらいの壁を超えてそうに思うけど
甘いかな？
でもこの板に来るような人って、最低限そのくらいの壁を超えてそうに思うけど
甘いかな？
515 ：デフォルトの名無しさん：2011/11/03(木) 16:32:34.74
>>512
参照にはないポインタ特有の発想の壁もあるけど
あれの最大の壁は表記の壁だと思う…例えば
ポインタ宣言時、型のほうではなく変数名のほうに付ける要素であるということ、
それでいて代入時はそれが要らないこと、
配列と混じった場合の優先順位の解りにくさ、関数ポインタのカオス書式
この辺りは表記がもうちょい考慮されてたら脱落者が相当減ると思うのだが…
参照にはないポインタ特有の発想の壁もあるけど
あれの最大の壁は表記の壁だと思う…例えば
ポインタ宣言時、型のほうではなく変数名のほうに付ける要素であるということ、
それでいて代入時はそれが要らないこと、
配列と混じった場合の優先順位の解りにくさ、関数ポインタのカオス書式
この辺りは表記がもうちょい考慮されてたら脱落者が相当減ると思うのだが…
516 ：デフォルトの名無しさん：2011/11/03(木) 17:03:37.21
確かに配列とポインタ変数は紛らわしいが
型にポインタつけるのはC的には無しだろうな
変に参照やらクロージャやらなんやら取り込んだC++はアレだがね
Java位でいんじゃね
型にポインタつけるのはC的には無しだろうな
変に参照やらクロージャやらなんやら取り込んだC++はアレだがね
Java位でいんじゃね
517 ：デフォルトの名無しさん：2011/11/04(金) 05:08:59.49
高階関数をあつかえるのは関数型言語だけ、みたいな思い込みが多いな。
自画自賛も結構だが、高階関数や遅延評価ぐらいで唯我独尊するのって恥ずかしいよね。
自画自賛も結構だが、高階関数や遅延評価ぐらいで唯我独尊するのって恥ずかしいよね。
518 ：デフォルトの名無しさん：2011/11/04(金) 05:20:12.85
思い込みに見えるのは妄想がすぎるからでは？ void風
519 ：デフォルトの名無しさん：2011/11/04(金) 05:57:41.31
まさか、高階関数は関数型言語でしか実装できないとか
本気で思い込んでるのか？
本気で思い込んでるのか？
520 ：デフォルトの名無しさん：2011/11/04(金) 06:45:59.87
再帰や高階関数を理解して使いこなせないと
関数型言語ではまともにプログラミングできないだろうな、とは思う
関数型言語ではまともにプログラミングできないだろうな、とは思う
521 ：デフォルトの名無しさん：2011/11/04(金) 07:54:28.65
高階関数はとても重要ですね
let sum x y = x + y
と書いたら sum の型は当然 int->(int->int) になる。それが高階関数ですよね
高階関数が無ければ
let incr = sum 1
という定義ができません。これはあまりに非効率で話になりません
let sum x y = x + y
と書いたら sum の型は当然 int->(int->int) になる。それが高階関数ですよね
高階関数が無ければ
let incr = sum 1
という定義ができません。これはあまりに非効率で話になりません
522 ：デフォルトの名無しさん：2011/11/04(金) 07:56:41.03
と int に決める理由もないですね。これはうっかり
sum は + が定義される任意の型 'a に対して 'a->('a->'a) となるべきでした
sum は + が定義される任意の型 'a に対して 'a->('a->'a) となるべきでした
523 ：デフォルトの名無しさん：2011/11/04(金) 08:42:14.38
それは高階関数だけじゃなくて、カリー化もサポートしてる言語の話だな
もちろんカリー化があるほうが便利
もちろんカリー化があるほうが便利
524 ：デフォルトの名無しさん：2011/11/04(金) 09:40:01.44
>>521-522
高階関数ってのは、関数を引数に渡せたり、関数を戻り値にすることができる、関数のことだよね？
関数をカリー化するのは、高階関数を上手く利用した手法だと思うけど、
それを高階関数だって言うのは違うんじゃないの？
高階関数ってのは、関数を引数に渡せたり、関数を戻り値にすることができる、関数のことだよね？
関数をカリー化するのは、高階関数を上手く利用した手法だと思うけど、
それを高階関数だって言うのは違うんじゃないの？
525 ：デフォルトの名無しさん：2011/11/04(金) 10:37:37.08
>>523
正確に言えば、関数の部分適用な。
正確に言えば、関数の部分適用な。
526 ：デフォルトの名無しさん：2011/11/04(金) 10:40:21.51
527 ：デフォルトの名無しさん：2011/11/04(金) 10:41:40.23
カリーとかも使えれば便利だけど、分かりにくいよな。
528 ：デフォルトの名無しさん：2011/11/04(金) 10:42:14.28
スコーレム化
529 ：デフォルトの名無しさん：2011/11/04(金) 10:46:06.71
>>526
(int, int) -> intをint->int->intにするのはカリー化
(int, int) -> intからint->intにするのは部分適用
int->int->intから int->intにするのは関数適用
(int, int) -> intをint->int->intにするのはカリー化
(int, int) -> intからint->intにするのは部分適用
int->int->intから int->intにするのは関数適用
530 ：デフォルトの名無しさん：2011/11/04(金) 10:49:10.30
531 ：デフォルトの名無しさん：2011/11/04(金) 10:49:46.31
どこからとも無く沸いてくる謎のint
532 ：デフォルトの名無しさん：2011/11/04(金) 10:51:24.93
OCamlなら+演算子によってintに決まる
Haskell, SML, GCamlでは決まらない
Haskell, SML, GCamlでは決まらない
533 ：デフォルトの名無しさん：2011/11/04(金) 10:53:15.88
534 ：デフォルトの名無しさん：2011/11/04(金) 10:53:34.95
いや 加齢化 だというのはなしね。
535 ：デフォルトの名無しさん：2011/11/04(金) 10:55:28.54
OCaml って今でも 3 + 3 = 5 なの？
536 ：デフォルトの名無しさん：2011/11/04(金) 10:57:31.55
>>521において、let incr = sum 1 の操作は部分適用で、
部分適用をこの形式で記述できるなら sum はカリー化されていると言える。
部分適用をこの形式で記述できるなら sum はカリー化されていると言える。
537 ：デフォルトの名無しさん：2011/11/04(金) 10:57:57.22
>>535
違うよ、っていうか過去にそんなバージョンあったか？
違うよ、っていうか過去にそんなバージョンあったか？
538 ：デフォルトの名無しさん：2011/11/04(金) 10:59:11.95
539 ：デフォルトの名無しさん：2011/11/04(金) 11:02:02.58
540 ：デフォルトの名無しさん：2011/11/04(金) 11:06:50.06
部分適用ってなんか失敗するかもしれない適用みたいな響き
541 ：デフォルトの名無しさん：2011/11/04(金) 11:15:57.62
>>521において、仮に sum がカリー化されていないとするなら let incr = sum 1 は部分適用に相当する操作だが、
sum がカリー化されていない以上、こうは書けない。
部分適用をサポートする言語では let incr = partial(sum, 1) のように書く。
一方、sum がカリー化されているなら let incr = sum 1 はごく普通の関数適用であり、部分適用ではない。
sum がカリー化されていない以上、こうは書けない。
部分適用をサポートする言語では let incr = partial(sum, 1) のように書く。
一方、sum がカリー化されているなら let incr = sum 1 はごく普通の関数適用であり、部分適用ではない。
542 ：デフォルトの名無しさん：2011/11/04(金) 11:34:21.13
このように、開発者が無用な議論で時間を無駄にする傾向が強いので
関数型言語は大規模開発で効率が悪い
関数型言語は大規模開発で効率が悪い
543 ：デフォルトの名無しさん：2011/11/04(金) 11:39:50.46
最近はドカタでも関数型の考え方は知っとけ的な流れがある
http://www.ibm.com/developerworks/jp/views/java/libraryview.jsp?&search_by=%E9%96%A2%E6%95%B0%E5%9E%8B%E3%81%AE%E8%80%83%E3%81%88%E6%96%B9
http://www.ibm.com/developerworks/jp/views/java/libraryview.jsp?&search_by=%E9%96%A2%E6%95%B0%E5%9E%8B%E3%81%AE%E8%80%83%E3%81%88%E6%96%B9
544 ：デフォルトの名無しさん：2011/11/04(金) 12:09:41.45
ドカタというか、職業プログラマが時間をかけて関数型プログラミングを深く知るメリットはまだ少ないと思う。
一部ＬＬ系のアーリーアダプタが注目して遊んでいるという程度で、
（パイロットプロジェクトを除く）案件で使われる（＝業務経歴書上のアピールポイントになる）には、まだ数年かかると思われ。
一部ＬＬ系のアーリーアダプタが注目して遊んでいるという程度で、
（パイロットプロジェクトを除く）案件で使われる（＝業務経歴書上のアピールポイントになる）には、まだ数年かかると思われ。
545 ：デフォルトの名無しさん：2011/11/04(金) 12:26:28.78
あとたった数年で広まるのか
随分明るい未来だな
随分明るい未来だな
546 ：デフォルトの名無しさん：2011/11/04(金) 12:33:16.72
この業界に身を置いていれば誰でも同意するだろうが
これまでの数年とこれからの数年はスピードが全く違うことが予想される
これまでの数年とこれからの数年はスピードが全く違うことが予想される
547 ：デフォルトの名無しさん：2011/11/04(金) 12:34:48.99
しかし人間の側はそう簡単に変われないので
ドカタと精鋭の二極化が進むんですね
ドカタと精鋭の二極化が進むんですね
548 ：デフォルトの名無しさん：2011/11/04(金) 12:37:58.63
だな。だがそこで精鋭を目指す奴はこの業界向いてない。
職業プログラマなら「食っていけるドカタ」を目指す割り切りが必要
職業プログラマなら「食っていけるドカタ」を目指す割り切りが必要
549 ：デフォルトの名無しさん：2011/11/04(金) 12:53:34.01
ちょっと違うな
16進のブートシークエンスを手打ちしていた「本物のプログラマ」や
昔ベーマガ読んでたオッサンは、確かに「そう簡単には変われない」
変わるのは世代
子供の頃からインターネットが存在するのが当然で
ファーストクラスの関数が当たり前に利用できる言語で育った若い世代が
年寄りを駆逐していくだけ
16進のブートシークエンスを手打ちしていた「本物のプログラマ」や
昔ベーマガ読んでたオッサンは、確かに「そう簡単には変われない」
変わるのは世代
子供の頃からインターネットが存在するのが当然で
ファーストクラスの関数が当たり前に利用できる言語で育った若い世代が
年寄りを駆逐していくだけ
550 ：デフォルトの名無しさん：2011/11/04(金) 13:05:49.84
??
lispの古さわかってんの？ ファーストクラスの関数が〜 と言ってるが。
視野狭くない？
lispの古さわかってんの？ ファーストクラスの関数が〜 と言ってるが。
視野狭くない？
551 ：デフォルトの名無しさん：2011/11/04(金) 13:07:33.91
世代交代を待つなら数年で変わるはずも無い
552 ：デフォルトの名無しさん：2011/11/04(金) 13:09:12.28
頭が普通ならばさほど時間がかからんと思うよ。問題は手続きやオブジェクト指向
で凝り固まった概念に浸った人。かれらは初心者より違うものを受け付けない傾向
にある。でも、そういった人は淘汰されるから。
速さが違うと言っても日本の中の多くは保守的な国でなかなか悪習を変えないから
その悪癖がどこまで悪影響としてでるかだよね。
で凝り固まった概念に浸った人。かれらは初心者より違うものを受け付けない傾向
にある。でも、そういった人は淘汰されるから。
速さが違うと言っても日本の中の多くは保守的な国でなかなか悪習を変えないから
その悪癖がどこまで悪影響としてでるかだよね。
553 ：デフォルトの名無しさん：2011/11/04(金) 13:11:52.21
ハードウエアが１CPUで高速化しまくる方向から変わってるからなぁ。
プログラミングも変化せざる負えないよね。実際多CPUにうまく対応
する言語もいくつも出てきてるしね。利用する何か？によってかわるだろうが
プログラミングも変化せざる負えないよね。実際多CPUにうまく対応
する言語もいくつも出てきてるしね。利用する何か？によってかわるだろうが
554 ：デフォルトの名無しさん：2011/11/04(金) 13:26:29.51
>>550
Lispは勿論古いけれども、Lispが使えるのは「当たり前」ではなかったよ
職業プログラマは、call by nameや関数のネストのような機能をALGOLから
意図的に削除したCベースの言語に長年馴染んで来たんだから
一方、今やLispや関数型言語から来た要素はJavaScriptのように
普通に使われている言語に「当たり前」にある要素だし
インターネット以降の世代では、知識ベースの共有がそれこそ桁違いだ
Lispは勿論古いけれども、Lispが使えるのは「当たり前」ではなかったよ
職業プログラマは、call by nameや関数のネストのような機能をALGOLから
意図的に削除したCベースの言語に長年馴染んで来たんだから
一方、今やLispや関数型言語から来た要素はJavaScriptのように
普通に使われている言語に「当たり前」にある要素だし
インターネット以降の世代では、知識ベースの共有がそれこそ桁違いだ
555 ：デフォルトの名無しさん：2011/11/04(金) 13:43:33.99
Lisperって態度ばかりでかくて
まともなプログラム作れない屑ばかり
まともなプログラム作れない屑ばかり
556 ：デフォルトの名無しさん：2011/11/04(金) 13:45:25.00
精鋭云々ということで言うと、日本ではプログラマとしてのセンスと
同等かそれ以上に英語が壁のような気がするな
fizzbuzz書けないのもダメだが、英語できないやつは自動的に精鋭にはなれない
同等かそれ以上に英語が壁のような気がするな
fizzbuzz書けないのもダメだが、英語できないやつは自動的に精鋭にはなれない
557 ：デフォルトの名無しさん：2011/11/04(金) 13:45:40.99
ここ数レスの中で一番態度がでかいのは555ですが、あなたはLisperですか？
558 ：デフォルトの名無しさん：2011/11/04(金) 13:54:29.35
個人的には、年寄りから若者まで、開発現場の皆が使える言語を使うのが効率的だと思う。
ま、皆が関数型言語を使うようになったら自分もそれに合わせるよ。
開発言語なんて何でもいいよ。俺が合わせるから、主義主張のある人たちで議論してください。
決まったら言って。
つー感じ。どーでもいい
ま、皆が関数型言語を使うようになったら自分もそれに合わせるよ。
開発言語なんて何でもいいよ。俺が合わせるから、主義主張のある人たちで議論してください。
決まったら言って。
つー感じ。どーでもいい
559 ：デフォルトの名無しさん：2011/11/04(金) 14:09:10.67
そんな都合のいいもんは無いよ
10年ぐらい前に業務命令でちょっとCOBOLerに親会社の誰か知らん奴が書いた
C++のコードについて説明した（教えた）ことがあるけど、要するに無理なんだよ
テンプレートを多用したコードでな、COBOLerどころかCは知ってる奴にだって
無理なコードだった
逆に言うと、今からJCLとCOBOLとPL/Iでやれとか言われても困るだろ
10年ぐらい前に業務命令でちょっとCOBOLerに親会社の誰か知らん奴が書いた
C++のコードについて説明した（教えた）ことがあるけど、要するに無理なんだよ
テンプレートを多用したコードでな、COBOLerどころかCは知ってる奴にだって
無理なコードだった
逆に言うと、今からJCLとCOBOLとPL/Iでやれとか言われても困るだろ
560 ：デフォルトの名無しさん：2011/11/04(金) 14:13:03.86
開発言語が何でもいいならこのスレいらねーだろと
561 ：デフォルトの名無しさん：2011/11/04(金) 14:47:01.36
>>556
That's right. Unfortunately, we should understand a large amount of
information about programing languages, their libraries and others
in English. In the case of punishing a project, we'd better write its
document in English. However, most of these projects have a little of
documents in English. The worst case in them is that the author wrote
a message, read the source - this has no document both in English and
Japanese.
It is a problem for Japanese that learning English is by far more
difficult than learning programing languages.
That's right. Unfortunately, we should understand a large amount of
information about programing languages, their libraries and others
in English. In the case of punishing a project, we'd better write its
document in English. However, most of these projects have a little of
documents in English. The worst case in them is that the author wrote
a message, read the source - this has no document both in English and
Japanese.
It is a problem for Japanese that learning English is by far more
difficult than learning programing languages.
562 ：デフォルトの名無しさん：2011/11/04(金) 15:10:56.75
自分ができることをやってない他人は怠け者だって考えをしてる奴は傲慢だな
エジソンは親が教育を放棄してたらただの変人
ヘレンケラーは親が金持ちじゃなかったら殺されてただろう
お前の能力はお前の努力で得たものではなく九割以上は環境に恵まれてから
ほぼ同じ環境にある奴同士で努力を競うならいいだろうが
まったく環境が異なる奴相手に努力しろと言ってる奴は見下してるだけ
お前が歴史に残るような偉業を成し遂げていないのなら
お前は凡人だよ、リソースを食い荒らして不幸を撒き散らしただけのただの愚か者
自分を有能だと思うのなら他人の利益になることをやれよ
俺みたいに世を呪わなければ正気を保てないような奴を見下して遊んでるんじゃない
このクソ虫ども、死ねよ
エジソンは親が教育を放棄してたらただの変人
ヘレンケラーは親が金持ちじゃなかったら殺されてただろう
お前の能力はお前の努力で得たものではなく九割以上は環境に恵まれてから
ほぼ同じ環境にある奴同士で努力を競うならいいだろうが
まったく環境が異なる奴相手に努力しろと言ってる奴は見下してるだけ
お前が歴史に残るような偉業を成し遂げていないのなら
お前は凡人だよ、リソースを食い荒らして不幸を撒き散らしただけのただの愚か者
自分を有能だと思うのなら他人の利益になることをやれよ
俺みたいに世を呪わなければ正気を保てないような奴を見下して遊んでるんじゃない
このクソ虫ども、死ねよ
563 ：デフォルトの名無しさん：2011/11/04(金) 15:11:27.48
564 ：デフォルトの名無しさん：2011/11/04(金) 15:53:39.11
>>563
it is not necessary to ensure all guys are familiar with the same programming language,
but a project of a team that has no experienced people for the language could be risky.
it is not necessary to ensure all guys are familiar with the same programming language,
but a project of a team that has no experienced people for the language could be risky.
565 ：デフォルトの名無しさん：2011/11/04(金) 16:05:09.50
OOP脳に凝り固まったJava PGに関数型は無理
http://local.joelonsoftware.com/wiki/%E5%90%9B%E3%81%AE%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E8%A8%80%E8%AA%9E%E3%81%A7%E3%80%81%E3%81%93%E3%82%8C%E3%80%81%E3%81%A7%E3%81%8D%E3%82%8B%3F
http://d.hatena.ne.jp/kazu-yamamoto/20080722/1216734420/
http://local.joelonsoftware.com/wiki/%E5%90%9B%E3%81%AE%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E8%A8%80%E8%AA%9E%E3%81%A7%E3%80%81%E3%81%93%E3%82%8C%E3%80%81%E3%81%A7%E3%81%8D%E3%82%8B%3F
http://d.hatena.ne.jp/kazu-yamamoto/20080722/1216734420/
566 ：デフォルトの名無しさん：2011/11/04(金) 16:13:01.56
>>561
× It is a problem for Japanese that learning English is by far more
○ It is a problem for the Japanese that learning English is by far more
× It is a problem for Japanese that learning English is by far more
○ It is a problem for the Japanese that learning English is by far more
567 ：デフォルトの名無しさん：2011/11/04(金) 16:15:00.64
568 ：デフォルトの名無しさん：2011/11/04(金) 16:28:31.49
いや、Javaのような言語は劣ってるとしか書いてないよね？
569 ：デフォルトの名無しさん：2011/11/04(金) 16:58:13.32
>>568
キミ、読解力が絶望的に低いねw
キミ、読解力が絶望的に低いねw
570 ：デフォルトの名無しさん：2011/11/04(金) 17:02:32.13
ハスケルの人達ってみんなこんな我田引水なの？
571 ：デフォルトの名無しさん：2011/11/04(金) 17:04:37.05
ハスケラーか。
ジャバラに比べると如何せん繁殖率が悪い。
ジャバラに比べると如何せん繁殖率が悪い。
572 ：デフォルトの名無しさん：2011/11/04(金) 17:09:29.07
別にHaskellerが特別関係してるってわけじゃない
Javaが他の言語と比べてぶっちぎりで劣ってるって話だから
Javaが他の言語と比べてぶっちぎりで劣ってるって話だから
573 ：デフォルトの名無しさん：2011/11/04(金) 17:13:33.36
Javaを槍玉に挙げてOOP叩くな、ってことでしょ？
名詞とか動詞とか、いつの時代のOOA/OODよ
名詞とか動詞とか、いつの時代のOOA/OODよ
574 ：デフォルトの名無しさん：2011/11/04(金) 17:19:05.04
天才言語使ってる奴ってレイシストばかりだな
居場所はリアルにいくらでもあるくせに
落伍者の集まる場所にまで押し寄せてきやがる
俺バカだからバカ言語の方が居心地がいいや
居場所はリアルにいくらでもあるくせに
落伍者の集まる場所にまで押し寄せてきやがる
俺バカだからバカ言語の方が居心地がいいや
575 ：デフォルトの名無しさん：2011/11/04(金) 17:35:06.72
Haskell使ってるのは今でも少数派だろ
ただ今時のLLは大抵レキシカルクロージャをサポートしていて
map, filter, reduceぐらいのことは標準でできる
C#でもできるしC++も11でようやくlambdaが入った
要は既にその程度は標準でありふれているものであって
C#やC++を見ればそれが圧倒的に世界の趨勢なのだと分かる
よって、そうした環境で育った子がJavaでの開発にはフラストレーションを感じる
可能性は高いだろう
ただ今時のLLは大抵レキシカルクロージャをサポートしていて
map, filter, reduceぐらいのことは標準でできる
C#でもできるしC++も11でようやくlambdaが入った
要は既にその程度は標準でありふれているものであって
C#やC++を見ればそれが圧倒的に世界の趨勢なのだと分かる
よって、そうした環境で育った子がJavaでの開発にはフラストレーションを感じる
可能性は高いだろう
576 ：デフォルトの名無しさん：2011/11/04(金) 17:42:58.90
Javaはそんなに簡単ではないと思う
静的型と実行時型情報が共存していたら混乱するのが普通だろう
静的型と実行時型情報が共存していたら混乱するのが普通だろう
577 ：デフォルトの名無しさん：2011/11/04(金) 17:45:28.99
まあコボラの二の舞にだけはなるなよ
Javaの仕事はすぐにはなくならないだろうから、それをやっていればいい
若い人に無理やりCOBOLのやりかたを押し付けることだけはするな
Javaの仕事はすぐにはなくならないだろうから、それをやっていればいい
若い人に無理やりCOBOLのやりかたを押し付けることだけはするな
578 ：デフォルトの名無しさん：2011/11/04(金) 18:43:59.68
まぁまぁそんな怒りなさんな。その元記事って
excelのチーフマネージャーだろ？Ｈａｓｋｅｌｌとは関係ない人ちゃう？
excelのチーフマネージャーだろ？Ｈａｓｋｅｌｌとは関係ない人ちゃう？
579 ：デフォルトの名無しさん：2011/11/04(金) 18:53:24.46
頭を固くしないためにも２，３年に一つは新しい言語にトライすることは
いいよ。年寄りが頭が硬いと思われてるは新しいことにトライする気力が
生まれないから。新しいものにトライするのがダリーっていうタイプは、
年齢にかかわらず終わってるのは事実かも。
いいよ。年寄りが頭が硬いと思われてるは新しいことにトライする気力が
生まれないから。新しいものにトライするのがダリーっていうタイプは、
年齢にかかわらず終わってるのは事実かも。
580 ：デフォルトの名無しさん：2011/11/04(金) 18:55:06.63
1年に一つとか言うのもあるけど流石にそれは浅くなりすぎるからな
2,3年に一つは丁度いいと思う
2,3年に一つは丁度いいと思う
581 ：デフォルトの名無しさん：2011/11/04(金) 19:00:28.30
>>576
じゃあHaskellもだめだな
じゃあHaskellもだめだな
582 ：デフォルトの名無しさん：2011/11/04(金) 19:01:46.18
>>579
ハスケラはハスケル最高で思考停止だけどな
ハスケラはハスケル最高で思考停止だけどな
583 ：デフォルトの名無しさん：2011/11/04(金) 19:09:39.19
584 ：デフォルトの名無しさん：2011/11/04(金) 19:12:20.61
C言語は、新しいアセンブリ言語にトライする人達にひどいことをしたよね
585 ：デフォルトの名無しさん：2011/11/04(金) 19:18:30.85
新しいことにチャレンジすることが大好きな天才たちは
一つの会社に永久就職して起業は考えないのであった
それが日本式
日本で起業するのは社会からあぶれた連中か
最初から起業する気でいた連中だけ
他人に自分のやってきた努力は要求するくせに
他人から言われた努力はやろうともしない
その程度のチャレンジャー、その程度の向上心
頭を硬くしないために見下せる他人を探して説教する
それが日本式エリート
かっこ良すぎですわ
こっちは疲弊して余力もないっての
一つの会社に永久就職して起業は考えないのであった
それが日本式
日本で起業するのは社会からあぶれた連中か
最初から起業する気でいた連中だけ
他人に自分のやってきた努力は要求するくせに
他人から言われた努力はやろうともしない
その程度のチャレンジャー、その程度の向上心
頭を硬くしないために見下せる他人を探して説教する
それが日本式エリート
かっこ良すぎですわ
こっちは疲弊して余力もないっての
586 ：デフォルトの名無しさん：2011/11/04(金) 19:20:01.78
なんか 妄想が爆発してる人がでてきてるけど 大丈夫？
ネタで煽ってるだけにしか見えない。
ネタで煽ってるだけにしか見えない。
587 ：デフォルトの名無しさん：2011/11/04(金) 19:20:48.43
C++はプログラマに能力を要求しすぎだし
Javaはプログラマをアホと仮定して便利な機能も入れないので不便。
Javaはプログラマをアホと仮定して便利な機能も入れないので不便。
588 ：デフォルトの名無しさん：2011/11/04(金) 19:28:22.79
俺お前らみたいな自称天才、努力してきましたエリートよりも
ドカタの方を尊敬してるよ
原発爆発したエリート東大卒は責任転嫁して逃げ回って給料だけは現状維持
現場のドカタは薄給で命を削って作業して
偉い東大の先生たちはプルトニウムは重くて飛ばないと言う
ドカタの方が尊敬に値する、むしろドカタを尊敬すべき
特攻隊も下っ端だろ、それを立案したエリートは敵前逃亡
やっぱり下で作業する頭の固いやつらの方が
人として尊敬できるよ
保身のための努力よりも、社会のための献身の方が偉いよ
新しい言語覚えたりするのって保身のための努力だろ
それを他人に強要し始めてる時点で人としてのレベルがね
こっちはお前らの構築してきたシステムに振り回されて死にそうだってのに
お前たちはずいぶんと余裕だね
ドカタの方を尊敬してるよ
原発爆発したエリート東大卒は責任転嫁して逃げ回って給料だけは現状維持
現場のドカタは薄給で命を削って作業して
偉い東大の先生たちはプルトニウムは重くて飛ばないと言う
ドカタの方が尊敬に値する、むしろドカタを尊敬すべき
特攻隊も下っ端だろ、それを立案したエリートは敵前逃亡
やっぱり下で作業する頭の固いやつらの方が
人として尊敬できるよ
保身のための努力よりも、社会のための献身の方が偉いよ
新しい言語覚えたりするのって保身のための努力だろ
それを他人に強要し始めてる時点で人としてのレベルがね
こっちはお前らの構築してきたシステムに振り回されて死にそうだってのに
お前たちはずいぶんと余裕だね
589 ：デフォルトの名無しさん：2011/11/04(金) 19:42:35.94
好き嫌いは別として
C++が無理程度のやつは
どっちにしろ大したもんは作れない
C++が無理程度のやつは
どっちにしろ大したもんは作れない
590 ：デフォルトの名無しさん：2011/11/04(金) 19:49:41.34
結局お前たちの努力なんてやらなくていい努力を全部排除して
必要最小限の部分だけの努力なんだ
生活するための努力、立場を得るための努力
環境を得るための努力、それら様々な努力をしなくても
生まれつき持っている
お前は勉強する努力だけでいいんだからな
それだけやって楽に高学歴を得て、時間が余ったから言語オタやって気楽でいいよな
一度何もかも捨ててやらなくてもよかった努力をすべてやった上で
言語オタやれるんだったら
それで認めてやるよ
必要最小限の部分だけの努力なんだ
生活するための努力、立場を得るための努力
環境を得るための努力、それら様々な努力をしなくても
生まれつき持っている
お前は勉強する努力だけでいいんだからな
それだけやって楽に高学歴を得て、時間が余ったから言語オタやって気楽でいいよな
一度何もかも捨ててやらなくてもよかった努力をすべてやった上で
言語オタやれるんだったら
それで認めてやるよ
591 ：デフォルトの名無しさん：2011/11/04(金) 19:50:19.06
動的なんてどうってことない！
なんつってなwwwwwwwwwwwwwwwwwwwwww
なんつってなwwwwwwwwwwwwwwwwwwwwww
592 ：デフォルトの名無しさん：2011/11/04(金) 20:09:19.44
593 ：デフォルトの名無しさん：2011/11/04(金) 20:13:44.88
594 ：デフォルトの名無しさん：2011/11/04(金) 20:26:09.24
595 ：デフォルトの名無しさん：2011/11/04(金) 20:44:40.31
他人のコードを読むのが辛いのはRubyだな
596 ：デフォルトの名無しさん：2011/11/04(金) 20:45:27.65
アセンブリは低級プログラミング言語だが何か？
597 ：デフォルトの名無しさん：2011/11/04(金) 22:01:42.83
すっかり動的型付けとは関係無い話になったな
まあ高階関数やクロージャの有無に比べれば静的/動的なんて些細な違いだからな
まあ高階関数やクロージャの有無に比べれば静的/動的なんて些細な違いだからな
598 ：デフォルトの名無しさん：2011/11/04(金) 23:01:26.03
いいんだよ。ここはチラウラだから
599 ：デフォルトの名無しさん：2011/11/04(金) 23:59:05.07
お前らろくなもん作れないんだろうなぁ
600 ：デフォルトの名無しさん：2011/11/05(土) 05:41:59.53
うん
601 ：デフォルトの名無しさん：2011/11/05(土) 07:57:09.79
高階関数やクロージャがあっても動的型付けではどうしようもない
動的型つけ言語で効率がいいのは手のひらサイズまで
動的型つけ言語で効率がいいのは手のひらサイズまで
602 ：デフォルトの名無しさん：2011/11/05(土) 08:17:28.79
逆だろ。クロージャなんてあってもなくてもどうにでもなるけど、型付けが静的か動的かって言うのは致命的な差を生む。
603 ：デフォルトの名無しさん：2011/11/05(土) 08:31:10.27
２０万行のC++をschemeで書き換えたら３万行。
たしかにコンパクトになる。>>601 無駄に膨れてるから錯覚を起こすのでは？
たしかにコンパクトになる。>>601 無駄に膨れてるから錯覚を起こすのでは？
604 ：デフォルトの名無しさん：2011/11/05(土) 09:03:03.73
致命的と確定すれば後は開き直るだけだが
静的と動的が入り乱れる言語を選ぶと、一挙手一投足が致命傷となりうる恐怖の連続
静的と動的が入り乱れる言語を選ぶと、一挙手一投足が致命傷となりうる恐怖の連続
605 ：デフォルトの名無しさん：2011/11/05(土) 09:56:41.96
多分Java8にクロージャが入るまで
クロージャなんて重要じゃないと言い続けるよ
だってJavaドカタだから
クロージャなんて重要じゃないと言い続けるよ
だってJavaドカタだから
606 ：デフォルトの名無しさん：2011/11/05(土) 11:55:20.35
>２０万行のC++をschemeで書き換えたら３万行
脳内移植御苦労さん
脳内移植御苦労さん
607 ：デフォルトの名無しさん：2011/11/05(土) 11:58:40.13
http://groups.google.com/group/clojure/browse_thread/thread/b18f9006c068f0a0?pli=1
短く書けると噂のScalaでも、
Clojureと比べるとこんだけ差が出るんだな
短く書けると噂のScalaでも、
Clojureと比べるとこんだけ差が出るんだな
608 ：デフォルトの名無しさん：2011/11/05(土) 12:02:36.23
609 ：デフォルトの名無しさん：2011/11/05(土) 12:23:14.30
610 ：デフォルトの名無しさん：2011/11/05(土) 12:25:15.11
611 ：デフォルトの名無しさん：2011/11/05(土) 12:26:44.29
612 ：デフォルトの名無しさん：2011/11/05(土) 12:30:16.88
1000行以上のプログラム書いたことない奴は帰れよ
613 ：デフォルトの名無しさん：2011/11/05(土) 12:32:04.28
ああ、1000行以上のプログラム書いた事無いから
大規模になったら「理由も無く」差が無くなると思っちゃったんだね
大規模になったら「理由も無く」差が無くなると思っちゃったんだね
614 ：デフォルトの名無しさん：2011/11/05(土) 12:35:09.68
1000行以上のプログラム書いたことないの
おまえだろw
おまえだろw
615 ：デフォルトの名無しさん：2011/11/05(土) 12:35:58.29
コンパクトなことが静的型付けよりも常に価値があるとは思わんが、
動的型言語の方がそりゃコンパクトに書けるだろうよ。
動的型言語の方がそりゃコンパクトに書けるだろうよ。
616 ：デフォルトの名無しさん：2011/11/05(土) 12:40:33.73
動的型付けのコンパクトってのは
腕切り落として体重が減ったって喜ぶようなもん
腕切り落として体重が減ったって喜ぶようなもん
617 ：デフォルトの名無しさん：2011/11/05(土) 12:43:27.35
Lispはmacro generating macrosを駆使すれば
異様にコードを圧縮する事も可能だが、保守は絶望的・・・
異様にコードを圧縮する事も可能だが、保守は絶望的・・・
618 ：デフォルトの名無しさん：2011/11/05(土) 12:52:02.37
動的厨は何か大規模ソフトを短く書きなおしてみろよ
短くかけるんだからすぐできるだろw
短くかけるんだからすぐできるだろw
619 ：デフォルトの名無しさん：2011/11/05(土) 13:00:51.31
あれ、規模が大きくなったら差が縮まることの説明は無し？
逃亡しちゃったの？
逃亡しちゃったの？
620 ：デフォルトの名無しさん：2011/11/05(土) 13:05:47.62
ある規模を超えるとどっちにしろ殆どの人間にとって扱え切れない化け物になってしまうのは割と共通しているんじゃね？ｗ
そういう意味では差が縮まると言っていいかも
そういう意味では差が縮まると言っていいかも
621 ：デフォルトの名無しさん：2011/11/05(土) 13:06:07.64
そもそもそんな差ないし
622 ：デフォルトの名無しさん：2011/11/05(土) 13:19:20.61
>>620
動的型付けの場合は殆どじゃなくて全ての人間でしょ
動的型付けの場合は殆どじゃなくて全ての人間でしょ
623 ：デフォルトの名無しさん：2011/11/05(土) 13:47:41.05
てか作るもので言語選べばいいだけだろ…
まさか一つの言語しか使えないワケでもあるまいし
でもjavaにクロージャはいらんよな
まさか一つの言語しか使えないワケでもあるまいし
でもjavaにクロージャはいらんよな
624 ：デフォルトの名無しさん：2011/11/05(土) 13:52:04.80
その選び方に関する話をしているんだろ
625 ：デフォルトの名無しさん：2011/11/05(土) 13:56:23.65
作るものによって換えざるを得ない状況を一つの言語でできるようにするってのも
Javaをはじめとする汎用プログラミング言語の目的だったはず
Javaをはじめとする汎用プログラミング言語の目的だったはず
626 ：デフォルトの名無しさん：2011/11/05(土) 13:57:13.13
ま、ドカタには複数の言語を覚える脳みそがないっつーことで
627 ：デフォルトの名無しさん：2011/11/05(土) 14:01:07.63
複数の工具が扱えるリアル土方の方がまだ有能だな
628 ：デフォルトの名無しさん：2011/11/05(土) 14:45:25.21
工具マニアじゃねーんだから
家建てられれば工具なんか何でもいい
家建てられれば工具なんか何でもいい
629 ：デフォルトの名無しさん：2011/11/05(土) 14:48:52.86
一般的に縛りプレイの方が難しい
630 ：デフォルトの名無しさん：2011/11/05(土) 14:50:14.91
ビフォーアフターじゃあるまいし早く安く簡単に作れるのが一番いいに決まってる
マジレスすると選ぶ言語によって開発者の単価から違うだろ
学者はそういう事何も考えねーから困る
マジレスすると選ぶ言語によって開発者の単価から違うだろ
学者はそういう事何も考えねーから困る
631 ：デフォルトの名無しさん：2011/11/05(土) 14:50:17.40
別にマニアじゃなくても、仕事でやってんなら
複数の言語くらい当たり前に使いこなせっての
Windows + Java + Eclipse で育った純粋培養のドカタは
まじでJavaしか出来ないから笑えるわ
複数の言語くらい当たり前に使いこなせっての
Windows + Java + Eclipse で育った純粋培養のドカタは
まじでJavaしか出来ないから笑えるわ
632 ：デフォルトの名無しさん：2011/11/05(土) 14:52:25.90
633 ：デフォルトの名無しさん：2011/11/05(土) 14:57:14.09
純粋培養PHPerは可哀想だから煽る気にもならん
強く生きてほしい
強く生きてほしい
634 ：デフォルトの名無しさん：2011/11/05(土) 14:59:13.52
「ドカタ」ってのはこのくらいが最低限。
C の読み書きに不自由しない
何か一つのアセンブリを読める
JavaでもC#でも、手続き型オブジェクト指向言語を何か一つ使いこなせる
スクリプト言語を何か一つ使いこなせる
このくらいの素養がない奴はドカタですらない。ただのガキ
C の読み書きに不自由しない
何か一つのアセンブリを読める
JavaでもC#でも、手続き型オブジェクト指向言語を何か一つ使いこなせる
スクリプト言語を何か一つ使いこなせる
このくらいの素養がない奴はドカタですらない。ただのガキ
635 ：デフォルトの名無しさん：2011/11/05(土) 15:05:59.88
いくら何でもそれくらいは楽勝だろ
636 ：デフォルトの名無しさん：2011/11/05(土) 15:07:34.25
糞コードはいくら経験しても読み書きに不自由します
637 ：デフォルトの名無しさん：2011/11/05(土) 15:10:23.16
638 ：デフォルトの名無しさん：2011/11/05(土) 15:11:48.69
>>617
そうでもないよ。マクロの使うセンスによるから。
そうでもないよ。マクロの使うセンスによるから。
639 ：デフォルトの名無しさん：2011/11/05(土) 15:16:52.08
読んでないけど、その3万行のschemeと20万行のC++で実行性能は同じなの？
640 ：デフォルトの名無しさん：2011/11/05(土) 15:20:43.96
なんだ、scheme ベースの GUI ライブラリを使ってレガシーな C++ を小さくできたってことか。
つまらん。
つまらん。
641 ：デフォルトの名無しさん：2011/11/05(土) 15:28:32.58
高階関数を使い出すと型推論のある静的型付け言語じゃないと悲惨なことになると思うんだけどそうでもないのかな
642 ：デフォルトの名無しさん：2011/11/05(土) 15:29:41.07
>>612
1000行ってのはたった 1Kstep なんだが....
せめて 10000行(10Kstep) と言って欲しかった
このくらいになるとモジュール化されたコード設計が必要になる
それ以下だとプログラム全体の構造を頭の中で把握できるから、
どんな言語でもコーディング技法(テクニック)で乗り切れてしまう
1000行ってのはたった 1Kstep なんだが....
せめて 10000行(10Kstep) と言って欲しかった
このくらいになるとモジュール化されたコード設計が必要になる
それ以下だとプログラム全体の構造を頭の中で把握できるから、
どんな言語でもコーディング技法(テクニック)で乗り切れてしまう
643 ：デフォルトの名無しさん：2011/11/05(土) 15:34:09.49
大規模ってどのくらいだろうね
もちろん言語によると思うけど、Cなら100万行超えたら大規模って言って大丈夫？
10万行オーダーは人によって意見がわかれそう。1万行は確実に小規模だよね？
もちろん言語によると思うけど、Cなら100万行超えたら大規模って言って大丈夫？
10万行オーダーは人によって意見がわかれそう。1万行は確実に小規模だよね？
644 ：デフォルトの名無しさん：2011/11/05(土) 15:37:49.69
645 ：デフォルトの名無しさん：2011/11/05(土) 15:39:36.03
>>614
なんとかなるものだよ
たとえばRubyでは
target = source_array.select {.....}.sort_by {.....}.map {.....}.inject(...) {.....}
みたいなコードを書く (実際にはコードを折り曲げるから、１文が数十行になる)
このコードの " {.....} " の部分がブロック(クロージャ)だから、
これは構文糖に包まれた高階関数であると言えるんじゃないかな？
もちろんブロック内で副作用のあるコードは書かない！という規律(モラル)が前提だけどね
なんとかなるものだよ
たとえばRubyでは
target = source_array.select {.....}.sort_by {.....}.map {.....}.inject(...) {.....}
みたいなコードを書く (実際にはコードを折り曲げるから、１文が数十行になる)
このコードの " {.....} " の部分がブロック(クロージャ)だから、
これは構文糖に包まれた高階関数であると言えるんじゃないかな？
もちろんブロック内で副作用のあるコードは書かない！という規律(モラル)が前提だけどね
646 ：デフォルトの名無しさん：2011/11/05(土) 15:42:12.38
読みやすいコードを書く人とそうでない人の差って、先のことを考えて
るかどうかだよ。
るかどうかだよ。
647 ：デフォルトの名無しさん：2011/11/05(土) 15:43:13.55
かいているときは気持ちいいだけど
かきおわったら萎える
かきおわったら萎える
648 ：デフォルトの名無しさん：2011/11/05(土) 15:46:42.81
dead endが見えると作業ディレクトリごと消す
649 ：デフォルトの名無しさん：2011/11/05(土) 15:47:13.64
認めたがらないときはくだらないとか難癖はつけるもの。
このスレならそれでいいのではないだろうか？所詮俺が正しいことを
押し付けるスレです。
このスレならそれでいいのではないだろうか？所詮俺が正しいことを
押し付けるスレです。
650 ：デフォルトの名無しさん：2011/11/05(土) 15:53:02.46
一万行超えたら全部把握するのは無理
大雑把にあの辺にあれがあるという程度になってるから
力押しでやるのは不可能だろ
だから可読性とテストを優先してる
このレベルからインターフェースやアブストラクトがものすごく便利になってくる
コードを短くするよりもわかりやすい名前の方が重要
大雑把にあの辺にあれがあるという程度になってるから
力押しでやるのは不可能だろ
だから可読性とテストを優先してる
このレベルからインターフェースやアブストラクトがものすごく便利になってくる
コードを短くするよりもわかりやすい名前の方が重要
652 ：デフォルトの名無しさん：2011/11/05(土) 15:56:59.79
653 ：デフォルトの名無しさん：2011/11/05(土) 16:49:48.92
654 ：デフォルトの名無しさん：2011/11/05(土) 17:31:23.73
こんなんおおいばりで書いてあるくらいだから
他も部分も大したことないのは
容易に想像がつくだろ
他も部分も大したことないのは
容易に想像がつくだろ
655 ：デフォルトの名無しさん：2011/11/05(土) 18:15:08.89
glue8万行って書いてあるけど
これは大部分じゃないのか？
これは大部分じゃないのか？
656 ：デフォルトの名無しさん：2011/11/05(土) 18:24:09.83
4割だな
657 ：デフォルトの名無しさん：2011/11/05(土) 18:26:13.39
でもこれって使用するGUIライブラリが変更されてるから
c++とschemeの公平な比較になってないわ
c++とschemeの公平な比較になってないわ
658 ：デフォルトの名無しさん：2011/11/05(土) 18:34:35.79
静的言語に寄生している分際で
行数が１／１０になるぞとかいばりちらして
頭おかしいのな
行数が１／１０になるぞとかいばりちらして
頭おかしいのな
659 ：デフォルトの名無しさん：2011/11/05(土) 18:42:35.21
なんか どうしても認められない人がいるのね。たしかに頭がおかしい。
おかしい人から正常な人を見たら頭がおかしく見えるというのもあなが
ち嘘ではないというのは658が示してる悲しい現実がある。
おかしい人から正常な人を見たら頭がおかしく見えるというのもあなが
ち嘘ではないというのは658が示してる悲しい現実がある。
660 ：デフォルトの名無しさん：2011/11/05(土) 18:45:05.86
637はいい加減自分の馬鹿さ加減を自覚しろよ
661 ：デフォルトの名無しさん：2011/11/05(土) 18:47:56.13
662 ：デフォルトの名無しさん：2011/11/05(土) 18:48:34.45
そもそも、思うんだけど、毛嫌いしてるだけじゃなくて、実際に
書いてみればいいのに。皮肉なことに関数型やってる人の多くは
CやC++の経験もある（というよりそちらが主流だから。）から
感じやすいんだろうな。そこからの反論だったら面白いことが
あるけどな。
この手のことって、左利き右利きのアナロジーと同じかな。
左利きは右利きのことはこなせるように強制されて、両利きや右になって
しまうけど、右利きには難しい。ここで右利きを主流、左を関数型と
捉えたらいいかもしれない。
ちょっとしたスタイルの違いで行数はずいぶん変わるけど、Lispは
カッコを閉じるとき)))改行だけど、主流は｝改行}改行}だからな。この
どうでもいいところでもどうしても行数は減る。
書いてみればいいのに。皮肉なことに関数型やってる人の多くは
CやC++の経験もある（というよりそちらが主流だから。）から
感じやすいんだろうな。そこからの反論だったら面白いことが
あるけどな。
この手のことって、左利き右利きのアナロジーと同じかな。
左利きは右利きのことはこなせるように強制されて、両利きや右になって
しまうけど、右利きには難しい。ここで右利きを主流、左を関数型と
捉えたらいいかもしれない。
ちょっとしたスタイルの違いで行数はずいぶん変わるけど、Lispは
カッコを閉じるとき)))改行だけど、主流は｝改行}改行}だからな。この
どうでもいいところでもどうしても行数は減る。
663 ：デフォルトの名無しさん：2011/11/05(土) 18:51:49.11
別にC/C++に寄生しなくても
Javaチップで動かせばおけ
Javaチップで動かせばおけ
664 ：デフォルトの名無しさん：2011/11/05(土) 18:53:09.05
減りやすいのは、map,reduce(fold),filterなどを
多用しだすと、それだけでも全然違うよね。
考えなくてもC++より関数型のほうが行数が減るというのは必然的
だと思うんだがな。
コンパクトになることを認めたがらないってやっぱりオツムの問題だと思うよ。
多用しだすと、それだけでも全然違うよね。
考えなくてもC++より関数型のほうが行数が減るというのは必然的
だと思うんだがな。
コンパクトになることを認めたがらないってやっぱりオツムの問題だと思うよ。
665 ：デフォルトの名無しさん：2011/11/05(土) 18:56:53.21
>>663
そしたらGroovyやClojureも動いちゃうだろ
そしたらGroovyやClojureも動いちゃうだろ
666 ：デフォルトの名無しさん：2011/11/05(土) 19:00:50.25
>>660
馬鹿だな。一人で戦ってシャドウボクシングをやってるように見てるのか。
馬鹿だな。一人で戦ってシャドウボクシングをやってるように見てるのか。
667 ：デフォルトの名無しさん：2011/11/05(土) 19:03:07.40
>>665
その２つはJavaに寄生してるだろ
その２つはJavaに寄生してるだろ
668 ：デフォルトの名無しさん：2011/11/05(土) 19:10:02.34
Javaチップとかバカ過ぎ
つーかネイティブコンパイルできるか否かと
型付けは関係ねーだろアホか
つーかネイティブコンパイルできるか否かと
型付けは関係ねーだろアホか
669 ：デフォルトの名無しさん：2011/11/05(土) 19:11:49.60
だれも関係あるなんて言ってないだろ馬鹿
670 ：デフォルトの名無しさん：2011/11/05(土) 19:13:08.23
じゃあ>>658は何のつもりで書いたんだよバカが
本当に低能だな
本当に低能だな
671 ：デフォルトの名無しさん：2011/11/05(土) 19:18:07.64
658のどこに
ネイティブコンパイルと型付けの関係が書いてあるんだよw
脳内で誰かと会話でもしてるん？www
ネイティブコンパイルと型付けの関係が書いてあるんだよw
脳内で誰かと会話でもしてるん？www
672 ：デフォルトの名無しさん：2011/11/05(土) 19:18:46.45
結局、動的型付け言語で大規模開発やった方が効率が良いみたいだな
そもそもコード量が断然少なくなるからな
そもそもコード量が断然少なくなるからな
673 ：デフォルトの名無しさん：2011/11/05(土) 19:20:10.30
大規模の時点で、コード量多いだろｗ
頭悪いのか？
頭悪いのか？
674 ：デフォルトの名無しさん：2011/11/05(土) 19:21:24.55
空想じゃなくて、やってみてから言いなよ
675 ：デフォルトの名無しさん：2011/11/05(土) 19:22:45.64
静的型言語と比較して少ないって意味だろ
頭おかしいレベルで馬鹿だな
頭おかしいレベルで馬鹿だな
676 ：デフォルトの名無しさん：2011/11/05(土) 19:23:43.83
677 ：デフォルトの名無しさん：2011/11/05(土) 19:24:50.48
コード量減ってもせいぜい２割くらいで
大規模に到達する前にメンテナンス不能のゴミになるのが関の山
大規模に到達する前にメンテナンス不能のゴミになるのが関の山
678 ：デフォルトの名無しさん：2011/11/05(土) 19:26:56.67
き‐せい【寄生】
２ 他の働きなどに頼り、生きていくこと。「芸能界に―する」
馬鹿のために辞書引いてやったぞ
２ 他の働きなどに頼り、生きていくこと。「芸能界に―する」
馬鹿のために辞書引いてやったぞ
679 ：デフォルトの名無しさん：2011/11/05(土) 19:28:54.86
ブートストラップできるネイティブコンパイラをもつLispは
一体何に寄生してるの？
一体何に寄生してるの？
680 ：デフォルトの名無しさん：2011/11/05(土) 19:31:43.15
JavaドカタはJavaに寄生してる
これが"寄生"の正しい使い方だな
これが"寄生"の正しい使い方だな
681 ：デフォルトの名無しさん：2011/11/05(土) 19:37:03.63
ブートストラップできるネイティブコンパイラをもつってだけでは
寄生しているかどうかわからんだろ
寄生しているかどうかわからんだろ
682 ：デフォルトの名無しさん：2011/11/05(土) 19:41:33.03
静的言語は確かに動的言語よりコードが多くなる。
だがそれは×αとかではなく＋α
コード量が少なければ＋αの影響は大きくなるが
コード量が多くなるに連れて＋αは誤差レベルにまで下がってしまう。
それが大規模と小規模でのコード量の違い。
そして大規模開発になると、コード量が大幅に増え、
時間的に考えて一人で作ることは不可能になる。
つまり、自分がコーディングをした知っている部分よりも、
知らない部分のほうが圧倒的に多くなる。
そうなると、書く量よりも、素早く他人が書いたコードの全体像を
把握する時間のほうが重要になる。
だがそれは×αとかではなく＋α
コード量が少なければ＋αの影響は大きくなるが
コード量が多くなるに連れて＋αは誤差レベルにまで下がってしまう。
それが大規模と小規模でのコード量の違い。
そして大規模開発になると、コード量が大幅に増え、
時間的に考えて一人で作ることは不可能になる。
つまり、自分がコーディングをした知っている部分よりも、
知らない部分のほうが圧倒的に多くなる。
そうなると、書く量よりも、素早く他人が書いたコードの全体像を
把握する時間のほうが重要になる。
683 ：デフォルトの名無しさん：2011/11/05(土) 19:41:41.12
1/10のコードで済むんだったら
8万行もglueコード書くのは変な話だろ
静的言語換算で80万行なら
フルスクラッチで立派なGUIライブラリが書けるじゃん
8万行もglueコード書くのは変な話だろ
静的言語換算で80万行なら
フルスクラッチで立派なGUIライブラリが書けるじゃん
684 ：デフォルトの名無しさん：2011/11/05(土) 20:09:21.84
> we were able to trade in 80,000 lines of C++ glue for about 8,000 lines of Racket glue.
素直に読めば8万行のglueコードはC++で書かれてたんじゃないか？
素直に読めば8万行のglueコードはC++で書かれてたんじゃないか？
685 ：デフォルトの名無しさん：2011/11/05(土) 20:14:57.49
8万行のC++のglueコードを書かないで
racketで8万行、静的言語で80万行相当の
GUIライブラリを書いた方がいいだろってこと
racketで8万行、静的言語で80万行相当の
GUIライブラリを書いた方がいいだろってこと
686 ：デフォルトの名無しさん：2011/11/05(土) 20:20:17.24
だんだん 悪あがきみたいなコメントになってるな。685 みてるほうとしては
つまらないバラエティ番組を見てる気分。
つまらないバラエティ番組を見てる気分。
687 ：デフォルトの名無しさん：2011/11/05(土) 20:24:52.76
移植性のあるGUIライブラリと
ただのglueコードでは同じ行数でも難易度が違うよ
ただのglueコードでは同じ行数でも難易度が違うよ
688 ：デフォルトの名無しさん：2011/11/05(土) 20:26:23.99
見なきゃいいだろ
684はどうしてglueコードがC++で書かれてないと思っていると
勝手に勘違いしたんだ？
684はどうしてglueコードがC++で書かれてないと思っていると
勝手に勘違いしたんだ？
689 ：デフォルトの名無しさん：2011/11/05(土) 20:28:45.65
静的言語換算で80万行と書いてたからだね
690 ：デフォルトの名無しさん：2011/11/05(土) 20:30:02.44
このracketの話って、スレのタイトルの反証だお。
691 ：デフォルトの名無しさん：2011/11/05(土) 20:30:31.76
静的言語換算で80万行・・・実際に静的言語で書いてみたら10万行でした。とかなｗ
692 ：デフォルトの名無しさん：2011/11/05(土) 20:30:38.96
693 ：デフォルトの名無しさん：2011/11/05(土) 20:31:22.77
静的言語換算だろ？
静的型付け言語換算じゃなくて
静的型付け言語換算じゃなくて
694 ：デフォルトの名無しさん：2011/11/05(土) 20:32:12.07
いや、C++で8万行のコードが静的言語換算で80万行って意味分からんでしょう
Racketで8万行ならともかく
Racketで8万行ならともかく
695 ：デフォルトの名無しさん：2011/11/05(土) 20:33:49.48
静的言語と動的言語なら10倍ぐらい差が出てもおかしくはないが、
静的型付けと動的型付け言語じゃ、そうとう動的型付け言語に
有利な例題じゃない限り、そんなに差はでないだろう。
静的型付けと動的型付け言語じゃ、そうとう動的型付け言語に
有利な例題じゃない限り、そんなに差はでないだろう。
696 ：デフォルトの名無しさん：2011/11/05(土) 20:35:39.46
>>694
いやC++は動的言語だよ。動的言語で静的型付け言語。
動的言語ってのは分かるよね？
インターフェースとか継承があって、実行時に呼び出すメソッドが決まる方式。
ちなみに型が静的に決まるのが静的型付け。
いやC++は動的言語だよ。動的言語で静的型付け言語。
動的言語ってのは分かるよね？
インターフェースとか継承があって、実行時に呼び出すメソッドが決まる方式。
ちなみに型が静的に決まるのが静的型付け。
697 ：デフォルトの名無しさん：2011/11/05(土) 20:37:55.89
静的言語ってのはCOBOLやFortlanや古いBASICみたいなもの。
関数があって、それを呼び出すコードがあって、
この結合が実行前に全部決まってしまうもの。
関数があって、それを呼び出すコードがあって、
この結合が実行前に全部決まってしまうもの。
698 ：デフォルトの名無しさん：2011/11/05(土) 20:45:41.33
もし>>683が静的言語を静的型付け言語と区別して使ってたんなら、
コードが1/10に減るって話はどこから来たんだろうね？
C++とRacketの比較なら、ちょうど8万行が8千行に減ったという例があるわけだけど
コードが1/10に減るって話はどこから来たんだろうね？
C++とRacketの比較なら、ちょうど8万行が8千行に減ったという例があるわけだけど
699 ：デフォルトの名無しさん：2011/11/05(土) 20:48:56.36
このスレで動的言語と言ったら動的型付け言語のこと
動的バインディングとは関係ない
動的バインディングとは関係ない
700 ：デフォルトの名無しさん：2011/11/05(土) 21:02:06.89
701 ：デフォルトの名無しさん：2011/11/05(土) 21:07:33.09
mapやreduceといった関数を使うことをもって関数型の考え方とか言ってる？
だとしたら低レベルの話でそんなドヤ顔しないでください。
その程度の話ならコールバック関数と何も変わらんじゃないか。
CでもJavaでも関数ポインタや関数オブジェクトで昔から誰でもやってます。
そうじゃないとGUIアプリなんか一つも書けないでしょ。
関数型の考え方っていうのは、mapやreduceのような関数を「臨機応変に自分で作る」ことを指すんだと思うよ
手続き型言語ならC++のTMPに近いんじゃないかなあ。
だとしたら低レベルの話でそんなドヤ顔しないでください。
その程度の話ならコールバック関数と何も変わらんじゃないか。
CでもJavaでも関数ポインタや関数オブジェクトで昔から誰でもやってます。
そうじゃないとGUIアプリなんか一つも書けないでしょ。
関数型の考え方っていうのは、mapやreduceのような関数を「臨機応変に自分で作る」ことを指すんだと思うよ
手続き型言語ならC++のTMPに近いんじゃないかなあ。
702 ：デフォルトの名無しさん：2011/11/05(土) 21:11:05.24
703 ：デフォルトの名無しさん：2011/11/05(土) 21:11:56.57
あら、ループして延々やってたんだこんな話ｗ
704 ：デフォルトの名無しさん：2011/11/05(土) 21:17:28.79
で、ここで結論が出たな。性的な手続き言語は終ってると。
705 ：デフォルトの名無しさん：2011/11/05(土) 21:18:25.46
結論出たなら帰れよ
706 ：デフォルトの名無しさん：2011/11/05(土) 21:19:41.40
性的w
707 ：デフォルトの名無しさん：2011/11/05(土) 21:23:22.67
一番スケールしないのは動的な関数型言語だよ
708 ：デフォルトの名無しさん：2011/11/05(土) 21:24:48.20
静的型付けのない関数型言語なんてeval以外に何のメリットもないから
709 ：デフォルトの名無しさん：2011/11/05(土) 21:33:13.91
邪悪なことをすればevalすら可能
710 ：デフォルトの名無しさん：2011/11/05(土) 21:56:47.03
>>708
知らないって幸せなことだねw
知らないって幸せなことだねw
711 ：デフォルトの名無しさん：2011/11/05(土) 21:58:11.51
静的型付けのない副作用のある関数型言語なんてゴミだろ
712 ：デフォルトの名無しさん：2011/11/05(土) 21:58:31.20
>>710
その内をヲチしてプッと笑うスレですから。
その内をヲチしてプッと笑うスレですから。
713 ：デフォルトの名無しさん：2011/11/06(日) 00:12:46.92
性的言語と童貞言語でしょ :-)
714 ：デフォルトの名無しさん：2011/11/06(日) 01:45:18.46
どどど童貞ちゃうわ！
715 ：デフォルトの名無しさん：2011/11/06(日) 02:16:48.02
しかしここのスレタイは秀逸だなw
お互いに好き勝手な事書いても、誰も客観的な検証も反論もできないから
延々とスレが伸びる
お互いに好き勝手な事書いても、誰も客観的な検証も反論もできないから
延々とスレが伸びる
716 ：デフォルトの名無しさん：2011/11/06(日) 02:33:26.33
というか、反論したい層＝大規模開発どころか仕事やってるかも怪しい層だから
どうしても説得力があることを言えないんだよ。
どうしても説得力があることを言えないんだよ。
717 ：デフォルトの名無しさん：2011/11/06(日) 02:43:49.08
すすすすいません。童貞ってマズいコトなんですか？
718 ：デフォルトの名無しさん：2011/11/06(日) 04:01:39.52
719 ：デフォルトの名無しさん：2011/11/06(日) 08:06:22.13
ここはいろんな人種が入り乱れているからな。まさにバトルロワイアルだよ！
720 ：デフォルトの名無しさん：2011/11/06(日) 08:07:39.21
スレタイで結論が出てる
キチガイLisperが荒らしているだけ
キチガイLisperが荒らしているだけ
721 ：デフォルトの名無しさん：2011/11/06(日) 08:15:45.66
722 ：デフォルトの名無しさん：2011/11/06(日) 08:36:59.03
723 ：デフォルトの名無しさん：2011/11/06(日) 09:06:48.02
724 ：デフォルトの名無しさん：2011/11/06(日) 09:28:37.91
具体的には、大規模な遺産を無かったことにして一からやり直す行為。
無かったことにしたい層は学習意欲が高い。
無かったことにしたい層は学習意欲が高い。
725 ：デフォルトの名無しさん：2011/11/06(日) 09:31:48.34
言語が考えることの制限になってることに気がついてないのだろうか？
726 ：デフォルトの名無しさん：2011/11/06(日) 09:32:32.43
727 ：デフォルトの名無しさん：2011/11/06(日) 09:34:02.36
>>724
具体的にはと言いながら激しく抽象的に思える
具体的にはと言いながら激しく抽象的に思える
728 ：デフォルトの名無しさん：2011/11/06(日) 09:34:04.87
729 ：デフォルトの名無しさん：2011/11/06(日) 10:09:41.22
>>728
と思ってるだけで実際は制限を受けているよ。
と思ってるだけで実際は制限を受けているよ。
730 ：デフォルトの名無しさん：2011/11/06(日) 10:10:21.41
思考に与える言語の制限というのは計算機言語の話だけではないよ。自然言語でも同じなんだが。
731 ：デフォルトの名無しさん：2011/11/06(日) 10:15:23.38
具体的なものは言語に制限されない。現実世界に制限される。
抽象的概念は言語によるブレが大きいが、
もともと曖昧なものだから当てにしないのが普通。
抽象的概念は言語によるブレが大きいが、
もともと曖昧なものだから当てにしないのが普通。
732 ：デフォルトの名無しさん：2011/11/06(日) 11:02:19.09
学び続ける事を拒否してるのか
言語を学ぶことなんて大した事無いと言ってるのか分からん
前者ならマジで終わってる
言語を学ぶことなんて大した事無いと言ってるのか分からん
前者ならマジで終わってる
733 ：デフォルトの名無しさん：2011/11/06(日) 11:10:55.08
学び続けることは重要だが、その対象が言語かどうかは別の話。
734 ：デフォルトの名無しさん：2011/11/06(日) 11:20:47.24
重要なのは作り続けることだ
学んだ言語で社会に何を還元したかが問題
学んだ言語で社会に何を還元したかが問題
735 ：デフォルトの名無しさん：2011/11/06(日) 11:46:22.27
当たり前だが実際に何か作ってみる事でしか
言語はマスターできん
ま、COBOLerみたいにはならんようにな
自分から動かないと、ずっと同じ言語使わされて取り残されるかもしれんぞ
言語はマスターできん
ま、COBOLerみたいにはならんようにな
自分から動かないと、ずっと同じ言語使わされて取り残されるかもしれんぞ
736 ：デフォルトの名無しさん：2011/11/06(日) 12:13:55.59
737 ：デフォルトの名無しさん：2011/11/06(日) 12:28:29.30
COBOLは書くだけなら誰でも一日で書けるようになるが、
COBOLで仕事ができるってのは言語知識とは別のところにある
COBOLで仕事ができるってのは言語知識とは別のところにある
738 ：デフォルトの名無しさん：2011/11/06(日) 12:38:23.26
仕事ができないならプログラミングなんかいくら書けたって意味がない
739 ：デフォルトの名無しさん：2011/11/06(日) 12:41:02.24
いやCOBOL以外で仕事するから
740 ：デフォルトの名無しさん：2011/11/06(日) 12:41:56.16
ほんとそうだよなw
741 ：デフォルトの名無しさん：2011/11/06(日) 12:43:42.80
その言語で仕事をしたこともない奴が批判してるのか。狭いな
742 ：デフォルトの名無しさん：2011/11/06(日) 12:46:48.30
ポインタを学ばない若者が「いやC以外で仕事するから」「ほんとそうだよなｗ」と馬鹿にするのと何が違うのだろうか
743 ：デフォルトの名無しさん：2011/11/06(日) 12:54:17.34
ポインタが理解できないのは知能的に問題あるけど
仕事に使うかは別だろ
仕事に使うかは別だろ
744 ：デフォルトの名無しさん：2011/11/06(日) 13:00:23.15
COBOLの仕事が少なくなってるのは事実で、
それはCOBOLで仕事してなくても分かることだからな。
少ない仕事にしがみついて働くのもいいんじゃね？
職が見つけ難かったり安く買い叩かれたりするけど。
それはCOBOLで仕事してなくても分かることだからな。
少ない仕事にしがみついて働くのもいいんじゃね？
職が見つけ難かったり安く買い叩かれたりするけど。
745 ：デフォルトの名無しさん：2011/11/06(日) 13:17:49.88
安い高いの問題ではなく、人って買われるものじゃないよね。
可哀想に。
可哀想に。
746 ：デフォルトの名無しさん：2011/11/06(日) 13:24:36.73
747 ：デフォルトの名無しさん：2011/11/06(日) 13:34:38.25
>>746
同意。Web界隈は人が余ってるから本当に安売りが酷い。
つーかこの業界、メインストリームを行くなら人より早く深く、常に勉強し続けないと話にならん。
それができない奴はニッチなところで何か一つ売れる技術を身につける方がマシ。
人と同じことを人と同じ速さでやってる奴ってのが一番骨折り損。
同意。Web界隈は人が余ってるから本当に安売りが酷い。
つーかこの業界、メインストリームを行くなら人より早く深く、常に勉強し続けないと話にならん。
それができない奴はニッチなところで何か一つ売れる技術を身につける方がマシ。
人と同じことを人と同じ速さでやってる奴ってのが一番骨折り損。
748 ：デフォルトの名無しさん：2011/11/06(日) 13:37:54.37
技術を作り出すのが一流
技術が広まる前に学ぶのが二流
広まってから技術を学ぶのが三流
廃れる技術に留まるのが無能
廃れきった技術を継承するのが伝統職人
技術が広まる前に学ぶのが二流
広まってから技術を学ぶのが三流
廃れる技術に留まるのが無能
廃れきった技術を継承するのが伝統職人
749 ：デフォルトの名無しさん：2011/11/06(日) 13:39:28.56
自分が今まで勉強した言語の中で、一番面白かったと思えるものって知りたい。
俺はFORTRAN。いろんな意味でｗ
俺はFORTRAN。いろんな意味でｗ
750 ：デフォルトの名無しさん：2011/11/06(日) 14:04:46.66
自分はHaskellが一番好き。惚れたと言って良い。
けど、スレチだからこっちへおいで
やってて楽しいプログラミング言語は？ 3言語
http://hibari.2ch.net/test/read.cgi/tech/1305383738/
けど、スレチだからこっちへおいで
やってて楽しいプログラミング言語は？ 3言語
http://hibari.2ch.net/test/read.cgi/tech/1305383738/
751 ：デフォルトの名無しさん：2011/11/06(日) 15:07:41.98
ドカタでもなければ静的型と動的型の両方をつかう
静的型に固執するのはドカタのしるし
静的型に固執するのはドカタのしるし
752 ：デフォルトの名無しさん：2011/11/06(日) 15:13:45.60
>>748
伝統職人以外は、マルチ商法に似てる
伝統職人以外は、マルチ商法に似てる
753 ：デフォルトの名無しさん：2011/11/06(日) 15:18:13.89
754 ：デフォルトの名無しさん：2011/11/06(日) 15:18:38.26
あ、知ってて＝使えて。な
755 ：デフォルトの名無しさん：2011/11/06(日) 15:19:23.42
>>753
だから君は成長しないんだよ
だから君は成長しないんだよ
756 ：デフォルトの名無しさん：2011/11/06(日) 15:35:14.81
今のweb系のプログラマってコボラーより未来がないと予想してるんだけど
競争相手が世界中に発生する上にやってること自体はそんなに難しくないからな
コボラーはまだ業務の知識が必要だったりセキュリティ面でもある程度は保護される
web系は何もかもが表に出すぎてるから
数倍の効率で開発できるプログラマ程度じゃあ
十人のプログラマには勝てないだろ、賃金が安い連中が生き残る
今の時点でも英語で交渉できる奴の方が日本人プログラマよりも開発効率は上だろ
アプリもhtml5に食われて同じような現象になる
日本語の壁が守ってくれたところで円高のままだったらいつか食われるときがくる
その辺りまで考えてるよね、みんな頭がいいんだから
競争相手が世界中に発生する上にやってること自体はそんなに難しくないからな
コボラーはまだ業務の知識が必要だったりセキュリティ面でもある程度は保護される
web系は何もかもが表に出すぎてるから
数倍の効率で開発できるプログラマ程度じゃあ
十人のプログラマには勝てないだろ、賃金が安い連中が生き残る
今の時点でも英語で交渉できる奴の方が日本人プログラマよりも開発効率は上だろ
アプリもhtml5に食われて同じような現象になる
日本語の壁が守ってくれたところで円高のままだったらいつか食われるときがくる
その辺りまで考えてるよね、みんな頭がいいんだから
757 ：デフォルトの名無しさん：2011/11/06(日) 15:41:03.65
プロジェクト選ぶときは、自分が使える言語よりも使えるようになりたい言語を選ぶよな
758 ：デフォルトの名無しさん：2011/11/06(日) 15:44:51.75
仕事じゃないときはな。
759 ：デフォルトの名無しさん：2011/11/06(日) 15:50:42.30
常識的には、仕事じゃないところで一通り使って感触を得てから仕事に適用するよな。
仕事で火吹いたら「使えるようになりたい言語を趣味で使ってみる」余裕がなくなるので悪循環に陥る。
仕事で火吹いたら「使えるようになりたい言語を趣味で使ってみる」余裕がなくなるので悪循環に陥る。
760 ：デフォルトの名無しさん：2011/11/06(日) 16:06:53.41
技術を仕事で身につけるのがプロだろ
761 ：デフォルトの名無しさん：2011/11/06(日) 16:12:23.97
吹いた
762 ：デフォルトの名無しさん：2011/11/06(日) 16:13:43.93
違います
技術を仕事で発揮するのがプロです
身に付けるのは仕事でもプライベートでもどこでも構いません
技術を仕事で発揮するのがプロです
身に付けるのは仕事でもプライベートでもどこでも構いません
763 ：デフォルトの名無しさん：2011/11/06(日) 16:14:26.54
「仕事で使うのは、十分に勉強してから」という言い訳をする奴が
人より先に技術を身につけたところなど見たこともないw
人より先に技術を身につけたところなど見たこともないw
764 ：デフォルトの名無しさん：2011/11/06(日) 16:15:27.00
たかがプライベートで使っただけの付け焼刃で専門家気取りか
そういう奴がプロジェクト燃やすんだよなー
そういう奴がプロジェクト燃やすんだよなー
765 ：デフォルトの名無しさん：2011/11/06(日) 16:19:52.51
766 ：デフォルトの名無しさん：2011/11/06(日) 16:25:23.37
TPPの影響考えておけ、食費が安くなったらその分だけwebに流れる金が増えるかもしれない
でも失業者増大するかもしれない、人余りで流れ込む
円安に流れる可能性がある、そうなると大きな資本が投資に回る可能性が高まる
外資食いから国外の下請けになって失業という流れはありえる
仕事という役割には消滅するリスクがあるが知識は消滅しない
手に入れやすくなるほど知識には価値がなくなる
人の価値は知能の高さにある、今ある情報でどれだけ先を読めるかが
人の価値の本質となるだろう
頭の悪い奴は余計な事を含めて溜め込むのが好きらしいけど
おまえは頭がいいから必要な部分だけを溜め込んでるんだよな
読んだ後にこれは必要なものだと自覚するよりも
読む前からこういうのが必要なものだろうと予測できてるよね
一を聞いて十を知るというのはそういうことだ
でも失業者増大するかもしれない、人余りで流れ込む
円安に流れる可能性がある、そうなると大きな資本が投資に回る可能性が高まる
外資食いから国外の下請けになって失業という流れはありえる
仕事という役割には消滅するリスクがあるが知識は消滅しない
手に入れやすくなるほど知識には価値がなくなる
人の価値は知能の高さにある、今ある情報でどれだけ先を読めるかが
人の価値の本質となるだろう
頭の悪い奴は余計な事を含めて溜め込むのが好きらしいけど
おまえは頭がいいから必要な部分だけを溜め込んでるんだよな
読んだ後にこれは必要なものだと自覚するよりも
読む前からこういうのが必要なものだろうと予測できてるよね
一を聞いて十を知るというのはそういうことだ
767 ：デフォルトの名無しさん：2011/11/06(日) 16:35:45.56
TPPの影響考えておけ、食費が安くなったらその分だけ牛丼に流れる金が増えるかもしれない
でも失業者増大するかもしれない、人余りで流れ込む
円安に流れる可能性がある、そうなると大きな資本が投資に回る可能性が高まる
外資食いから国外の下請けになって失業という流れはありえる
仕事という役割には消滅するリスクがあるが知識は消滅しない
手に入れやすくなるほど知識には価値がなくなる
人の価値は知能の高さにある、今ある情報でどれだけ先を読めるかが
人の価値の本質となるだろう
頭の悪い奴は余計な事を含めて溜め込むのが好きらしいけど
おまえは頭がいいから必要な部分だけを溜め込んでるんだよな
読んだ後にこれは必要なものだと自覚するよりも
読む前からこういうのが必要なものだろうと予測できてるよね
一を聞いて十を知るというのはそういうことだ
でも失業者増大するかもしれない、人余りで流れ込む
円安に流れる可能性がある、そうなると大きな資本が投資に回る可能性が高まる
外資食いから国外の下請けになって失業という流れはありえる
仕事という役割には消滅するリスクがあるが知識は消滅しない
手に入れやすくなるほど知識には価値がなくなる
人の価値は知能の高さにある、今ある情報でどれだけ先を読めるかが
人の価値の本質となるだろう
頭の悪い奴は余計な事を含めて溜め込むのが好きらしいけど
おまえは頭がいいから必要な部分だけを溜め込んでるんだよな
読んだ後にこれは必要なものだと自覚するよりも
読む前からこういうのが必要なものだろうと予測できてるよね
一を聞いて十を知るというのはそういうことだ
768 ：デフォルトの名無しさん：2011/11/06(日) 16:50:57.85
>>765
お勉強はお勉強タイムでやる人？
つまり仕事中は何も学ばない人なんだね。
そういう人のことを ド カ タ って呼ぶんだよ。
仕事中に新しい技術を探求できない人に
新技術の開発なんて出来るわけないでしょww
逆に、新技術を仕事で通用するレベルで身につけようとするなら、
それに見合ったプロジェクトを自分で探したり選んだり、必要なら作ったりする。
それができない人は、やっぱり ド カ タ なんだと思うよ。
お勉強はお勉強タイムでやる人？
つまり仕事中は何も学ばない人なんだね。
そういう人のことを ド カ タ って呼ぶんだよ。
仕事中に新しい技術を探求できない人に
新技術の開発なんて出来るわけないでしょww
逆に、新技術を仕事で通用するレベルで身につけようとするなら、
それに見合ったプロジェクトを自分で探したり選んだり、必要なら作ったりする。
それができない人は、やっぱり ド カ タ なんだと思うよ。
769 ：デフォルトの名無しさん：2011/11/06(日) 17:00:13.50
770 ：デフォルトの名無しさん：2011/11/06(日) 17:01:43.28
771 ：デフォルトの名無しさん：2011/11/06(日) 17:01:46.14
プライベートなり責任の発生しない所である程度把握して扱えるようにして、それから少しずつ仕事に取り入れていくのが普通じゃないの？
いきなり右も左も分からないもの仕事で使うの？マジスゲー。
いきなり右も左も分からないもの仕事で使うの？マジスゲー。
772 ：デフォルトの名無しさん：2011/11/06(日) 17:03:55.90
>>768
他人を自分の思い通りにコントロールしたいんだろ
自分の考えが正しいから他人も自分と同じ考えを持つべきだ
そうでない奴は見下してもいい差別してもいい
それは宗教、政治結社
思想は自由であるべきだし
それは個人が自分で考えて選択するべきだろ
支配力を行使すればするほど、命令に従う奴は思考を停止せざるを得ない
他人の意見を尊重しない組織に所属している人は余計なことをしなくなる
つまりおまえのいうドカタを作り出してるのはおまえみたいな考えの人間だよ
支配強化の先には奴隷国家があって
奴隷国家には模索する自由がない
模索する自由がない国で新しい何かを身につけましょうと言う
それはギャグでしかない
保守思想が他人に努力を要求していること自体が矛盾しているのだよ
他人を自分の思い通りにコントロールしたいんだろ
自分の考えが正しいから他人も自分と同じ考えを持つべきだ
そうでない奴は見下してもいい差別してもいい
それは宗教、政治結社
思想は自由であるべきだし
それは個人が自分で考えて選択するべきだろ
支配力を行使すればするほど、命令に従う奴は思考を停止せざるを得ない
他人の意見を尊重しない組織に所属している人は余計なことをしなくなる
つまりおまえのいうドカタを作り出してるのはおまえみたいな考えの人間だよ
支配強化の先には奴隷国家があって
奴隷国家には模索する自由がない
模索する自由がない国で新しい何かを身につけましょうと言う
それはギャグでしかない
保守思想が他人に努力を要求していること自体が矛盾しているのだよ
773 ：デフォルトの名無しさん：2011/11/06(日) 17:04:59.20
「ドカタ」という言葉を使うドカ太郎が
仕事をしてないことがばれちゃいましたね。
勉強することが仕事の学生さんならではの
発想ですｗｗｗ
仕事をしてないことがばれちゃいましたね。
勉強することが仕事の学生さんならではの
発想ですｗｗｗ
774 ：デフォルトの名無しさん：2011/11/06(日) 17:06:26.31
実績の無い技術要素をチームに使わせるためには、
最低限として自分がチームメンバーに教えられるレベルになっていないと話にならないだろ。
そこから仕事だから金くれってのは技術者として性根腐ってないか？
自分が使いたい技術を使うなら、そのくらいはギブ＆テイクだと思ってタダでやれ。
なんて考える技術者が多いから技術者はいいように使われるんだろうなー
金儲けは下手だよね俺もお前らもｗ
最低限として自分がチームメンバーに教えられるレベルになっていないと話にならないだろ。
そこから仕事だから金くれってのは技術者として性根腐ってないか？
自分が使いたい技術を使うなら、そのくらいはギブ＆テイクだと思ってタダでやれ。
なんて考える技術者が多いから技術者はいいように使われるんだろうなー
金儲けは下手だよね俺もお前らもｗ
775 ：デフォルトの名無しさん：2011/11/06(日) 17:08:14.93
768の次のレスは「釣れた」
776 ：デフォルトの名無しさん：2011/11/06(日) 17:10:04.11
777 ：デフォルトの名無しさん：2011/11/06(日) 17:11:05.57
>>774 みたいなことをドヤ顔で言う奴にまともな技術者はいない
778 ：デフォルトの名無しさん：2011/11/06(日) 17:15:38.02
新しいものを身につける努力と
完成度の高いものの価値を維持する努力は
まったく方向が違うな
後者が努力していないというのはおかしい
金閣寺が金閣ビルに進化したら誰が得するんだよ
完成度の高いものの価値を維持する努力は
まったく方向が違うな
後者が努力していないというのはおかしい
金閣寺が金閣ビルに進化したら誰が得するんだよ
779 ：デフォルトの名無しさん：2011/11/06(日) 17:17:44.44
>>774
> 実績の無い技術要素をチームに使わせるためには、
> 最低限として自分がチームメンバーに教えられるレベルになっていないと話にならないだろ。
なってれば何の問題もないのに、
「全員使える言語」(>>753-754)とか言い出すからドカタ根性なんだよw
実務の中で教えたり学んだり調査したりするのは技術屋なら当然だろ。
「習ってないから使えませーん」とか笑わせんなw
> 実績の無い技術要素をチームに使わせるためには、
> 最低限として自分がチームメンバーに教えられるレベルになっていないと話にならないだろ。
なってれば何の問題もないのに、
「全員使える言語」(>>753-754)とか言い出すからドカタ根性なんだよw
実務の中で教えたり学んだり調査したりするのは技術屋なら当然だろ。
「習ってないから使えませーん」とか笑わせんなw
780 ：デフォルトの名無しさん：2011/11/06(日) 17:30:49.08
強引に自分の思い通りに進めようとする奴が偉くなったら
部下はイエスマンばかりになる
余計なことを言って怒らせて立場を悪くしたくないから
知ってることがあっても何も言わずにただ従うだけ
ルールを厳守して余計なことは一切しない
つまりドカタになる
そして強引に物事を推し進める奴はドカタジェネレータだ
結論として
ドカタジェネレータをドカタに降格して
ドカタを再教育しなおせば変われるだろう
部下はイエスマンばかりになる
余計なことを言って怒らせて立場を悪くしたくないから
知ってることがあっても何も言わずにただ従うだけ
ルールを厳守して余計なことは一切しない
つまりドカタになる
そして強引に物事を推し進める奴はドカタジェネレータだ
結論として
ドカタジェネレータをドカタに降格して
ドカタを再教育しなおせば変われるだろう
781 ：デフォルトの名無しさん：2011/11/06(日) 17:34:49.62
>>780
仕事の中で新しい技術に挑戦しない組織ってのは、そういう傾向があるね。
「その方法論はオレは知らないからダメだ」
「その言語はオレが知らないからダメだ」
「そのフレームワークはオレが知らないからダメだ」
こうしてドカタ言語が固定化され、化石化していく
仕事の中で新しい技術に挑戦しない組織ってのは、そういう傾向があるね。
「その方法論はオレは知らないからダメだ」
「その言語はオレが知らないからダメだ」
「そのフレームワークはオレが知らないからダメだ」
こうしてドカタ言語が固定化され、化石化していく
782 ：デフォルトの名無しさん：2011/11/06(日) 17:36:03.67
783 ：デフォルトの名無しさん：2011/11/06(日) 17:43:45.42
王が天才なら国は栄えるけど、王がバカなら国は滅ぶ
民主主義は権力を分散することで
天才君主の可能性を潰す代わりに、滅ぶリスクも潰した
民主主義的にはチームの思想はばらばらなのが好ましいが
時間がかかる、スピーディーな解決が必要な場合では決断はトップが行う
これでバランスを取るんだよ
同じような奴を集めるのは保守的にしたい場合、金閣ビルを作らないように
コボラーには協調性が必要だけど
それ以外の変化が激しい部署では協調は不要、一つにまとめなくてよい
民主主義は権力を分散することで
天才君主の可能性を潰す代わりに、滅ぶリスクも潰した
民主主義的にはチームの思想はばらばらなのが好ましいが
時間がかかる、スピーディーな解決が必要な場合では決断はトップが行う
これでバランスを取るんだよ
同じような奴を集めるのは保守的にしたい場合、金閣ビルを作らないように
コボラーには協調性が必要だけど
それ以外の変化が激しい部署では協調は不要、一つにまとめなくてよい
784 ：デフォルトの名無しさん：2011/11/06(日) 17:44:25.33
785 ：デフォルトの名無しさん：2011/11/06(日) 17:57:52.83
>>784
いや、習ってないから使えません。で良いんだよ
出来ないのに出来るって言うのは、上司にも客にも無責任だろ
その上で、仕事に必要ならプライベートでも仕事の合間でも覚えれば良い
得意な言語でも、すべて知ってるわけじゃないだろ？
仕事中に教えてもらったり、調べながらで進めて行くのは得意な言語でも変わらない
いや、習ってないから使えません。で良いんだよ
出来ないのに出来るって言うのは、上司にも客にも無責任だろ
その上で、仕事に必要ならプライベートでも仕事の合間でも覚えれば良い
得意な言語でも、すべて知ってるわけじゃないだろ？
仕事中に教えてもらったり、調べながらで進めて行くのは得意な言語でも変わらない
786 ：デフォルトの名無しさん：2011/11/06(日) 18:14:59.42
>>785
> その上で、仕事に必要ならプライベートでも仕事の合間でも覚えれば良い
典型的なドカタだねえ
ソフトウェア開発ってのは、企画者も開発者もいっしょに新しいものを開拓するんだよ。
今まで使ったことない言語ぐらい開拓していけないチキンが
新しい技術を開拓なんてできるわけがない。
既に使ったことがある技術だけ使う奴ってのは、結局は上から降りてくる仕様書通りに
誰でも書けるコードをそのまんま書くことしかできない。
今までにない技術を切り拓くことなんてできないのさ。
つまり、ドカタってことさ。
> その上で、仕事に必要ならプライベートでも仕事の合間でも覚えれば良い
典型的なドカタだねえ
ソフトウェア開発ってのは、企画者も開発者もいっしょに新しいものを開拓するんだよ。
今まで使ったことない言語ぐらい開拓していけないチキンが
新しい技術を開拓なんてできるわけがない。
既に使ったことがある技術だけ使う奴ってのは、結局は上から降りてくる仕様書通りに
誰でも書けるコードをそのまんま書くことしかできない。
今までにない技術を切り拓くことなんてできないのさ。
つまり、ドカタってことさ。
787 ：デフォルトの名無しさん：2011/11/06(日) 18:18:10.58
788 ：デフォルトの名無しさん：2011/11/06(日) 18:23:17.05
ま、調査チームを立ち上げて検証しないと新言語なんて実戦投入できんわな
チーム立ち上げもチーム人員も自分独りってケースはあるがw
ま、そういう調査チームを作らせてくれない会社はヘボだし、
自分で調査チームを立ち上げられない奴はヘタレ
チーム立ち上げもチーム人員も自分独りってケースはあるがw
ま、そういう調査チームを作らせてくれない会社はヘボだし、
自分で調査チームを立ち上げられない奴はヘタレ
789 ：デフォルトの名無しさん：2011/11/06(日) 18:25:17.33
>>787
へ？
googleが一日何個も新しいアルゴリズムを一般ユーザ相手に試していることも知らないのか？
簡単にデプロイするための独自のビルド管理環境を独立の専門チームが維持管理して、
それを使って本番システムに突っ込んで、実際のユーザからのリクエストの一部を
実験的アルゴリズムに回して、その結果を全部ロギングして分析評価してるんだよ。
アイツらが扱っているアルゴリズムはそこまでして実際の規模で動かさないと評価できねえんだよ。
へ？
googleが一日何個も新しいアルゴリズムを一般ユーザ相手に試していることも知らないのか？
簡単にデプロイするための独自のビルド管理環境を独立の専門チームが維持管理して、
それを使って本番システムに突っ込んで、実際のユーザからのリクエストの一部を
実験的アルゴリズムに回して、その結果を全部ロギングして分析評価してるんだよ。
アイツらが扱っているアルゴリズムはそこまでして実際の規模で動かさないと評価できねえんだよ。
790 ：デフォルトの名無しさん：2011/11/06(日) 18:26:44.05
791 ：デフォルトの名無しさん：2011/11/06(日) 18:28:20.53
792 ：デフォルトの名無しさん：2011/11/06(日) 18:31:43.67
>>788
そうやってママゴトプロジェクトで「俺がこの言語をマスターした！」とか言っちゃう時点でドカタだってのw
そうやってママゴトプロジェクトで「俺がこの言語をマスターした！」とか言っちゃう時点でドカタだってのw
793 ：デフォルトの名無しさん：2011/11/06(日) 18:32:18.90
794 ：デフォルトの名無しさん：2011/11/06(日) 18:35:07.65
795 ：デフォルトの名無しさん：2011/11/06(日) 18:42:36.21
796 ：デフォルトの名無しさん：2011/11/06(日) 18:45:54.85
797 ：デフォルトの名無しさん：2011/11/06(日) 18:47:16.20
>>794
で、ママゴトプロジェクトで使い物になるかどうかわかった気になっちゃうの？
あるいは、ママゴトプロジェクトで使い物になるかどうかわかるほど枯れたドカタ仕事ばかりなの？
なるほどね、ドカタってのはこういう考え方するんだねw
で、ママゴトプロジェクトで使い物になるかどうかわかった気になっちゃうの？
あるいは、ママゴトプロジェクトで使い物になるかどうかわかるほど枯れたドカタ仕事ばかりなの？
なるほどね、ドカタってのはこういう考え方するんだねw
798 ：デフォルトの名無しさん：2011/11/06(日) 18:48:10.56
799 ：デフォルトの名無しさん：2011/11/06(日) 18:50:27.40
800 ：デフォルトの名無しさん：2011/11/06(日) 18:53:14.65
801 ：デフォルトの名無しさん：2011/11/06(日) 18:54:21.44
>>786
新しい物を開発する仕事と、仕事を受ける側が新しい手法を開拓するのを同一視すんなよ。
受けた仕事の中に新しいことをしなきゃならない部分があるのは仕方ないし、
プロなら客と相談や確認しつつ先に進めていくべきだ。
そういった事の中で新しい事を覚えていくというのなら分かる。
でも既に扱える技術の組み合わせでも実現可能なのに、そこで未知の新技術を投入するのはプロの仕事じゃないだろ。
少なくともその技術を導入するメリットを客に説明できる程度には知ってないと。
客のいない仕事なら自分の責任の範囲で好きにすればいいよ。
新しい物を開発する仕事と、仕事を受ける側が新しい手法を開拓するのを同一視すんなよ。
受けた仕事の中に新しいことをしなきゃならない部分があるのは仕方ないし、
プロなら客と相談や確認しつつ先に進めていくべきだ。
そういった事の中で新しい事を覚えていくというのなら分かる。
でも既に扱える技術の組み合わせでも実現可能なのに、そこで未知の新技術を投入するのはプロの仕事じゃないだろ。
少なくともその技術を導入するメリットを客に説明できる程度には知ってないと。
客のいない仕事なら自分の責任の範囲で好きにすればいいよ。
802 ：デフォルトの名無しさん：2011/11/06(日) 18:54:27.79
>>798
例えば、俺は使えるがメンバー全員が使えるわけじゃない場合、
そのメンバーにとっては「使ったことない言語」なわけだ。
全員が使ったことがある言語しか使わねえってのが>>753-754だろ。
あと、別に俺が使えなくたって、有能な部下が使っている言語なら、
そいつにリーダーまかせて指導させるし、俺も頭下げて指導受ける。
技術者として、知っている奴が主導していく。当然だろ？
どうやらドカタ界隈じゃ肩書きが全てらしいけどなw
例えば、俺は使えるがメンバー全員が使えるわけじゃない場合、
そのメンバーにとっては「使ったことない言語」なわけだ。
全員が使ったことがある言語しか使わねえってのが>>753-754だろ。
あと、別に俺が使えなくたって、有能な部下が使っている言語なら、
そいつにリーダーまかせて指導させるし、俺も頭下げて指導受ける。
技術者として、知っている奴が主導していく。当然だろ？
どうやらドカタ界隈じゃ肩書きが全てらしいけどなw
803 ：デフォルトの名無しさん：2011/11/06(日) 18:57:19.82
>>801
で、プロジェクトを走らせながら新しい言語の１つや２つも学ぶ姿勢のない奴が
どうやって言語以外の技術を切り開いていくんだい？
けっきょくお前が言っているのは
「お客様に人月で雇われた身だから、お客様に言われたことだけします。
新しい技術とか仕事では使いません。」ってことだ。
わかりやすいドカタ思考。
で、プロジェクトを走らせながら新しい言語の１つや２つも学ぶ姿勢のない奴が
どうやって言語以外の技術を切り開いていくんだい？
けっきょくお前が言っているのは
「お客様に人月で雇われた身だから、お客様に言われたことだけします。
新しい技術とか仕事では使いません。」ってことだ。
わかりやすいドカタ思考。
804 ：デフォルトの名無しさん：2011/11/06(日) 19:01:20.91
805 ：デフォルトの名無しさん：2011/11/06(日) 19:03:39.40
806 ：デフォルトの名無しさん：2011/11/06(日) 19:10:05.44
807 ：デフォルトの名無しさん：2011/11/06(日) 19:20:55.01
自分より立場の悪い人たちに怠け者って言い放つ奴って
現実を知らない奴だよ
立場が弱くなるほど選択肢がなくなって
不利な条件になるから時間もなくなる金もない
努力する時間もない寝る時間すらもない
バカな政治家がホームレスを怠け者と言うけどさ
ホームレスを多数作り出す政治をする政治家の方がよほど怠け者だろ
無数の選択肢があっても現状を変える能力のない
そういう自分を恥じるべき、そのために努力したんじゃないのか
おまえは頭がいいから頭の悪い人たちを導くべきじゃないのか
努力した結果が他人を見下すための立場だとしたらそんな社会はクソだろ
保身のための努力の結果が原発だよ
歩きつかれたあの人へ冷たい言葉を平気で放つ
まさにそのとおりの人間だな
現実を知らない奴だよ
立場が弱くなるほど選択肢がなくなって
不利な条件になるから時間もなくなる金もない
努力する時間もない寝る時間すらもない
バカな政治家がホームレスを怠け者と言うけどさ
ホームレスを多数作り出す政治をする政治家の方がよほど怠け者だろ
無数の選択肢があっても現状を変える能力のない
そういう自分を恥じるべき、そのために努力したんじゃないのか
おまえは頭がいいから頭の悪い人たちを導くべきじゃないのか
努力した結果が他人を見下すための立場だとしたらそんな社会はクソだろ
保身のための努力の結果が原発だよ
歩きつかれたあの人へ冷たい言葉を平気で放つ
まさにそのとおりの人間だな
808 ：デフォルトの名無しさん：2011/11/06(日) 19:21:01.90
809 ：デフォルトの名無しさん：2011/11/06(日) 19:25:43.92
信用怖い
810 ：デフォルトの名無しさん：2011/11/06(日) 19:29:31.33
ちょっとまともな企業なら、儲ける案件とちょっとチャレンジャーな案件を織り交ぜてやってる。
どっちか一種類しかないと考えてる時点で、両方ともドカタなのがバレバレ (w
どっちか一種類しかないと考えてる時点で、両方ともドカタなのがバレバレ (w
811 ：デフォルトの名無しさん：2011/11/06(日) 19:45:37.90
>>810
チャレンジャーな案件はプログラマに丸投げ
一応責任物が結果はちゃんと出せよ
じゃね？
自分が使える言語で一番好きな言語は使っても、これから言語覚えながらチャレンジャーな案件とか、上司にも客にも結果を確約出来ないな
チャレンジャーな案件はプログラマに丸投げ
一応責任物が結果はちゃんと出せよ
じゃね？
自分が使える言語で一番好きな言語は使っても、これから言語覚えながらチャレンジャーな案件とか、上司にも客にも結果を確約出来ないな
812 ：デフォルトの名無しさん：2011/11/06(日) 19:49:28.05
儲ける案件をやりながらでも何処かにチャレンジを設定して技術を向上させるのがプロだろ。
813 ：デフォルトの名無しさん：2011/11/06(日) 19:50:32.27
カタカナ英語にしても、そこは「チャレンジングな案件」とか書いてほしい。
さすがにチャレンジャーな案件は無いだろ
さすがにチャレンジャーな案件は無いだろ
814 ：デフォルトの名無しさん：2011/11/06(日) 19:52:28.97
>>810
そんな当たり前な事ドヤ顔で言うなよ
そんな当たり前な事ドヤ顔で言うなよ
815 ：デフォルトの名無しさん：2011/11/06(日) 19:55:38.63
日本にまともな企業なんてないよ
全ての案件は下請けに丸投げ
さらに下請け孫請けのコンポジットパターンを形成してヤクザにピンはねされ
最終的にホームレスが現場で働いて死ぬ
余った利益でマスコミに広告を打ちまくり
政治家に献金して官僚に天下り先を作る
そして大失敗した場合は災害のせいにして国に助けを求める
これが基本パターンだな
全ての案件は下請けに丸投げ
さらに下請け孫請けのコンポジットパターンを形成してヤクザにピンはねされ
最終的にホームレスが現場で働いて死ぬ
余った利益でマスコミに広告を打ちまくり
政治家に献金して官僚に天下り先を作る
そして大失敗した場合は災害のせいにして国に助けを求める
これが基本パターンだな
816 ：デフォルトの名無しさん：2011/11/06(日) 19:56:37.56
817 ：デフォルトの名無しさん：2011/11/06(日) 19:57:21.58
せやな
新技術の勉強会とか自分らの金と時間使って勝手にやれっつう方が多いやろうな
新技術の勉強会とか自分らの金と時間使って勝手にやれっつう方が多いやろうな
818 ：デフォルトの名無しさん：2011/11/06(日) 20:05:40.97
逆だ。
チャレンジを設定できないチキンが結果なんて出せるわけがない。
もちろんチャレンジのためのリソースと客の理解を確保した上での話だ。
それができないならそもそもそんな仕事を受けるべきじゃない。
チャレンジを設定できないチキンが結果なんて出せるわけがない。
もちろんチャレンジのためのリソースと客の理解を確保した上での話だ。
それができないならそもそもそんな仕事を受けるべきじゃない。
819 ：デフォルトの名無しさん：2011/11/06(日) 20:09:35.89
客とか案件とか受託しかいねーのかよ
820 ：デフォルトの名無しさん：2011/11/06(日) 20:13:25.29
>>811-812, >>815, >>817
まあ、そういう職場も多いらしいが。
さすがに新しい手法とか規模のでかいチャレンジはそれ相応の対応が要るよ。
>>813
そりゃそうだな、すまん。
>>814
その当たり前のことがわかってない議論が延々と続いているんだが...
>>819
自社製品でも、客が偉いさんに変わるだけだろ。
まあ、そういう職場も多いらしいが。
さすがに新しい手法とか規模のでかいチャレンジはそれ相応の対応が要るよ。
>>813
そりゃそうだな、すまん。
>>814
その当たり前のことがわかってない議論が延々と続いているんだが...
>>819
自社製品でも、客が偉いさんに変わるだけだろ。
821 ：デフォルトの名無しさん：2011/11/06(日) 20:40:40.42
お前らドカタ舐めんな
技術や技能はおろかなんも勉強しねえ
英語すら読めねえ書けねえ
指摘されても教えられても明後日
なんか渋々覚えたことしか出来ねえやらねえ
何てのはザラ
二度とからみたくないわ
技術や技能はおろかなんも勉強しねえ
英語すら読めねえ書けねえ
指摘されても教えられても明後日
なんか渋々覚えたことしか出来ねえやらねえ
何てのはザラ
二度とからみたくないわ
822 ：デフォルトの名無しさん：2011/11/06(日) 20:51:26.55
823 ：デフォルトの名無しさん：2011/11/06(日) 20:55:44.58
>>821
それを英語で書いてみてよ
それを英語で書いてみてよ
824 ：デフォルトの名無しさん：2011/11/06(日) 20:57:57.20
My name is Dokata. This is a pen.
825 ：デフォルトの名無しさん：2011/11/06(日) 21:50:41.49
名前がドカタって。。。
英語出来ない自分でもMy work is Dokata. My job level is low level.位には書けるぞ。。。。
英語出来ない自分でもMy work is Dokata. My job level is low level.位には書けるぞ。。。。
826 ：デフォルトの名無しさん：2011/11/06(日) 21:52:21.02
日々研鑽だなら
仕事もプライベートも関係ない
仕事もプライベートも関係ない
827 ：デフォルトの名無しさん：2011/11/06(日) 21:53:08.63
I am Dokata. でok
828 ：デフォルトの名無しさん：2011/11/06(日) 21:54:49.72
829 ：デフォルトの名無しさん：2011/11/06(日) 21:56:10.95
Don't underestimate Dokata.
They are really stupid, and never study everything
not to mention technology and technique.
Of course, they can't read and write English.
No matter how hard I teach or point out things they pay no attention.
They perform minimum work in a grudging manner.
I don't want to deal with Dokata again.
They are really stupid, and never study everything
not to mention technology and technique.
Of course, they can't read and write English.
No matter how hard I teach or point out things they pay no attention.
They perform minimum work in a grudging manner.
I don't want to deal with Dokata again.
830 ：デフォルトの名無しさん：2011/11/06(日) 22:04:26.74
831 ：デフォルトの名無しさん：2011/11/06(日) 22:12:27.11
>>829
やればできるじゃないか。合格点を与えよう。
やればできるじゃないか。合格点を与えよう。
いや、書いといてなんだけど俺ドカタだからw
833 ：デフォルトの名無しさん：2011/11/06(日) 22:24:19.43
実際、ただの学生なんかより
ドカタのほうが技術力上だよ。
いや、当たり前なんだけどねｗ
ドカタは元学生なわけだし。
ドカタのほうが技術力上だよ。
いや、当たり前なんだけどねｗ
ドカタは元学生なわけだし。
834 ：デフォルトの名無しさん：2011/11/06(日) 22:30:50.07
ぜんぜん当たり前じゃないだろ。
技術力ってほっとくとどんどん下がるよ。
本人そのままでも、回りはどんどん進むからね。
だから、普通の学生より技術力のないドカタなんていくらでもいる。
て言うことが理解できてない、>>833 もその手の口かと。
技術力ってほっとくとどんどん下がるよ。
本人そのままでも、回りはどんどん進むからね。
だから、普通の学生より技術力のないドカタなんていくらでもいる。
て言うことが理解できてない、>>833 もその手の口かと。
835 ：デフォルトの名無しさん：2011/11/06(日) 22:33:39.90
いやー、俺も時々ドカタwwwとか書いて煽ってるけどね
なんか今日はマジでドカタを見下してる感じの人が居て引くわー
ちゃんと冗談って分かってやってるんだよね？
なんか今日はマジでドカタを見下してる感じの人が居て引くわー
ちゃんと冗談って分かってやってるんだよね？
836 ：デフォルトの名無しさん：2011/11/06(日) 22:51:58.08
ん？なんか煽られてると思ったら
誰かが英訳してくれてる流れにわろた
誰かが英訳してくれてる流れにわろた
837 ：デフォルトの名無しさん：2011/11/06(日) 23:28:19.51
>>834
その「普通の学生」って帝大レベルの普通の学生っていう意味で使ってるよね？
それなら同意。
そうでなくピンからキリまで日本の大学全般の平均っていう意味で言ってるなら
それよりレベルの低いプログラマなんかどこにもいないよ
その「普通の学生」って帝大レベルの普通の学生っていう意味で使ってるよね？
それなら同意。
そうでなくピンからキリまで日本の大学全般の平均っていう意味で言ってるなら
それよりレベルの低いプログラマなんかどこにもいないよ
838 ：デフォルトの名無しさん：2011/11/06(日) 23:28:26.45
>>834
それは、学生でも馬鹿はいるよ。と言ってるのとなにも変わらんｗ
それは、学生でも馬鹿はいるよ。と言ってるのとなにも変わらんｗ
839 ：デフォルトの名無しさん：2011/11/06(日) 23:31:13.55
頭が悪いやつらは直ぐにドカタとか喧嘩しはじめて話がずれるから嫌いだ
こういうくだっらない喧嘩は誰も何の得にもならない
せめてスレタイに沿った議論をしろよ
こういうくだっらない喧嘩は誰も何の得にもならない
せめてスレタイに沿った議論をしろよ
840 ：デフォルトの名無しさん：2011/11/06(日) 23:32:02.68
841 ：デフォルトの名無しさん：2011/11/06(日) 23:35:40.15
>>839
ネタ振りどうぞ
ネタ振りどうぞ
842 ：デフォルトの名無しさん：2011/11/06(日) 23:36:17.16
学生だろうがドカタだろうがどうでもいいんだよ
動的型付けと静的型付けの話をしろ
動的型付けと静的型付けの話をしろ
843 ：デフォルトの名無しさん：2011/11/06(日) 23:37:35.99
>>842
ネタ振りどうぞ
ネタ振りどうぞ
844 ：デフォルトの名無しさん：2011/11/06(日) 23:45:00.89
動的型付け言語が大規模開発に向かない理由がよくわからない
主な理由はコンパイル時に多くのエラーがわからないといったところだろうけど
ideの発達により動的型付け言語ですらメソッドの補完もできるようになり
かなりの静的解析をやってしまうようになった
それでもまだ向かない理由ってなんだろうか
主な理由はコンパイル時に多くのエラーがわからないといったところだろうけど
ideの発達により動的型付け言語ですらメソッドの補完もできるようになり
かなりの静的解析をやってしまうようになった
それでもまだ向かない理由ってなんだろうか
845 ：デフォルトの名無しさん：2011/11/06(日) 23:51:39.56
開発者の多い大規模開発では、必然的にコミュニケーションがより重要である
ドキュメントはコミュニケーションの重要な要素の一つであり
ソースコードはもっとも重要なドキュメントである
一般には静的型付け言語のほうがドキュメント性が高い
（コードそのものに型という形でプログラマの意図を直接記述できるという意味で）
コードとして記述された意図は人とコンパイラの両者に理解され機械的に
チェックされるので、コメントやドキュメント文字列の類よりはるかに厳密で
誤りの可能性が少ない
こんなところでどうか
ドキュメントはコミュニケーションの重要な要素の一つであり
ソースコードはもっとも重要なドキュメントである
一般には静的型付け言語のほうがドキュメント性が高い
（コードそのものに型という形でプログラマの意図を直接記述できるという意味で）
コードとして記述された意図は人とコンパイラの両者に理解され機械的に
チェックされるので、コメントやドキュメント文字列の類よりはるかに厳密で
誤りの可能性が少ない
こんなところでどうか
846 ：デフォルトの名無しさん：2011/11/06(日) 23:55:29.72
理屈は通ってると思うけど抽象的だね
そのドキュメント性が、コメントや変数の名前に
勝る理由が、コンパイラによってチェックされるからだ
と言われても、あまり俺には説得力を持たない
具体例で説明できたらいいと思う
そのドキュメント性が、コメントや変数の名前に
勝る理由が、コンパイラによってチェックされるからだ
と言われても、あまり俺には説得力を持たない
具体例で説明できたらいいと思う
847 ：デフォルトの名無しさん：2011/11/07(月) 00:03:11.87
>>846
具体的といっても……
# x: int, y: int
def add(x, y):
if not isinstance(x, int): 〜
とか書くぐらいなら
int add(int x, int y)
のほうがいいだろう、ということだけど
後者のほうが楽で、見た目で明らかで、コメント不一致やチェック抜けなどの
誤りが入る余地が無い
具体的といっても……
# x: int, y: int
def add(x, y):
if not isinstance(x, int): 〜
とか書くぐらいなら
int add(int x, int y)
のほうがいいだろう、ということだけど
後者のほうが楽で、見た目で明らかで、コメント不一致やチェック抜けなどの
誤りが入る余地が無い
848 ：デフォルトの名無しさん：2011/11/07(月) 00:05:48.01
まあこう書くと、この程度でチェックできることはたかが知れているという
反論があるのは承知しているし、実際その通りなんだが
何もないよりはチェックできる部分が多いほうが相対的にマシだ、という考え
反論があるのは承知しているし、実際その通りなんだが
何もないよりはチェックできる部分が多いほうが相対的にマシだ、という考え
849 ：デフォルトの名無しさん：2011/11/07(月) 00:08:08.57
850 ：デフォルトの名無しさん：2011/11/07(月) 00:09:16.46
チェックが重要なのではない。
コードに説明が書いてあることが重要。
コードに説明が書いてあることが重要。
851 ：デフォルトの名無しさん：2011/11/07(月) 00:26:53.74
コードとは別の場所にドキュメントを書くと、
コードとドキュメントは本当に一致しているのか？って問題が起きるからね。
コード＝ドキュメントと考え、コードに全てを書く方が間違いが起こらない。
そして言語仕様として扱うと、コンピュータが機械的に理解できるようになる。
そうすると、人間が不得意な類の間違い（スペルミスとか誰でのやるミス）を見つけてくれる。
コードとドキュメントは本当に一致しているのか？って問題が起きるからね。
コード＝ドキュメントと考え、コードに全てを書く方が間違いが起こらない。
そして言語仕様として扱うと、コンピュータが機械的に理解できるようになる。
そうすると、人間が不得意な類の間違い（スペルミスとか誰でのやるミス）を見つけてくれる。
852 ：デフォルトの名無しさん：2011/11/07(月) 00:43:22.42
説明の仕方がマニュアル化されてるんだな。
マークシートを塗りつぶすだけの解答用紙みたいに。
ドキュメントとしては役に立たない。
マークシートを塗りつぶすだけの解答用紙みたいに。
ドキュメントとしては役に立たない。
853 ：デフォルトの名無しさん：2011/11/07(月) 00:48:11.27
動的言語で大規模開発は効率が悪いどころか論外
マシン語の16進数でプログラム組むようなもん
悪夢以外の何物でもない
マシン語の16進数でプログラム組むようなもん
悪夢以外の何物でもない
854 ：デフォルトの名無しさん：2011/11/07(月) 00:55:27.62
855 ：デフォルトの名無しさん：2011/11/07(月) 01:06:03.87
たとえ話でもいいだろ。
たとえ話を禁止されて何も書けなくなるより
形式にこだわらず何か書く方がドキュメント性は高い。
たとえ話を禁止されて何も書けなくなるより
形式にこだわらず何か書く方がドキュメント性は高い。
856 ：デフォルトの名無しさん：2011/11/07(月) 01:06:39.73
静的型言語は、テスト時に静的解析が比較的やりやすいのが重要。
コンパイル時に型チェックが行われるのも、その一部と考えていい。
動的型言語は実行してみるまで何が起きるかわからないので、
コーディングの記述量が減っても、きっちりテストをしようと思うと、テストケースが膨れ上がってしまう。
コンパイル時に型チェックが行われるのも、その一部と考えていい。
動的型言語は実行してみるまで何が起きるかわからないので、
コーディングの記述量が減っても、きっちりテストをしようと思うと、テストケースが膨れ上がってしまう。
857 ：デフォルトの名無しさん：2011/11/07(月) 01:12:20.41
858 ：デフォルトの名無しさん：2011/11/07(月) 02:35:04.81
>>855
いいや、この場合は喩え話じゃダメだね。
一般的に喩え話を使って批判すると、
一体何を批判しているのかわからなくなる。
カレーってウンコみたいな色だよね。
ウンコ食べたいと思う？みたいにウンコを
批判する話にすり替えるという下らない事やり始める。
いいや、この場合は喩え話じゃダメだね。
一般的に喩え話を使って批判すると、
一体何を批判しているのかわからなくなる。
カレーってウンコみたいな色だよね。
ウンコ食べたいと思う？みたいにウンコを
批判する話にすり替えるという下らない事やり始める。
859 ：デフォルトの名無しさん：2011/11/07(月) 02:39:38.41
>>857
たとえば、itoaみたいな関数の場合。
C言語なら引数はintって決まっているから引数の型のチェックの必要はないが、
動的型付け言語だと、引数がintであるかのチェックを関数でしないといけないし、
また関数にそのチェックが加わったことで、それに関するテストケースが必要になる。
たとえば、itoaみたいな関数の場合。
C言語なら引数はintって決まっているから引数の型のチェックの必要はないが、
動的型付け言語だと、引数がintであるかのチェックを関数でしないといけないし、
また関数にそのチェックが加わったことで、それに関するテストケースが必要になる。
860 ：デフォルトの名無しさん：2011/11/07(月) 05:11:48.68
動的言語ではitoaなんて必要ない
861 ：デフォルトの名無しさん：2011/11/07(月) 05:20:24.64
ええええええええええええええ
862 ：デフォルトの名無しさん：2011/11/07(月) 05:50:02.15
863 ：デフォルトの名無しさん：2011/11/07(月) 06:07:51.69
aptana studioについてるpydevも普通に補完するな
あと、マイナーだが、intellij ideaのluaとか、clojureプラグイン
あと、マイナーだが、intellij ideaのluaとか、clojureプラグイン
864 ：デフォルトの名無しさん：2011/11/07(月) 08:28:17.18
865 ：デフォルトの名無しさん：2011/11/07(月) 08:39:55.80
そのitoaは本当にintを受け取らなきゃダメだったのか？intに制限する理由は何だ？
実はstringを返せるならどんな型でも良かったんじゃないか？
実際に動的型言語では x.to_s() や str(x) のようなやり方が殆どだ
つまり何が言いたいかというと、例が悪い
あまりに悪すぎて、動的型言語を使った事が無いのかと疑いを持つレベル
実はstringを返せるならどんな型でも良かったんじゃないか？
実際に動的型言語では x.to_s() や str(x) のようなやり方が殆どだ
つまり何が言いたいかというと、例が悪い
あまりに悪すぎて、動的型言語を使った事が無いのかと疑いを持つレベル
866 ：デフォルトの名無しさん：2011/11/07(月) 08:50:01.59
その言語のソースを見てみろよ
867 ：デフォルトの名無しさん：2011/11/07(月) 08:57:40.63
本質はそこじゃないだろ。
to_s を x ごとに実装するのだから中身は itoa 作ってるのと同じ。
「x が to_s を持っているか否か」をコンパイル時にチェックして、
持っていなければコンパイルエラーにするのが静的型付け。
実行時にチェックして、持っていなければ実行時エラーにするのが動的型付け。
to_s を x ごとに実装するのだから中身は itoa 作ってるのと同じ。
「x が to_s を持っているか否か」をコンパイル時にチェックして、
持っていなければコンパイルエラーにするのが静的型付け。
実行時にチェックして、持っていなければ実行時エラーにするのが動的型付け。
868 ：デフォルトの名無しさん：2011/11/07(月) 09:03:34.88
動的型付けでいいという人に聞きたいのだが、
動的にチェックするのがデバッグモードだけで、リリースモードでは
「x が to_s を持っていなければ単に暴走する」
でも大規模システムの開発効率上問題ないか？
問題ないと自信を持って言い切れるならこの議論は終わりだと思う。
「いやそれはさすがに問題だ」というなら、何故問題なのか。
そこを考えてみてほしい。
動的にチェックするのがデバッグモードだけで、リリースモードでは
「x が to_s を持っていなければ単に暴走する」
でも大規模システムの開発効率上問題ないか？
問題ないと自信を持って言い切れるならこの議論は終わりだと思う。
「いやそれはさすがに問題だ」というなら、何故問題なのか。
そこを考えてみてほしい。
869 ：デフォルトの名無しさん：2011/11/07(月) 09:08:21.55
でもその場合は型チェックなんて必要ないだろ
to_s や __str__ を持ってるか否かなんだから、いわゆる「型」の話じゃない
そしてメソッドの有無も、わざわざチェックしなくても無かったら例外が出る
ということを踏まえて、どんなテストケースが増えるんだ？
to_s や __str__ を持ってるか否かなんだから、いわゆる「型」の話じゃない
そしてメソッドの有無も、わざわざチェックしなくても無かったら例外が出る
ということを踏まえて、どんなテストケースが増えるんだ？
870 ：デフォルトの名無しさん：2011/11/07(月) 09:23:20.89
例外でるからテストしなくていいのか
871 ：デフォルトの名無しさん：2011/11/07(月) 09:25:43.62
そういう煽りはいいから、どんなテストケースが増えるのか言えよ
具体例付きでな
具体例付きでな
872 ：デフォルトの名無しさん：2011/11/07(月) 09:34:07.81
例外上がるように設計したなら、その分のテスト増えるな
873 ：デフォルトの名無しさん：2011/11/07(月) 09:36:30.43
>>869
うーん。君の理解はいまいち。
オブジェクトがメソッドを持っているということを「型」で表現するのが、
インタフェースの考え方そのもの。
わざわざチェックしなくても無かったら例外を出してくれるのは、
実行時システムがチェックしてるから。
うーん。君の理解はいまいち。
オブジェクトがメソッドを持っているということを「型」で表現するのが、
インタフェースの考え方そのもの。
わざわざチェックしなくても無かったら例外を出してくれるのは、
実行時システムがチェックしてるから。
874 ：デフォルトの名無しさん：2011/11/07(月) 09:39:57.69
ほらね。動的型言語を使った事無いから
itoaみたいな的外れの例しか出せないし、
具体例を出すと突っ込まれるから
段々抽象的なことしか書けなくなる
itoaみたいな的外れの例しか出せないし、
具体例を出すと突っ込まれるから
段々抽象的なことしか書けなくなる
875 ：デフォルトの名無しさん：2011/11/07(月) 09:41:44.58
876 ：デフォルトの名無しさん：2011/11/07(月) 09:43:48.34
普通に動的型言語使ってたら、使ってる動的型言語自体にどんどんテスト増えてく様を見てそうなもんだが
877 ：デフォルトの名無しさん：2011/11/07(月) 09:45:16.60
たとえば、配列の範囲外アクセスなんかは型システムで検出できない。
だからといって、大抵の言語ではそのまま暴走するなんてことにはならず、
ちゃんと例外が出る。
なぜ例外を出せるかっていうと、
実行時システム (VM と言ってもいい) がチェックしているから。
大抵の用途では、暴走するより例外として検出できる方がよい。
その例外を適切に処理するコードさえ書いておけば何とかなるので。
(配列の範囲外アクセスはほぼ100%バグなので、catch して何とかするというのは本来違うと思うが、例外処理一般論として)
でも、もし可能なら、実行時に例外を出してもらうよりコンパイル時に検出できる方が、さらによい。
コンパイルが通れば範囲外アクセスは無いということが保証されるなら、catch する処理はいらないから。
もっと言うと、コンパイル時に検出するより、書いた瞬間にエディタ上で教えてくれる方が、さらによい。
周知のとおり、今の IDE は可能な限りそうしようとしているね。
こんな感じでどうでしょうか。
だからといって、大抵の言語ではそのまま暴走するなんてことにはならず、
ちゃんと例外が出る。
なぜ例外を出せるかっていうと、
実行時システム (VM と言ってもいい) がチェックしているから。
大抵の用途では、暴走するより例外として検出できる方がよい。
その例外を適切に処理するコードさえ書いておけば何とかなるので。
(配列の範囲外アクセスはほぼ100%バグなので、catch して何とかするというのは本来違うと思うが、例外処理一般論として)
でも、もし可能なら、実行時に例外を出してもらうよりコンパイル時に検出できる方が、さらによい。
コンパイルが通れば範囲外アクセスは無いということが保証されるなら、catch する処理はいらないから。
もっと言うと、コンパイル時に検出するより、書いた瞬間にエディタ上で教えてくれる方が、さらによい。
周知のとおり、今の IDE は可能な限りそうしようとしているね。
こんな感じでどうでしょうか。
878 ：デフォルトの名無しさん：2011/11/07(月) 09:47:25.31
>>875
877 を踏まえて直接的に答えるなら、
to_s を持つモックオブジェクト、持たないモックオブジェクトを作って、
それぞれ、to_s が実行されること、例外が発生することをチェックするテストケースが必要。
877 を踏まえて直接的に答えるなら、
to_s を持つモックオブジェクト、持たないモックオブジェクトを作って、
それぞれ、to_s が実行されること、例外が発生することをチェックするテストケースが必要。
879 ：デフォルトの名無しさん：2011/11/07(月) 09:49:12.04
toStringメソッドを持っていないオブジェクトなんてないし
overrideすることをうっかり忘れてもコンパイル時にチェックすることはできない
overrideすることをうっかり忘れてもコンパイル時にチェックすることはできない
880 ：デフォルトの名無しさん：2011/11/07(月) 09:50:52.82
アホか、to_sが無かったら例外が上がるのは「言語仕様で」決まってる
そんなんテストする馬鹿がいるか
そんなんテストする馬鹿がいるか
881 ：デフォルトの名無しさん：2011/11/07(月) 09:51:44.08
to_s は例だと思えばいいよ。自作のメソッドだと思ってくれ。
その程度の汎化は各自で頼むね。
その程度の汎化は各自で頼むね。
882 ：デフォルトの名無しさん：2011/11/07(月) 09:53:30.36
だからメソッドが見つかんないとき例外が発生するのは
言語仕様で決まってんだよ
そんなんテストするアホがいるか
言語仕様で決まってんだよ
そんなんテストするアホがいるか
883 ：デフォルトの名無しさん：2011/11/07(月) 09:55:53.14
動的言語使ってると、そういうアホみたいなテストをするじゃん
884 ：デフォルトの名無しさん：2011/11/07(月) 09:56:11.67
ああそうね。881 は外した。
その例外が上がらない言語は困るでしょ？そこは同意できる？
できるなら次。
その例外が起きるのは、作ろうとしているシステムにとって正常系？
つまり、to_foobar を使う関数に to_foobar を持たないオブジェクトを「意図的に」渡して、
「意図的に」例外を発生させて、その例外処理の中で「意図的に正常系の処理を書く」
ようなシステムを作ることってある？
その例外が上がらない言語は困るでしょ？そこは同意できる？
できるなら次。
その例外が起きるのは、作ろうとしているシステムにとって正常系？
つまり、to_foobar を使う関数に to_foobar を持たないオブジェクトを「意図的に」渡して、
「意図的に」例外を発生させて、その例外処理の中で「意図的に正常系の処理を書く」
ようなシステムを作ることってある？
885 ：デフォルトの名無しさん：2011/11/07(月) 10:10:17.41
持っていることを知りたいなら、持つかどうか調べるのがわかりやすいね
型を調べたり例外を調べると意図がわかりにくい
型を調べたり例外を調べると意図がわかりにくい
886 ：デフォルトの名無しさん：2011/11/07(月) 10:13:17.46
引数としてintを受け取りたい関数がある時、静的型付けならテストするのはintだけでいいけど、動的型付けなら文字列なども必要
って話だと思ったんだけど違うの？
って話だと思ったんだけど違うの？
887 ：デフォルトの名無しさん：2011/11/07(月) 10:18:56.12
>>884
method missingを使うシステムは、まさにそうだろう（実際には例外は発生しないが）
で、それはそれとして、そういうのを異常系として認めたくない場合、
静的型言語では何もしなくてもコンパイラが弾くけど
動的型言語ではテストしなきゃ弾けない
ここまでは静的型言語の良いところで、皆が認める
でも、結局のところテストは書くんだろ？
そのときにどんなテストケースが増えるのか？というのが質問なわけよ
method missingを使うシステムは、まさにそうだろう（実際には例外は発生しないが）
で、それはそれとして、そういうのを異常系として認めたくない場合、
静的型言語では何もしなくてもコンパイラが弾くけど
動的型言語ではテストしなきゃ弾けない
ここまでは静的型言語の良いところで、皆が認める
でも、結局のところテストは書くんだろ？
そのときにどんなテストケースが増えるのか？というのが質問なわけよ
888 ：デフォルトの名無しさん：2011/11/07(月) 10:19:59.94
馬鹿馬鹿しい例だが
Pythonで文字列のリストに"foo"という文字列が含まれているか検査する関数を考える
def has_foo(xs): return 'foo' in xs
以下が、意図された動作
has_foo(('foo', 'bar')) → True
has_foo(('bar', 'bazz')) → False
しかし、以下が何の実行時エラーにもならないことにも注意しよう
has_foo('foo') → True
has_foo('fooo') → True
たぶんこれは意図したことではないはずだ
Pythonで文字列のリストに"foo"という文字列が含まれているか検査する関数を考える
def has_foo(xs): return 'foo' in xs
以下が、意図された動作
has_foo(('foo', 'bar')) → True
has_foo(('bar', 'bazz')) → False
しかし、以下が何の実行時エラーにもならないことにも注意しよう
has_foo('foo') → True
has_foo('fooo') → True
たぶんこれは意図したことではないはずだ
889 ：デフォルトの名無しさん：2011/11/07(月) 10:21:24.87
このように、エラーにもならず意図しないデータ型で動いてしまうという例が
一番たちが悪い
一番たちが悪い
890 ：デフォルトの名無しさん：2011/11/07(月) 10:23:11.28
Pythonを知らない人のためにつけくわけておくが、
もちろん「正しく」使っていれば
has_foo(('fooo')) → False
has_foo(('fooo', 'foooo')) → False
こうなるよ
もちろん「正しく」使っていれば
has_foo(('fooo')) → False
has_foo(('fooo', 'foooo')) → False
こうなるよ
891 ：デフォルトの名無しさん：2011/11/07(月) 10:23:57.79
ごめん
has_foo(('fooo',))
のように書かないといけないのだったな
has_foo(('fooo',))
のように書かないといけないのだったな
892 ：デフォルトの名無しさん：2011/11/07(月) 10:27:19.23
それって静的型言語でも多相型を使ってれば普通に起こることだけど？
893 ：デフォルトの名無しさん：2011/11/07(月) 10:34:53.45
>>892
なぜこのごく単純で馬鹿馬鹿しい問題に多相型を持ち出す必要があるのだろうか？
ごくシンプルな問題だから、シンプルで誤りの入りようがない解を静的型なら書ける
「リストでは限定しすぎだから文字列のコレクションは受け入れる」としても
特に問題はない
なぜこのごく単純で馬鹿馬鹿しい問題に多相型を持ち出す必要があるのだろうか？
ごくシンプルな問題だから、シンプルで誤りの入りようがない解を静的型なら書ける
「リストでは限定しすぎだから文字列のコレクションは受け入れる」としても
特に問題はない
894 ：デフォルトの名無しさん：2011/11/07(月) 10:37:28.75
listを受け取った時は'foo'が要素にある場合に真を返し、
strを受け取った時は'foo'を部分列として持つ場合に真を返す
has_foo という名前から連想される多相関数としては、極めて妥当な振舞いだと思うけどね
strを受け取った時は'foo'を部分列として持つ場合に真を返す
has_foo という名前から連想される多相関数としては、極めて妥当な振舞いだと思うけどね
895 ：デフォルトの名無しさん：2011/11/07(月) 10:38:52.04
段々ただの難癖になってきたな
896 ：デフォルトの名無しさん：2011/11/07(月) 10:42:26.16
897 ：デフォルトの名無しさん：2011/11/07(月) 10:44:45.95
動的型言語は多相的に振る舞う関数が書きやすく
（型推論があってもランク2多相には型注釈が必須）
静的型言語では単相的に振る舞う関数が書きやすい
それだけの話なわけだが
（型推論があってもランク2多相には型注釈が必須）
静的型言語では単相的に振る舞う関数が書きやすい
それだけの話なわけだが
898 ：デフォルトの名無しさん：2011/11/07(月) 10:47:23.54
899 ：デフォルトの名無しさん：2011/11/07(月) 10:48:56.61
>>896
引数がコレクションか否かまで判定する必要がある関数を定義したきゃ
def has_foo_in_collection(xs):
return is_collection(xs) and has_foo(xs)
という関数にでもしとけよ
引数がコレクションか否かまで判定する必要がある関数を定義したきゃ
def has_foo_in_collection(xs):
return is_collection(xs) and has_foo(xs)
という関数にでもしとけよ
900 ：デフォルトの名無しさん：2011/11/07(月) 10:49:51.51
プログラマが意図していないのだから、プログラムとして（多層的にも）正しい
振る舞いになっているかどうかは「わからない」
処理系から見れば弾くべきところがないのだから実行時エラーにもならない
通常は、しばしば発見が困難なバグにつながる
振る舞いになっているかどうかは「わからない」
処理系から見れば弾くべきところがないのだから実行時エラーにもならない
通常は、しばしば発見が困難なバグにつながる
901 ：デフォルトの名無しさん：2011/11/07(月) 10:51:51.88
静的型言語と違って、動的型言語では関数はデフォルトで多相的に振る舞うんだから
それを想定できないのは動的型言語プログラマとして未熟なだけ
それを想定できないのは動的型言語プログラマとして未熟なだけ
902 ：デフォルトの名無しさん：2011/11/07(月) 10:53:29.96
ついに逃げたか
903 ：デフォルトの名無しさん：2011/11/07(月) 10:54:31.19
いや、マジでこれが問題だっつーならHaskellやOCamlは使えないぞ？
904 ：デフォルトの名無しさん：2011/11/07(月) 11:00:53.30
熟練した動的型言語プログラマでも
大規模開発は無理
大規模開発は無理
905 ：デフォルトの名無しさん：2011/11/07(月) 11:02:44.69
「型」の事を、数値や文字の内部表現の事だと勘違いしてる者が混ざってるから、話があっちこっちに飛んでるな。
906 ：デフォルトの名無しさん：2011/11/07(月) 11:03:53.76
Pythonプログラマはinが組み込み型strにも使える事を知ってるから
あんなミスはしないんですけどね
あんなミスはしないんですけどね
907 ：デフォルトの名無しさん：2011/11/07(月) 11:59:51.00
テストケースが増える具体例を示せ、って言われたから示したらこれか
908 ：デフォルトの名無しさん：2011/11/07(月) 12:01:26.52
実行時エラーなんか出されても死ぬしかないという意味では、テストは増えないかもしれないな
909 ：デフォルトの名無しさん：2011/11/07(月) 12:03:51.16
あの例ではコンテナにhas_fooメソッドの定義を足して
x.has_foo() って呼び出すべきだな
文字列は has_foo メソッド持ってないから例外だ
x.has_foo() って呼び出すべきだな
文字列は has_foo メソッド持ってないから例外だ
910 ：デフォルトの名無しさん：2011/11/07(月) 12:27:34.84
>>899
もちろん引数型を明示的にチェックして単相をエミュレートすることも可能だけれども
それをやるぐらいなら最初から静的型のほうがマシでは？
これはどちらがデフォルトのほうが適切／マシか、という議論かもしれないな
>>901
>>906
人は誤り、かならず見落としをし、バグは生まれるものだ
そして大規模開発ではそれだけ誤りが発生する可能性が高い
ということが理解できないようでは動的・静的型関係なしでプログラマとして未熟だ
もちろん引数型を明示的にチェックして単相をエミュレートすることも可能だけれども
それをやるぐらいなら最初から静的型のほうがマシでは？
これはどちらがデフォルトのほうが適切／マシか、という議論かもしれないな
>>901
>>906
人は誤り、かならず見落としをし、バグは生まれるものだ
そして大規模開発ではそれだけ誤りが発生する可能性が高い
ということが理解できないようでは動的・静的型関係なしでプログラマとして未熟だ
911 ：デフォルトの名無しさん：2011/11/07(月) 12:37:08.53
912 ：デフォルトの名無しさん：2011/11/07(月) 12:44:59.66
>>911
>>909の場合は、仕様が違うし使い勝手はデグレードしているね
元のhas_foo()にはiterable, list, tuple, setを直接渡せて
その場合には意図した動作になっている
より重要なことは、>>888のような実装をすると問題があるとして、
「そういう問題のある実装をしない」ことは保障のしようがない
>>909の場合は、仕様が違うし使い勝手はデグレードしているね
元のhas_foo()にはiterable, list, tuple, setを直接渡せて
その場合には意図した動作になっている
より重要なことは、>>888のような実装をすると問題があるとして、
「そういう問題のある実装をしない」ことは保障のしようがない
913 ：デフォルトの名無しさん：2011/11/07(月) 12:49:16.18
んなこと言ったら、厳密に言えば静的型言語で has_foo と
同じ仕様の関数を書こうとしたら多相型にするかObject型（top）渡すしか無いじゃん
勝手に有利な仕様を持ち出されてもな
そんで、x.has_foo() って仕様で現実問題として何か困んの？
同じ仕様の関数を書こうとしたら多相型にするかObject型（top）渡すしか無いじゃん
勝手に有利な仕様を持ち出されてもな
そんで、x.has_foo() って仕様で現実問題として何か困んの？
914 ：デフォルトの名無しさん：2011/11/07(月) 12:52:27.77
>>912
> 「そういう問題のある実装をしない」ことは保障のしようがない
in : 'a -> 'b -> bool って二項演算子があって
let foo xs = 'foo' in xs
って書いたら静的型でも一緒だろ？こういう関数を書くのをどうやって防ぐの？
> 「そういう問題のある実装をしない」ことは保障のしようがない
in : 'a -> 'b -> bool って二項演算子があって
let foo xs = 'foo' in xs
って書いたら静的型でも一緒だろ？こういう関数を書くのをどうやって防ぐの？
915 ：デフォルトの名無しさん：2011/11/07(月) 12:53:45.75
>>913
そう、多相になるけれども、たとえば.NETなら
IEnumerable<String>とでもすればいい話だろう
IEnumerable<String>はIEnumerable<Char>とは違う型なので、文字列を
文字のコレクションとして扱える言語でも、文字列を渡せばエラーは検出できる
Pythonでもstrが「文字の」シークエンスだったなら、has_foo()にstrを渡したら
'foo'との比較時に実行時エラーになってくれるだろうが、そうではない
そう、多相になるけれども、たとえば.NETなら
IEnumerable<String>とでもすればいい話だろう
IEnumerable<String>はIEnumerable<Char>とは違う型なので、文字列を
文字のコレクションとして扱える言語でも、文字列を渡せばエラーは検出できる
Pythonでもstrが「文字の」シークエンスだったなら、has_foo()にstrを渡したら
'foo'との比較時に実行時エラーになってくれるだろうが、そうではない
916 ：デフォルトの名無しさん：2011/11/07(月) 12:55:38.12
917 ：デフォルトの名無しさん：2011/11/07(月) 13:00:16.21
もう依存型しかないな
918 ：デフォルトの名無しさん：2011/11/07(月) 13:00:48.16
なんか面倒になってきた
>>910
> これはどちらがデフォルトのほうが適切／マシか、という議論かもしれないな
テストケースが増えるかどうかはともかく、これについては同意だな
フレームワーク的なものを作るときは多相型がデフォルトの方が楽だし、
そうじゃないときは単相型のほうが安心な気がする
>>910
> これはどちらがデフォルトのほうが適切／マシか、という議論かもしれないな
テストケースが増えるかどうかはともかく、これについては同意だな
フレームワーク的なものを作るときは多相型がデフォルトの方が楽だし、
そうじゃないときは単相型のほうが安心な気がする
919 ：デフォルトの名無しさん：2011/11/07(月) 13:05:18.23
全てが多相な上さらにoptionalでさらにそれが決定不能であるという恐ろしさ
920 ：デフォルトの名無しさん：2011/11/07(月) 13:38:07.17
動的型言語でもそれなりの言語なら型宣言できるし
一通りのコンパイル時チェックもやってくれると思うんだが
多相型が不安なら多相型使わなきゃいいだけの話じゃん
お前ら何を話してるん?
一通りのコンパイル時チェックもやってくれると思うんだが
多相型が不安なら多相型使わなきゃいいだけの話じゃん
お前ら何を話してるん?
921 ：デフォルトの名無しさん：2011/11/07(月) 13:42:34.24
それなりの言語ってどれだよ
922 ：デフォルトの名無しさん：2011/11/07(月) 14:54:51.45
CLの静的検証ツール作ってくれや
923 ：デフォルトの名無しさん：2011/11/07(月) 16:41:06.57
924 ：デフォルトの名無しさん：2011/11/07(月) 17:11:32.68
925 ：デフォルトの名無しさん：2011/11/07(月) 17:15:19.16
926 ：デフォルトの名無しさん：2011/11/07(月) 17:19:50.04
>>923
隔離スレですね。ああいえば上祐（死語）もあるし、内容を見てその
滑稽さにいろいろ感じることがいいのかも。プログラマーのための
バラエティスレだよね。ただ、色んなひといるみたいで、現場の人
アカデミックの人そこからドカ太郎まで見かける。共通してるのは
比較的暇を持て余している状況下にある人で占められているという事。
隔離スレですね。ああいえば上祐（死語）もあるし、内容を見てその
滑稽さにいろいろ感じることがいいのかも。プログラマーのための
バラエティスレだよね。ただ、色んなひといるみたいで、現場の人
アカデミックの人そこからドカ太郎まで見かける。共通してるのは
比較的暇を持て余している状況下にある人で占められているという事。
927 ：デフォルトの名無しさん：2011/11/07(月) 17:24:43.79
>>926
みんな自分と同じだと思い込む認知バイアスの実例オツ
みんな自分と同じだと思い込む認知バイアスの実例オツ
928 ：デフォルトの名無しさん：2011/11/07(月) 17:39:54.22
>>927
いえいえ。バイアスかどうかなんとも言えんが、例外として忙しくても
このスレにきて書き込みをする人がいても不思議じゃない。だが、彼ら
の多くは時間を捨てるということにかなり敏感だよ。なぜならここは、
時間を捨てるようなものなので。俺も時間を捨ててるな。
いえいえ。バイアスかどうかなんとも言えんが、例外として忙しくても
このスレにきて書き込みをする人がいても不思議じゃない。だが、彼ら
の多くは時間を捨てるということにかなり敏感だよ。なぜならここは、
時間を捨てるようなものなので。俺も時間を捨ててるな。
929 ：デフォルトの名無しさん：2011/11/07(月) 17:49:18.90
>>927
所で、静的型言語のメリットとして、コンパイル時のエラーチェックを挙げる人が多いみたいだけど、工程の中でコンパイルエラー取りってそんなに大きい割合を占めるのか？
大規模化するほど、他の作業の比率が高くなってたけどな。
所で、静的型言語のメリットとして、コンパイル時のエラーチェックを挙げる人が多いみたいだけど、工程の中でコンパイルエラー取りってそんなに大きい割合を占めるのか？
大規模化するほど、他の作業の比率が高くなってたけどな。
930 ：デフォルトの名無しさん：2011/11/07(月) 18:04:27.67
>>929
大きな割合占めてたら困るだろw
大きな割合占めてたら困るだろw
931 ：デフォルトの名無しさん：2011/11/07(月) 18:05:08.73
>>929
関数型言語で型宣言せずに型推論でゴリゴリ書くと、
とんでもないスピードで時間が過ぎていくぞ。
型推論があれば型宣言しなくていいから楽チンなんて書いてるアフォがたまにいるが、
実用規模のコードを型推論ベースで書いたことがない奴と断言できる。
型宣言しても型変数つかうとやっぱり型エラーのバグ取りは簡単じゃない。
ただ、型推論と違って型変数の名前がデバッグのヒントになるからまだマシ。
関数型言語で型宣言せずに型推論でゴリゴリ書くと、
とんでもないスピードで時間が過ぎていくぞ。
型推論があれば型宣言しなくていいから楽チンなんて書いてるアフォがたまにいるが、
実用規模のコードを型推論ベースで書いたことがない奴と断言できる。
型宣言しても型変数つかうとやっぱり型エラーのバグ取りは簡単じゃない。
ただ、型推論と違って型変数の名前がデバッグのヒントになるからまだマシ。
932 ：デフォルトの名無しさん：2011/11/07(月) 18:17:57.18
>>930
他にメリットらしいものを挙げないから、余程コンパイルエラーで困ってるんだろう。
他にメリットらしいものを挙げないから、余程コンパイルエラーで困ってるんだろう。
933 ：デフォルトの名無しさん：2011/11/07(月) 18:29:28.02
934 ：デフォルトの名無しさん：2011/11/07(月) 18:34:00.42
935 ：デフォルトの名無しさん：2011/11/07(月) 18:42:41.22
そんなもん普通に型注釈を書いた場合も同じじゃん
ばっかじゃないの？
ばっかじゃないの？
936 ：デフォルトの名無しさん：2011/11/07(月) 18:45:16.05
937 ：デフォルトの名無しさん：2011/11/07(月) 18:52:34.83
>>932
お前アホだろ
お前アホだろ
938 ：デフォルトの名無しさん：2011/11/07(月) 19:49:08.50
コンパイラエラーレベルで苦労してるマネージャーは少なくないだろ。
メンバーがエキスパート揃いなら、そんな事は勿論無いだろうけど、それならそもそも動的・静的は無関係。
メンバーがエキスパート揃いなら、そんな事は勿論無いだろうけど、それならそもそも動的・静的は無関係。
939 ：デフォルトの名無しさん：2011/11/07(月) 20:04:33.45
面倒なコンパイルエラーもあるが、一般には一番対処しやすいエラーではあるだろ
実行時エラーは、少なくともそのパスを通さないと発覚しない
>>888のような問題は、テストによっては通ってしまう可能性さえある
静的型言語では、そうした問題（の少なくとも一部）を容易に早期発見できるようには
なる
実行時エラーは、少なくともそのパスを通さないと発覚しない
>>888のような問題は、テストによっては通ってしまう可能性さえある
静的型言語では、そうした問題（の少なくとも一部）を容易に早期発見できるようには
なる
940 ：デフォルトの名無しさん：2011/11/07(月) 20:06:59.90
C++でboostの奥深くで発生するコンパイルエラーのようなものの場合は
しばしばboostの実装（テンプレートとマクロの魔宮）を自分で見なければ
原因が判明しないことがあるな
しばしばboostの実装（テンプレートとマクロの魔宮）を自分で見なければ
原因が判明しないことがあるな
941 ：デフォルトの名無しさん：2011/11/07(月) 20:11:56.23
全てのバグをコンパイラに発見させるのは不可能としても
型で片付く程度の単純な問題を早期確実に発見することで
ダメージが少なくて済むのがポイントなので、
コンパイルエラー取りに時間がかからないから意味がないのでは？という指摘は
ちょっと的外れのような気がするな
型で片付く程度の単純な問題を早期確実に発見することで
ダメージが少なくて済むのがポイントなので、
コンパイルエラー取りに時間がかからないから意味がないのでは？という指摘は
ちょっと的外れのような気がするな
942 ：デフォルトの名無しさん：2011/11/07(月) 20:45:55.65
コンパイルエラー取り以外のメリットを提示しないから、他のフェーズではメリットないの？という流れ。
943 ：デフォルトの名無しさん：2011/11/07(月) 20:49:09.79
全てじゃないけど確実に発見するのがポイント
944 ：デフォルトの名無しさん：2011/11/07(月) 20:50:57.54
>>941
スレタイからしても、型を否定してる訳じゃないと思うが。
スレタイからしても、型を否定してる訳じゃないと思うが。
945 ：デフォルトの名無しさん：2011/11/07(月) 21:03:21.13
大規模開発で、コンパイルエラーの対処ワークは比率が小さいから、他のメリットを経験レベルでもいいから書きこめばいいんじゃないの？
因みにうちの場合は、データ構造とか基本ロジックを固めるまでは動的言語であれこれ試作してる。
人数が必要な工程では、動的言語使ったDSLでJavaとかCのソース生成。
アプリレベルの不整合有無のチェックは別のDSLでパース。
他所では事情が違うだろうけど今の所、動的・静的の一方だけで何でもやろうとするのは無謀、という判断。
因みにうちの場合は、データ構造とか基本ロジックを固めるまでは動的言語であれこれ試作してる。
人数が必要な工程では、動的言語使ったDSLでJavaとかCのソース生成。
アプリレベルの不整合有無のチェックは別のDSLでパース。
他所では事情が違うだろうけど今の所、動的・静的の一方だけで何でもやろうとするのは無謀、という判断。
946 ：デフォルトの名無しさん：2011/11/07(月) 22:58:36.12
やっぱり大規模になって一人で開発できるレベルを超えると
静的型付け言語のほうがいいって結論になってるな。
静的型付け言語のほうがいいって結論になってるな。
947 ：デフォルトの名無しさん：2011/11/07(月) 23:04:16.18
>>942
> コンパイルエラー取り以外のメリットを提示しないから、他のフェーズではメリットないの？という流れ。
コンパイルエラー以外のメリットですか？
メソッド名とか、その引数とか、ドキュメントを
リアルタイムで教えてくれる所。
コーディングしていて、えーとこの関数なんて名前にしよう？って
迷った時、とりあえず書いておいて、あとからじっくりいい名前に修正するってのが
関数名だけじゃなく、クラス名だったり、変数名だったり、いろいろ簡単に行えること。
設計がきっちり固まっていないとき、とりあえず書いておいて
あとからきちんと修正するのが楽ってところかな。
> コンパイルエラー取り以外のメリットを提示しないから、他のフェーズではメリットないの？という流れ。
コンパイルエラー以外のメリットですか？
メソッド名とか、その引数とか、ドキュメントを
リアルタイムで教えてくれる所。
コーディングしていて、えーとこの関数なんて名前にしよう？って
迷った時、とりあえず書いておいて、あとからじっくりいい名前に修正するってのが
関数名だけじゃなく、クラス名だったり、変数名だったり、いろいろ簡単に行えること。
設計がきっちり固まっていないとき、とりあえず書いておいて
あとからきちんと修正するのが楽ってところかな。
948 ：デフォルトの名無しさん：2011/11/07(月) 23:24:29.32
リファクタリングの一部だろ？
動的とか関係ないんじゃ？
動的とか関係ないんじゃ？
949 ：デフォルトの名無しさん：2011/11/07(月) 23:45:50.70
程度問題。静的型の方が参照しているクラスや呼び出したメソッドをレキシカルに
特定しやすいのは事実。
特定しやすいのは事実。
950 ：デフォルトの名無しさん：2011/11/08(火) 08:08:00.31
動的・静的の優劣なんぞを言い合っている間に、こんなものが。
http://www.eclipse.org/Xtext/
http://www.eclipse.org/Xtext/
951 ：デフォルトの名無しさん：2011/11/08(火) 10:35:27.31
IDEのリファクタリング機能がまともに機能するようなら、それは動的言語の言語機能を生かせてない
952 ：デフォルトの名無しさん：2011/11/08(火) 10:41:03.63
多相型の関数を作らなければいいって、自分一人で書いてるプログラムならそれで良いだろうけど、チームで開発してると他のプログラマーはリストを返すかスカラを返すか分からない関数を当たり前のように作る。
静的型付け言語の場合、それを防げる。
静的型付け言語の場合、それを防げる。
953 ：デフォルトの名無しさん：2011/11/08(火) 10:43:02.18
それはチームの問題だ
954 ：デフォルトの名無しさん：2011/11/08(火) 10:48:53.21
Twitter社で働いてるくらいの、おそくら高レベルなプログラマーでも大規模開発になった場合には型指定の不備が致命的だって。
http://www.artima.com/scalazine/articles/twitter_on_scala.html
Alex Payne: I’d definitely want to hammer home what Steve said about typing.
As our system has grown, a lot of the logic in our Ruby system sort of replicates a type system, either in our unit tests or as validations on models.
I think it may just be a property of large systems in dynamic languages, that eventually you end up rewriting your own type system, and you sort of do it badly.
You’re checking for null values all over the place.
There’s lots of calls to Ruby’s kind_of? method, which asks, “Is this a kind of User object? Because that’s what we’re expecting.
If we don’t get that, this is going to explode.”
It is a shame to have to write all that when there is a solution that has existed in the world of programming languages for decades now.
http://www.artima.com/scalazine/articles/twitter_on_scala.html
Alex Payne: I’d definitely want to hammer home what Steve said about typing.
As our system has grown, a lot of the logic in our Ruby system sort of replicates a type system, either in our unit tests or as validations on models.
I think it may just be a property of large systems in dynamic languages, that eventually you end up rewriting your own type system, and you sort of do it badly.
You’re checking for null values all over the place.
There’s lots of calls to Ruby’s kind_of? method, which asks, “Is this a kind of User object? Because that’s what we’re expecting.
If we don’t get that, this is going to explode.”
It is a shame to have to write all that when there is a solution that has existed in the world of programming languages for decades now.
955 ：デフォルトの名無しさん：2011/11/08(火) 11:00:31.26
だーかーらー、その話は>>897でもう終わってんの
どうしても単相型の関数を書きたきゃ
@typecheck
def f(x:int, y:int) -> int: return x + y
みたいなデコレータを定義して使えばいいだけの話
どうしても単相型の関数を書きたきゃ
@typecheck
def f(x:int, y:int) -> int: return x + y
みたいなデコレータを定義して使えばいいだけの話
956 ：デフォルトの名無しさん：2011/11/08(火) 11:04:54.34
動的・静的の使い分けの問題を、型指定不備の話にすり替えられても参考にならない。
静的型言語の評価を落とす為にわざとやってるんだろ？
静的型言語の評価を落とす為にわざとやってるんだろ？
957 ：デフォルトの名無しさん：2011/11/08(火) 11:18:17.30
>>955
つまり、引数や戻り値に型を指定するのが効率的ということだな。
つまり、引数や戻り値に型を指定するのが効率的ということだな。
958 ：デフォルトの名無しさん：2011/11/08(火) 11:18:58.96
>>952
動的の場合 わからなければすぐにREPLで関数をテストするのが鉄則だよ。
静的の感覚で動的を使えば、使いづらいのは当然だから、使うときにそれぞれ
の理にかなった方法でやっていくことをおすすめするな。要するに郷に入れば
郷に従えだ。それができない奴って、ソースを見ればすぐにわかる。
また、引数は方がわかるようにしておくのも普通に行われる。
動的の場合 わからなければすぐにREPLで関数をテストするのが鉄則だよ。
静的の感覚で動的を使えば、使いづらいのは当然だから、使うときにそれぞれ
の理にかなった方法でやっていくことをおすすめするな。要するに郷に入れば
郷に従えだ。それができない奴って、ソースを見ればすぐにわかる。
また、引数は方がわかるようにしておくのも普通に行われる。
959 ：デフォルトの名無しさん：2011/11/08(火) 11:22:39.88
960 ：デフォルトの名無しさん：2011/11/08(火) 11:27:29.92
田舎の田んぼのあぜ道に信号機は不要だろう。F1カーにウィンカーは不要だろう。
しかし、普通に交通量が多くて、F1レーサーのような運転スキルがない普通のドライバーが安全に運転しようと思えば、信号機もウィンカーも必須。
しかし、普通に交通量が多くて、F1レーサーのような運転スキルがない普通のドライバーが安全に運転しようと思えば、信号機もウィンカーも必須。
961 ：デフォルトの名無しさん：2011/11/08(火) 12:27:21.67
信号があってもなくても同じ車に乗れるから効率が良い。
ウィンカーも着脱可能にすれば修理しやすい。
故障しないから修理もしなくていいと想定すると理論上は非常に効率が良いんだが
想定が外れると非常に面倒なことになる。
ウィンカーも着脱可能にすれば修理しやすい。
故障しないから修理もしなくていいと想定すると理論上は非常に効率が良いんだが
想定が外れると非常に面倒なことになる。
962 ：デフォルトの名無しさん：2011/11/08(火) 13:57:44.98
残念だが、自分の車にウィンカーつけても、前の車にウィンカーがついてないんだよ。
車検があればそんなことはない。
車検があればそんなことはない。
963 ：デフォルトの名無しさん：2011/11/08(火) 14:07:51.28
喩え話で泥沼化の例がまた一つ
964 ：デフォルトの名無しさん：2011/11/08(火) 17:43:21.30
>>936
オレ、gofer, sml, Haskellと15年ほど関数型使ってきて、
仕事でも両手に余る数のコードを納品してきたが、
型推論での型デバッグはやりたくないね。
つうか、お前、関数型言語本当に使ってんのか？
オレ、gofer, sml, Haskellと15年ほど関数型使ってきて、
仕事でも両手に余る数のコードを納品してきたが、
型推論での型デバッグはやりたくないね。
つうか、お前、関数型言語本当に使ってんのか？
965 ：デフォルトの名無しさん：2011/11/08(火) 17:52:34.56
最悪なのが、hgやgitで複数人のコードをマージした時の
型宣言してないコードが絡んだ型エラー。
マジで涙が出てくるぞw
型宣言してないコードが絡んだ型エラー。
マジで涙が出てくるぞw
966 ：デフォルトの名無しさん：2011/11/08(火) 18:02:01.66
>>964
OCamlを使ってるけど、インクリメンタルビルドと型情報を表示できる
エディタの登場で状況が変わったよ
型注釈を書かないときに、実際ミスったところと遠い場所で
型エラーが出るとマジで気が遠くなるが、今は間違ったら直ぐ分かるから
そういうケースが無くなった
（自分の書いた関数の型をチェックしないとか言うなよ？）
あと、当然ながら.mliは書く（だから>>965の問題は杞憂）
OCamlを使ってるけど、インクリメンタルビルドと型情報を表示できる
エディタの登場で状況が変わったよ
型注釈を書かないときに、実際ミスったところと遠い場所で
型エラーが出るとマジで気が遠くなるが、今は間違ったら直ぐ分かるから
そういうケースが無くなった
（自分の書いた関数の型をチェックしないとか言うなよ？）
あと、当然ながら.mliは書く（だから>>965の問題は杞憂）
967 ：デフォルトの名無しさん：2011/11/08(火) 18:23:05.09
もちろん、実装は未定だけど型だけは決まってるときは
型だけ先に書いておいて中身はとりあえず assert false にしておく
こともあるけどね
型だけ先に書いておいて中身はとりあえず assert false にしておく
こともあるけどね
968 ：デフォルトの名無しさん：2011/11/08(火) 21:37:21.39
旧世代がIDEの進化に付いていけないみたいな話か
969 ：デフォルトの名無しさん：2011/11/08(火) 22:20:35.41
970 ：デフォルトの名無しさん：2011/11/08(火) 22:56:22.57
>>969
動的コンパイラ（=/ インタプリタ）も含まれる。
静的もREPLはインタプリタとして持ってる言語はあるけど、
静的のREPLは言語によって使い物にならんか、
使い勝手がいまいちなことが多いような印象があるな。
IDEは個人的には思考のリズムが合わないので余り好きで
はないな。CUIだけで操作ができるように覚えればいいん
だろうga。
>>966
よかったらOcamlでの開発の進め方を書いてみてよ。多分、ここの
多くの人は頭の中の言語としてしか知らないだろうし、俺もほとん
ど知らん。^^; 世の中にオカムラーが増えるかもな。
動的コンパイラ（=/ インタプリタ）も含まれる。
静的もREPLはインタプリタとして持ってる言語はあるけど、
静的のREPLは言語によって使い物にならんか、
使い勝手がいまいちなことが多いような印象があるな。
IDEは個人的には思考のリズムが合わないので余り好きで
はないな。CUIだけで操作ができるように覚えればいいん
だろうga。
>>966
よかったらOcamlでの開発の進め方を書いてみてよ。多分、ここの
多くの人は頭の中の言語としてしか知らないだろうし、俺もほとん
ど知らん。^^; 世の中にオカムラーが増えるかもな。
971 ：デフォルトの名無しさん：2011/11/08(火) 23:25:22.14
http://hibari.2ch.net/test/read.cgi/tech/1320743217/
次スレが立った。どうせおんなじようなネタになるしここでいいよ。
しかし、関数型に粘着アンチするのってどんな生き物なんだろうか？
次スレが立った。どうせおんなじようなネタになるしここでいいよ。
しかし、関数型に粘着アンチするのってどんな生き物なんだろうか？
972 ：デフォルトの名無しさん：2011/11/08(火) 23:46:14.27
Haskell 、QIをよく使うんでここを覗いてみたけど、関数型を否定してるレスあったっけ？
否定する理由を見てみたい。
否定する理由を見てみたい。
973 ：デフォルトの名無しさん：2011/11/09(水) 00:02:24.54
なんでこのスレタイで関数型の話になるんだ？
Java vs PHP みたいな話じゃねーの？
Java vs PHP みたいな話じゃねーの？
974 ：デフォルトの名無しさん：2011/11/09(水) 00:11:01.77
つか、IDEを単なるエディタとコマンド呼び出しツールとしか見ておらず、
開発のための道具だという認識が甘いんだよな。
IDEを使ったコーディングテクニックというものを知らない。
開発のための道具だという認識が甘いんだよな。
IDEを使ったコーディングテクニックというものを知らない。
975 ：デフォルトの名無しさん：2011/11/09(水) 00:20:43.51
Web 系の話ならロジックスカスカでテンプレートエンジンと O/R マッパー突っ込んで
画面数に比例する規模でひたすらゴリゴリ書くだけみたいなシステム
これは LOC がどうだろうと動的型付け言語の方が早い
裏側のバッチやらでロジックが複雑になってくると型が欲しくなる
画面数に比例する規模でひたすらゴリゴリ書くだけみたいなシステム
これは LOC がどうだろうと動的型付け言語の方が早い
裏側のバッチやらでロジックが複雑になってくると型が欲しくなる
976 ：デフォルトの名無しさん：2011/11/09(水) 00:39:04.02
977 ：デフォルトの名無しさん：2011/11/09(水) 00:47:05.93
>>970
関数を書く → セーブする → 裏で自動でコンパイルが走る → ここでエラーがあれば直す
→ エラーが無ければ関数の型を確認 → 型が予想と違えば直す → 最初に戻る
基本的に上のサイクルをリズムを崩さず書く（>>958が指摘するようにREPLも良く使う）
で、動くモジュールが出来たら、ocamlc -i で.mliファイルの雛形
（Cでいうところのヘッダーファイル。ソースファイルは.ml）を生成し、
これを修正して（例：非公開関数の型情報を消す）コメントを追加して完成
だから最終的には型情報付きのコードが出来上がる
なお、書くときはvim、コードを腰据えて読むときはEclipseを使ってる
（他人のコードを読むときのビジュアルデバッガの便利さはヤバい）
関数を書く → セーブする → 裏で自動でコンパイルが走る → ここでエラーがあれば直す
→ エラーが無ければ関数の型を確認 → 型が予想と違えば直す → 最初に戻る
基本的に上のサイクルをリズムを崩さず書く（>>958が指摘するようにREPLも良く使う）
で、動くモジュールが出来たら、ocamlc -i で.mliファイルの雛形
（Cでいうところのヘッダーファイル。ソースファイルは.ml）を生成し、
これを修正して（例：非公開関数の型情報を消す）コメントを追加して完成
だから最終的には型情報付きのコードが出来上がる
なお、書くときはvim、コードを腰据えて読むときはEclipseを使ってる
（他人のコードを読むときのビジュアルデバッガの便利さはヤバい）
978 ：デフォルトの名無しさん：2011/11/09(水) 01:11:01.24
IDE使わない人って、
他人が作った関数の戻り値・・・のオブジェクトが
どんなメソッドを持っているかってどうやって調べるの？
わざわざファイル探すの？
他人が作った関数の戻り値・・・のオブジェクトが
どんなメソッドを持っているかってどうやって調べるの？
わざわざファイル探すの？
979 ：デフォルトの名無しさん：2011/11/09(水) 05:11:53.34
980 ：デフォルトの名無しさん：2011/11/09(水) 06:52:22.06
>>978
IDEを使う人って、他人が作る部分が完成するまで自分は何もせず待機してるの？
IDEを使う人って、他人が作る部分が完成するまで自分は何もせず待機してるの？
981 ：デフォルトの名無しさん：2011/11/09(水) 08:41:06.58
>>979
あー、やっぱりだｗ
他人が作った関数戻り値ってのは、
そんなドキュメントがちゃんと用意されてるものじゃなくて
開発中で仕様が固まってるわけでもないやつとか
プライベートメソッドとか、そいういうちゃんと準備されたものじゃないもののことだよ。
えと、それなりの人数で開発していれば、普通にある話だよね？
どうもIDE使ってない人って、自分以外はすべて公開された汎用ライブラリって
小さなプロジェクトしかやってないと思っていたが、その通りのレスを有難うｗ
>>980
んなもんスタブでも作ればいいだけじゃんｗ
あー、やっぱりだｗ
他人が作った関数戻り値ってのは、
そんなドキュメントがちゃんと用意されてるものじゃなくて
開発中で仕様が固まってるわけでもないやつとか
プライベートメソッドとか、そいういうちゃんと準備されたものじゃないもののことだよ。
えと、それなりの人数で開発していれば、普通にある話だよね？
どうもIDE使ってない人って、自分以外はすべて公開された汎用ライブラリって
小さなプロジェクトしかやってないと思っていたが、その通りのレスを有難うｗ
>>980
んなもんスタブでも作ればいいだけじゃんｗ
982 ：デフォルトの名無しさん：2011/11/09(水) 10:21:00.09
このくらいしかIDEを自慢できないことが悲しいね。
983 ：デフォルトの名無しさん：2011/11/09(水) 10:28:40.36
動的言語の戻り値型推論とか想像するだけで大変そう
984 ：デフォルトの名無しさん：2011/11/09(水) 10:40:37.29
動的の場合は、わからなかったら、REPLでソースを見るということが
可能な言語がいくつかあるよ。全てではないけど、強力なREPLをもってる
と楽なんだよな。
可能な言語がいくつかあるよ。全てではないけど、強力なREPLをもってる
と楽なんだよな。
985 ：デフォルトの名無しさん：2011/11/09(水) 10:56:44.76
戻り値のオブジェクトが持つプライベートメソッドが
分かったとして、それを何に使うの？
分かったとして、それを何に使うの？
986 ：デフォルトの名無しさん：2011/11/09(水) 11:04:07.87
>>977
TX! Ocamlでもeclipsが使えるんだ。知らなかった。関数型とvimってよくある
よね。機動力があるからかな。scakaでも本掲載とのアンケート結果を見ると
vim人気高いみたいだし。
haskellのほうはghciから:eはデフォルトでvimになってるな。
TX! Ocamlでもeclipsが使えるんだ。知らなかった。関数型とvimってよくある
よね。機動力があるからかな。scakaでも本掲載とのアンケート結果を見ると
vim人気高いみたいだし。
haskellのほうはghciから:eはデフォルトでvimになってるな。
>>981
>えと、それなりの人数で開発していれば、普通にある話だよね？
ンっ、>>981の世界ではそれが普通なの？
少なくとも自分が過去に関わったプロジェクトでは、
(言語とは無関係に)コンポーネントの公開インターフェイスや
共通で使用される(=内部ライブラリである)モジュール/クラスは、
あらかじめ(暫定案でもいいから)固めて文書化しておくのが普通(常識)
そうしないとコンポーネントごと複数人数で分担する、あるいは
複数の会社で開発を分担して最終的に統合してプロダクトとするような
規模のプロジェクトでは、仕様変更に伴う大混乱が「間違いなく」発生する
それとも最近のIDEというのは、この辺りの仕様変更まで自動的に追従してくれるのかな？
>えと、それなりの人数で開発していれば、普通にある話だよね？
ンっ、>>981の世界ではそれが普通なの？
少なくとも自分が過去に関わったプロジェクトでは、
(言語とは無関係に)コンポーネントの公開インターフェイスや
共通で使用される(=内部ライブラリである)モジュール/クラスは、
あらかじめ(暫定案でもいいから)固めて文書化しておくのが普通(常識)
そうしないとコンポーネントごと複数人数で分担する、あるいは
複数の会社で開発を分担して最終的に統合してプロダクトとするような
規模のプロジェクトでは、仕様変更に伴う大混乱が「間違いなく」発生する
それとも最近のIDEというのは、この辺りの仕様変更まで自動的に追従してくれるのかな？
988 ：デフォルトの名無しさん：2011/11/09(水) 11:42:04.94
>>981で結論出てるな。
大人数での開発では静的型付け言語の方が安定感がある。
大規模開発では平均スキルレベルの維持が難しい(全員がエキスパートじゃコストがえらいことに！)から、初心者レベルの単純ミスを指摘してくれる機能は外せない。
尤も、顧客要求は開発規模(人月、予算、コード量)スリム化、でも機能盛りだくさんの方向だから悩ましい。
大人数での開発では静的型付け言語の方が安定感がある。
大規模開発では平均スキルレベルの維持が難しい(全員がエキスパートじゃコストがえらいことに！)から、初心者レベルの単純ミスを指摘してくれる機能は外せない。
尤も、顧客要求は開発規模(人月、予算、コード量)スリム化、でも機能盛りだくさんの方向だから悩ましい。
989 ：デフォルトの名無しさん：2011/11/09(水) 15:15:40.99
低レベルのを人手と思うのが幻想だな
むしろマイナスでござる
むしろマイナスでござる
990 ：デフォルトの名無しさん：2011/11/09(水) 15:50:15.39
日本語で。
>>988
>>>981で結論出てるな。
意味不明だ
このスレで言うIDEとは、Eclipse/VisualStudio/XCode/Emacsあたりを指していると思うけど、
これらはどれも個人レベルのコード生産性を向上するのに役立つツールかもしれない
しかし、数十人以上の不均質な体制が組まれる現実の大規模開発プロジェクトにとっては
評価の対象とはならない（IDEと開発規模とは無関係）
# 評価対象にならないというだけで、IDEそのものを批判している訳ではないので誤解せぬよう
# IDEを使う/使わないは個人レベル、あるいはプロジェクト単位で判断すればいい
>>978,981,988 の主張は、現実の大規模開発を経験したことの無いド素人の発想でしかない
>>>981で結論出てるな。
意味不明だ
このスレで言うIDEとは、Eclipse/VisualStudio/XCode/Emacsあたりを指していると思うけど、
これらはどれも個人レベルのコード生産性を向上するのに役立つツールかもしれない
しかし、数十人以上の不均質な体制が組まれる現実の大規模開発プロジェクトにとっては
評価の対象とはならない（IDEと開発規模とは無関係）
# 評価対象にならないというだけで、IDEそのものを批判している訳ではないので誤解せぬよう
# IDEを使う/使わないは個人レベル、あるいはプロジェクト単位で判断すればいい
>>978,981,988 の主張は、現実の大規模開発を経験したことの無いド素人の発想でしかない
>>991
ああ、言葉足らずだった、すまん。
981の前半についてのコメントだった。
IDE使用有無との関連は、ここでは考えていない。
言いたかったのは、コスト・スキルバランスを考えると、要員の単純ミスが無視できないから、静的チェックが欠かせない、って事。
それはスキルの問題だろと言われればそれまでなんだが、誰かも書いていたように、エキスパート揃いだったらそもそも、動的・静的のどっちで統一するかなんて問題は小さくなるしな。
ああ、言葉足らずだった、すまん。
981の前半についてのコメントだった。
IDE使用有無との関連は、ここでは考えていない。
言いたかったのは、コスト・スキルバランスを考えると、要員の単純ミスが無視できないから、静的チェックが欠かせない、って事。
それはスキルの問題だろと言われればそれまでなんだが、誰かも書いていたように、エキスパート揃いだったらそもそも、動的・静的のどっちで統一するかなんて問題は小さくなるしな。
993 ：デフォルトの名無しさん：2011/11/09(水) 16:27:22.32
単純なミスはスキル不足だけでは起こらないからな。疲労の蓄積etc.による
集中力の欠如は大敵だわ。ケアレスミスは誰だって起こるしなぁ。
集中力の欠如は大敵だわ。ケアレスミスは誰だって起こるしなぁ。
994 ：デフォルトの名無しさん：2011/11/09(水) 16:33:35.16
前スレで書いた
型はコード解析しやすくするために必要
コード解析しやすくなると開発ツールの実装が楽になる
IDEの機能はデフォで充実、自分で拡張したり新規に作るのも楽
充実した開発環境は開発効率を向上させる
誰も反論しないから定理として扱っていいと思ったのに
いまさら反論されても困る
型はコード解析しやすくするために必要
コード解析しやすくなると開発ツールの実装が楽になる
IDEの機能はデフォで充実、自分で拡張したり新規に作るのも楽
充実した開発環境は開発効率を向上させる
誰も反論しないから定理として扱っていいと思ったのに
いまさら反論されても困る
995 ：デフォルトの名無しさん：2011/11/09(水) 17:03:16.54
カーソルの箇所から
必要なリファレンスを自動的に表示したり
単体で実行したり
その辺りまでやるべきだよな
ホットキーすらも押す必要がない
カーソル位置から解析できる全ての情報がそこに表示されるべき
そのために解析範囲を大きくしてはならない
解析範囲を小さくしてもそのブロックに意味がなければならない
言語仕様は開発ツールの動作を妨げてはならない
こう考えたから
型は必須でなければならないという結論になった
動的静的なんてクソどうでもいい差
必要なリファレンスを自動的に表示したり
単体で実行したり
その辺りまでやるべきだよな
ホットキーすらも押す必要がない
カーソル位置から解析できる全ての情報がそこに表示されるべき
そのために解析範囲を大きくしてはならない
解析範囲を小さくしてもそのブロックに意味がなければならない
言語仕様は開発ツールの動作を妨げてはならない
こう考えたから
型は必須でなければならないという結論になった
動的静的なんてクソどうでもいい差
>>992
了解
>>994
だから、個人レベルの戦闘能力を高める武器としてのIDEを否定/反論する気は全く無い
指摘したのは、
・IDEと開発規模とは無関係であり、
・IDEは大規模開発に関わる問題を解決するツールでは無く、
・>>981はド素人
だということ
了解
>>994
だから、個人レベルの戦闘能力を高める武器としてのIDEを否定/反論する気は全く無い
指摘したのは、
・IDEと開発規模とは無関係であり、
・IDEは大規模開発に関わる問題を解決するツールでは無く、
・>>981はド素人
だということ
997 ：デフォルトの名無しさん：2011/11/09(水) 17:22:25.56
うるさいだまれ
知性の欠片もなく
経験や立場を自慢して主観を押し付けてレッテル貼って
それで他人と肩を並べたつもりになってるくずめ
おまえなんてあばばばば
知性の欠片もなく
経験や立場を自慢して主観を押し付けてレッテル貼って
それで他人と肩を並べたつもりになってるくずめ
おまえなんてあばばばば
998 ：デフォルトの名無しさん：2011/11/09(水) 17:29:33.14
そんなに全てを静的に決めたいならsubtype polymorphismも含めて
全ての多相性を禁止にしろよ
どのメソッドが呼ばれるか静的に決まるぞ
全ての多相性を禁止にしろよ
どのメソッドが呼ばれるか静的に決まるぞ
999 ：デフォルトの名無しさん：2011/11/09(水) 17:41:05.08
あらゆる多相性を撤廃し、高階関数も無くし、副作用も禁止すれば
静的解析しやすくIDEが作りやすい言語になるだろうが、そんな言語使いたくねぇw
静的解析しやすくIDEが作りやすい言語になるだろうが、そんな言語使いたくねぇw
1000 ：デフォルトの名無しさん：2011/11/09(水) 17:48:43.28
VHDLがそんな感じじゃね？
1001 ：１００１：
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
もう書けないので、新しいスレッドを立ててくださいです。。。