1 :デフォルトの名無しさん2011/10/22(土) 01:01:12.94
まあいろんなところで証明済みなんだが、
反論したいなら語れや。
やっぱり動的型付け言語では安全なソフトは作れない
http://hibari.2ch.net/test/read.cgi/tech/1316887046/
反論したいなら語れや。
やっぱり動的型付け言語では安全なソフトは作れない
http://hibari.2ch.net/test/read.cgi/tech/1316887046/
2 :デフォルトの名無しさん2011/10/22(土) 01:56:23.56
大規模開発の効率はプログラミング言語の選択なんかよりもはるかに上流で決まる
4 :デフォルトの名無しさん2011/10/22(土) 07:39:45.81
Dartが本当に静的型言語を目指しているなら、
最初からJavascriptベースになんかするかよw
基本は動的型付で、APIでは型アノテーションつけたり、
下周りのライブラリで型を決め打ちしても実害が少ないところを
型をつけてチューニング可能、というだけ。
Dartが静的型ベースなら、型宣言を必須にした上で、
静的型を付けたくないところをany型とかにするだろ。
最初からJavascriptベースになんかするかよw
基本は動的型付で、APIでは型アノテーションつけたり、
下周りのライブラリで型を決め打ちしても実害が少ないところを
型をつけてチューニング可能、というだけ。
Dartが静的型ベースなら、型宣言を必須にした上で、
静的型を付けたくないところをany型とかにするだろ。
8 :デフォルトの名無しさん2011/10/22(土) 09:46:11.30
>>4
Javascriptベース……?
開幕からいきなり何言ってんだこいつ
Javascriptベース……?
開幕からいきなり何言ってんだこいつ
5 :デフォルトの名無しさん2011/10/22(土) 07:44:38.00
土方は英語が読めないから、Dartの仕様やドキュメントを読めません
日本語の解説記事だけ読んで「型注釈あり=静的型付け」と短絡的に考えてます
日本語の解説記事だけ読んで「型注釈あり=静的型付け」と短絡的に考えてます
7 :デフォルトの名無しさん2011/10/22(土) 08:10:19.10
安全性のための銀の弾丸ではないことを
やっと理解したということだな
で、今度は大規模開発の銀の弾丸かw
やっと理解したということだな
で、今度は大規模開発の銀の弾丸かw
9 :デフォルトの名無しさん2011/10/22(土) 09:58:07.42
前スレのリンクにゃ
しっかりdartは動的型付と書いてあるがな
型アノテーションは単に
人や機械へのヒントだと
しっかりdartは動的型付と書いてあるがな
型アノテーションは単に
人や機械へのヒントだと
10 :デフォルトの名無しさん2011/10/22(土) 10:07:36.14
>>9
Dartで作ったものをJSに変換する都合上、動的型付けでも動くようにしてるだけだろうが…
Dartで作ったものをJSに変換する都合上、動的型付けでも動くようにしてるだけだろうが…
11 :デフォルトの名無しさん2011/10/22(土) 10:10:52.58
もしかしたら、Dartで作ったものをjavascriptへトランスレートして動かすことを「Javascriptベース」と呼んでるのかもしれん
12 :デフォルトの名無しさん2011/10/22(土) 10:15:30.23
Dartは動的も静的も受け付けるんだから、なかよく使えよw
動的だと人や機械へのヒントすら(まともに)できなかったから、Dartは作られたわけで
静的屋としてはありがたいよ
動的だと人や機械へのヒントすら(まともに)できなかったから、Dartは作られたわけで
静的屋としてはありがたいよ
13 :デフォルトの名無しさん2011/10/22(土) 10:40:13.46
あれを静的型付けと呼ぶのは、本当の静的型付言語への侮辱だろw
14 :デフォルトの名無しさん2011/10/22(土) 10:56:06.59
>>13
なんで?
JSがブラウザを占拠している以上、それにあわせて普及を目指すのは当然の戦略だが?
非常に頭の良い折衷案だろ、あれは
「完全な静的型付け言語としても利用でき、普及されきっているJSへの変換もサポートし、JS同様の動的型付け言語もできる」
静的erにとって最高の対応じゃん
なんで?
JSがブラウザを占拠している以上、それにあわせて普及を目指すのは当然の戦略だが?
非常に頭の良い折衷案だろ、あれは
「完全な静的型付け言語としても利用でき、普及されきっているJSへの変換もサポートし、JS同様の動的型付け言語もできる」
静的erにとって最高の対応じゃん
16 :デフォルトの名無しさん2011/10/22(土) 11:24:54.39
>>13
侮辱って…静的ってそこまで高尚なものでも無いと思うんだがなあ
ただの考え方の違いでしかないんだが
侮辱って…静的ってそこまで高尚なものでも無いと思うんだがなあ
ただの考え方の違いでしかないんだが
15 :デフォルトの名無しさん2011/10/22(土) 11:20:07.67
少なくともDartのVMはJavaScriptと同じような動的型付け言語ベースのものだよね。
静的型付け言語的な機能をもった構文パーサで構文解析。
その結果を、動的型付け言語に変換したり、動的型付け言語ベースのVMで実行する。
こんな感じかね?
静的型付け言語的な機能をもった構文パーサで構文解析。
その結果を、動的型付け言語に変換したり、動的型付け言語ベースのVMで実行する。
こんな感じかね?
18 :デフォルトの名無しさん2011/10/22(土) 11:35:01.53
>>15
単にDartのVMが普及してないからJSエンジンの上で動かすようにしてるだけだろがw
単にDartのVMが普及してないからJSエンジンの上で動かすようにしてるだけだろがw
17 :デフォルトの名無しさん2011/10/22(土) 11:25:21.60
VMに動的も静的もないだろw
VMはマシンだ。機械語だ。
機械語に動的とか静的があるか。
単純な命令をたんたんと実行してるだけ。
VMはマシンだ。機械語だ。
機械語に動的とか静的があるか。
単純な命令をたんたんと実行してるだけ。
19 :デフォルトの名無しさん2011/10/22(土) 11:51:44.17
あれ?DartのVMって、JavaVMみたいに、プログラムを中間言語に変換したものを実行するの?
最近のJavaScriptのJITコンパイラみたいなものを想像してたんだけど。
ドキュメントにもDartのVMはDartのコードをダイレクトに実行するとか書いてあったし。
最近のJavaScriptのJITコンパイラみたいなものを想像してたんだけど。
ドキュメントにもDartのVMはDartのコードをダイレクトに実行するとか書いてあったし。
20 :デフォルトの名無しさん2011/10/22(土) 11:57:25.00
>>19
JavaVMはJITコンパイルしてますよ。
なにが言いたいか理解できますか?
JavaVMはJITコンパイルしてますよ。
なにが言いたいか理解できますか?
21 :デフォルトの名無しさん2011/10/22(土) 12:01:11.64
>>20
JavaVMのJITコンパイラと、
V8みたいなJavaScriptのJITコンパイラの動作の違いは理解できてる?
JavaVMのJITコンパイラと、
V8みたいなJavaScriptのJITコンパイラの動作の違いは理解できてる?
22 :デフォルトの名無しさん2011/10/22(土) 12:06:53.11
相手の知識量を馬鹿にするんじゃなくて、自分が持ち上げたいものを馬鹿でも分かるように説明するためにレスしろよw
26 :デフォルトの名無しさん2011/10/22(土) 12:10:20.72
JavaScriptの場合、JITコンパイラは、
最初は変数の型とかが確定できないから変数の参照更新なんかを動的型付けに対応した処理に変換する。
そして、実際に実行してみて変数が特定の型でしか参照更新されないと判断したら、
それを静的型付けにのみに対応した処理に置き換えて高速化するよね。
DartのVM?JITコンパイラ?も同じようなことをやると思うんだけど、
型情報がプログラムに記述されてる場合には、最初から静的型付けにのみに対応した処理に変換することで、
より効率的に処理できる。Dartの型情報ってのは実行時にはこんな感じに使われると思ったんだけど違うのかな。
最初は変数の型とかが確定できないから変数の参照更新なんかを動的型付けに対応した処理に変換する。
そして、実際に実行してみて変数が特定の型でしか参照更新されないと判断したら、
それを静的型付けにのみに対応した処理に置き換えて高速化するよね。
DartのVM?JITコンパイラ?も同じようなことをやると思うんだけど、
型情報がプログラムに記述されてる場合には、最初から静的型付けにのみに対応した処理に変換することで、
より効率的に処理できる。Dartの型情報ってのは実行時にはこんな感じに使われると思ったんだけど違うのかな。
28 :デフォルトの名無しさん2011/10/22(土) 12:13:52.78
>>26みたいなことをやると想像してたので、
DartのVMが動的型付け言語ベースと書いたんだけど、どうなんだろ?
DartのVMが動的型付け言語ベースと書いたんだけど、どうなんだろ?
135 :デフォルトの名無しさん2011/10/22(土) 21:22:32.09
>>129
確かにこれじゃ実行時には何の役にも立たないね。
>>26で言ってるような最適化も絵に描いた餅だ。
確かにこれじゃ実行時には何の役にも立たないね。
>>26で言ってるような最適化も絵に描いた餅だ。
27 :デフォルトの名無しさん2011/10/22(土) 12:13:00.15
言語の話から、なんでVMの話に話が逸れてるのか意味フなんだが
30 :デフォルトの名無しさん2011/10/22(土) 12:27:36.17
その昔、C++はCにトランスレートされてコンパイルされていた
それを指して「C++よりCの方が優れている」と言ってよいものかどうか・・??
それを指して「C++よりCの方が優れている」と言ってよいものかどうか・・??
31 :デフォルトの名無しさん2011/10/22(土) 12:48:47.76
実装をまったく考慮せずに、文法だけで判断するならば、
型をオプションで記述できる動的型付け言語と、
型が省略可能(推論もされず実行時に決定)な静的型付け言語を、
区別するものは何なんだろうね。
型をオプションで記述できる動的型付け言語と、
型が省略可能(推論もされず実行時に決定)な静的型付け言語を、
区別するものは何なんだろうね。
32 :デフォルトの名無しさん2011/10/22(土) 13:02:56.88
>>31
区別する必要あるのか?
どっちも同じじゃん
残念なのは、現在の動的型付け言語は、「完全な静的型付け」として利用するオプションを持っていないってことだろ
だからDartが作られた
区別する必要あるのか?
どっちも同じじゃん
残念なのは、現在の動的型付け言語は、「完全な静的型付け」として利用するオプションを持っていないってことだろ
だからDartが作られた
33 :デフォルトの名無しさん2011/10/22(土) 13:12:40.35
やっぱり動的型付け厨にとっては、静的型付けの盛り返しが気にくわないのかな?
37 :デフォルトの名無しさん2011/10/22(土) 13:29:00.91
>>33
静的動的なんて考え方の違いでしかないのに
静的厨が何故か動的を下として見るからな、気に食わないとしたらそこだけだ
別に盛り返してるとも、上だとも下だとも思ってないよ
静的動的なんて考え方の違いでしかないのに
静的厨が何故か動的を下として見るからな、気に食わないとしたらそこだけだ
別に盛り返してるとも、上だとも下だとも思ってないよ
35 :デフォルトの名無しさん2011/10/22(土) 13:26:45.25
なぜ対人論証に持っていこうとするのか
粛々と説得材料書けば済むだけのことだろ
粛々と説得材料書けば済むだけのことだろ
36 :デフォルトの名無しさん2011/10/22(土) 13:28:50.04
別に型注釈だろうが、型宣言だろう、静的型付けだろうが、なんでもかまわん
欲しいのはコンパイル時に問題を検出できる能力だ
言葉遊びはイランよ
欲しいのはコンパイル時に問題を検出できる能力だ
言葉遊びはイランよ
38 :デフォルトの名無しさん2011/10/22(土) 13:31:25.17
型注釈と静的型の違いは前スレにも何度も書かれていたが?
それを読みもせずに「動的型から静的型への移行は不可能だから」とかいう
ググルのアナウンスと真っ向から相反する噴飯モノのトーシロ発言をご開陳しているのが
静的廚だということぐらい、本人以外はみーんなわかってる罠
それを読みもせずに「動的型から静的型への移行は不可能だから」とかいう
ググルのアナウンスと真っ向から相反する噴飯モノのトーシロ発言をご開陳しているのが
静的廚だということぐらい、本人以外はみーんなわかってる罠
39 :デフォルトの名無しさん2011/10/22(土) 13:34:46.54
>>38
え?お前何いっちゃってるの?
誰が動的型から静的型への移行は不可能とか言っちゃってるの?脳内仮想敵?
別に静的への移行が可能な動的型言語が普及しているなら、それに乗ればいいだけじゃん
で、何か1つ例あげてよ
え?お前何いっちゃってるの?
誰が動的型から静的型への移行は不可能とか言っちゃってるの?脳内仮想敵?
別に静的への移行が可能な動的型言語が普及しているなら、それに乗ればいいだけじゃん
で、何か1つ例あげてよ
40 :デフォルトの名無しさん2011/10/22(土) 13:38:22.55
静的型付け言語から動的型付け言語にするのは
単に型情報を取り除くだけでいいけど、
動的型付け言語に、静的型付け言語の機能を加えようとしたら、
それは全くの別言語になってしまう。
単に型情報を取り除くだけでいいけど、
動的型付け言語に、静的型付け言語の機能を加えようとしたら、
それは全くの別言語になってしまう。
42 :デフォルトの名無しさん2011/10/22(土) 13:40:50.32
静的型付け言語といっても、どの言語もたいていobject型という
型を無視する型があるからね。
それにキャストすることで型を無視する機能は、
静的型付け言語にもともと付いているわけだ。
まあ、デメリットしか無いから特に理由がない限り使わないが。
型を無視する型があるからね。
それにキャストすることで型を無視する機能は、
静的型付け言語にもともと付いているわけだ。
まあ、デメリットしか無いから特に理由がない限り使わないが。
51 :デフォルトの名無しさん2011/10/22(土) 14:28:00.41
>>42
templateとかリフレクションならまだしも
それは結局型を知らないとメソッドも呼べない時点で静的型付けそのもの
動的型付けと比較できる機能じゃない
templateとかリフレクションならまだしも
それは結局型を知らないとメソッドも呼べない時点で静的型付けそのもの
動的型付けと比較できる機能じゃない
43 :デフォルトの名無しさん2011/10/22(土) 13:43:18.54
動的型付けと多相型の区別すらつかないカスが現われた
どうする?
1. 無視する
2. 笑う
3. ひとまず同調してもっと大きな笑いを引き出す
どうする?
1. 無視する
2. 笑う
3. ひとまず同調してもっと大きな笑いを引き出す
47 :デフォルトの名無しさん2011/10/22(土) 14:07:33.00
え、誰も「静的への移行が可能な動的型言語」の具体例1つもあげられないの・・・?
おいおい
おいおい
52 :デフォルトの名無しさん2011/10/22(土) 14:32:17.03
>>47
後で移行できるなら、最初は小規模でいいし追加分も少しずつでいいことになる
それでは大規模の価値がなくなってしまう
そこで、小規模から大規模に移行したり動的から静的に移行することは不可能
というルールを叩き込むことで大規模の価値を守ろうという流れになる
後で移行できるなら、最初は小規模でいいし追加分も少しずつでいいことになる
それでは大規模の価値がなくなってしまう
そこで、小規模から大規模に移行したり動的から静的に移行することは不可能
というルールを叩き込むことで大規模の価値を守ろうという流れになる
54 :デフォルトの名無しさん2011/10/22(土) 14:36:28.16
>>52
レス番間違えてないか?
「静的への移行」ってのは、プロジェクトを移行することじゃないぞ?
レス番間違えてないか?
「静的への移行」ってのは、プロジェクトを移行することじゃないぞ?
70 :デフォルトの名無しさん2011/10/22(土) 16:01:29.38
>>38
>>39,47
>>52
>>54
>>39,47
>>52
>>54
48 :デフォルトの名無しさん2011/10/22(土) 14:10:02.41
動的型言語のほうが柔軟だからなあ、それを静的に落とし込むのは動的型言語のほうでどうこうしても仕方ないよ
50 :デフォルトの名無しさん2011/10/22(土) 14:19:03.71
>>48
> 動的型言語のほうが柔軟だからなあ、それを静的に落とし込むのは動的型言語のほうでどうこうしても仕方ないよ
柔軟と言うか、たんに無秩序ってだけだな。
たとえばgotoは柔軟だ。
だがその柔軟さ故に悪いものと認識された。
> 動的型言語のほうが柔軟だからなあ、それを静的に落とし込むのは動的型言語のほうでどうこうしても仕方ないよ
柔軟と言うか、たんに無秩序ってだけだな。
たとえばgotoは柔軟だ。
だがその柔軟さ故に悪いものと認識された。
49 :デフォルトの名無しさん2011/10/22(土) 14:12:08.96
動的型付け言語のほうが、色々できて、パワフルで、柔軟なのは認める。まったくもってその通り。
でも俺が欲しいのは、意図的に制約をかけることができる言語なんだ
いうなれば、安全装置のついた武器が欲しい。
安全装置がついてない武器を、まだ未熟な新人たちに渡したくないんだ
でも俺が欲しいのは、意図的に制約をかけることができる言語なんだ
いうなれば、安全装置のついた武器が欲しい。
安全装置がついてない武器を、まだ未熟な新人たちに渡したくないんだ
53 :デフォルトの名無しさん2011/10/22(土) 14:33:47.82
まあリフレクションでダックタイピングは普通に実現できるわな
C#のdynamic型も実装はリフレクションだったと思う
C++ならテンプレートと継承のあわせ技でtype erasureを行う
C#のdynamic型も実装はリフレクションだったと思う
C++ならテンプレートと継承のあわせ技でtype erasureを行う
55 :デフォルトの名無しさん2011/10/22(土) 14:39:33.27
もともともっときつい制限がかかっていたのだから
静的型付けに動的型付けの機能をいれこむのは
そんなに難しいことではない。
今までダメだったことを、認めればいいだけだけ。
もちろん以前の書き方も通用するから段階的に変更していける。
しかしもともとが緩かったら、そこに制限のある型を
導入すると、全体のコードがそれに引きづられてしまう。
今までできていたことができなくなる。
できなくなるから静的型付け用に書き換える。
そうすると、それに依存している部分を書き換えなくてはならなくなる。
そして、さらにそれに依存している部分を・・・と続く。
静的型付けに動的型付けの機能をいれこむのは
そんなに難しいことではない。
今までダメだったことを、認めればいいだけだけ。
もちろん以前の書き方も通用するから段階的に変更していける。
しかしもともとが緩かったら、そこに制限のある型を
導入すると、全体のコードがそれに引きづられてしまう。
今までできていたことができなくなる。
できなくなるから静的型付け用に書き換える。
そうすると、それに依存している部分を書き換えなくてはならなくなる。
そして、さらにそれに依存している部分を・・・と続く。
56 :デフォルトの名無しさん2011/10/22(土) 14:48:42.30
で、静的型付けをしっかりサポートしている動的型付け言語の具体例とやらはまだか?
是非とも使いたいんだ。頼む
是非とも使いたいんだ。頼む
57 :デフォルトの名無しさん2011/10/22(土) 15:10:32.85
>>56
そもそも、それがあったとして
それは動的型付けに分類できるのか?
まあ、静的型付けに分類するのも難しいのかも知れないが
そもそも、それがあったとして
それは動的型付けに分類できるのか?
まあ、静的型付けに分類するのも難しいのかも知れないが
58 :デフォルトの名無しさん2011/10/22(土) 15:20:16.08
class Class1 {
int func() {
return 10;
}
}
class Class2 {
String func() {
return "20";
}
}
func(Class1 hoge) {
print(hoge.func());
}
main() {
func(new Class1());
func(new Class2());
}
これでwarningが出るだけだから>>56の言う感じに近いのでは
funcの引数をvarにすればWarningも出なくなるし
int func() {
return 10;
}
}
class Class2 {
String func() {
return "20";
}
}
func(Class1 hoge) {
print(hoge.func());
}
main() {
func(new Class1());
func(new Class2());
}
これでwarningが出るだけだから>>56の言う感じに近いのでは
funcの引数をvarにすればWarningも出なくなるし
59 :デフォルトの名無しさん2011/10/22(土) 15:24:52.04
warningの内容は?
61 :582011/10/22(土) 15:29:10.62
忘れてた。>>58の言語はDart
>>59
Class2 is not assignable to Class1
>>59
Class2 is not assignable to Class1
62 :デフォルトの名無しさん2011/10/22(土) 15:31:25.60
>>61
静的厨が、Dartが静的にも完全対応してて素晴らしいって言ってたら
動的厨が「そんなもんすでにある」というようなことを言ってきたので「具体例1つあげろよ」ってなったんだが…
静的厨が、Dartが静的にも完全対応してて素晴らしいって言ってたら
動的厨が「そんなもんすでにある」というようなことを言ってきたので「具体例1つあげろよ」ってなったんだが…
63 :デフォルトの名無しさん2011/10/22(土) 15:35:09.92
>>62
「Dartが静的にも完全対応してて素晴らしい」というのに反論してだけなのに、
なぜか動的厨扱いされてるでござる
「Dartが静的にも完全対応してて素晴らしい」というのに反論してだけなのに、
なぜか動的厨扱いされてるでござる
64 :デフォルトの名無しさん2011/10/22(土) 15:36:29.47
>>63
お前のレスどれだよ58だろ?
なんで「Dart以外にあんの?」って聞いてるレスに対して、Dartのコード貼ってんだよ
お前のレスどれだよ58だろ?
なんで「Dart以外にあんの?」って聞いてるレスに対して、Dartのコード貼ってんだよ
69 :582011/10/22(土) 15:56:43.84
>>64
いや違うよ
そもそも「Dart以外にあんの?」っていう流れがどこか解らん
いや違うよ
そもそも「Dart以外にあんの?」っていう流れがどこか解らん
71 :デフォルトの名無しさん2011/10/22(土) 17:26:51.28
>>69
> そもそも「Dart以外にあんの?」っていう流れがどこか解らん
pythonやStrongtalkすら知らないアホ>>64の脳内流れ
> そもそも「Dart以外にあんの?」っていう流れがどこか解らん
pythonやStrongtalkすら知らないアホ>>64の脳内流れ
96 :デフォルトの名無しさん2011/10/22(土) 20:06:47.15
>>71
知らない言語があるだけでアホ呼ばわりされるとは不条理だなぁ・・・
python調べてみたんだが、変数の型宣言すら無いようだが?
知らない言語があるだけでアホ呼ばわりされるとは不条理だなぁ・・・
python調べてみたんだが、変数の型宣言すら無いようだが?
98 :デフォルトの名無しさん2011/10/22(土) 20:08:00.14
>>96
自分の調べ方が足りないという自覚もないのか?
自分の調べ方が足りないという自覚もないのか?
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でググレカス
110 :デフォルトの名無しさん2011/10/22(土) 20:27:22.69
>>101
なんじゃこりゃああ!
なんじゃこりゃああ!
60 :デフォルトの名無しさん2011/10/22(土) 15:25:41.51
せめて型を書いたときくらい厳密な型検査をしてほしいだけなのに > Dart
Hashable h = '1';
int n = h;
print(n + 1); # 出力:11
Hashable h = '1';
int n = h;
print(n + 1); # 出力:11
65 :デフォルトの名無しさん2011/10/22(土) 15:41:03.82
>>60にwarningも出さない言語が「完全な静的型付け」をサポートしてるとかありえん
67 :デフォルトの名無しさん2011/10/22(土) 15:44:13.90
>>65
出すよ
実際に自分でやってみりゃ一発だろ
出すよ
実際に自分でやってみりゃ一発だろ
68 :デフォルトの名無しさん2011/10/22(土) 15:46:44.89
>>67
自分こそやってみてから言えよ
warningなんて出ねーよ
自分こそやってみてから言えよ
warningなんて出ねーよ
73 :デフォルトの名無しさん2011/10/22(土) 18:03:48.89
>>60は、HashableがintのSubtypeだから警告すら出ないんだね。
HashableをStringにすれば一応警告が出る。
HashableをStringにすれば一応警告が出る。
78 :デフォルトの名無しさん2011/10/22(土) 19:21:40.19
>>60
型推論の無い言語でHashableなんて抽象的な型で変数を定義するのは、
静的に型を指定してるとは言えないんじゃないか。
型推論の無い言語でHashableなんて抽象的な型で変数を定義するのは、
静的に型を指定してるとは言えないんじゃないか。
81 :デフォルトの名無しさん2011/10/22(土) 19:50:15.88
>>60
main() {
Hashable h = 'this';
int n = h;
print(n + 1); # 出力: this1
}
こうなるんだな、ワロタw
main() {
Hashable h = 'this';
int n = h;
print(n + 1); # 出力: this1
}
こうなるんだな、ワロタw
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
>>81
はぁ、それって単純に+演算子が
オーバーロードされてるようなもんじゃん。
はぁ、それって単純に+演算子が
オーバーロードされてるようなもんじゃん。
85 :デフォルトの名無しさん2011/10/22(土) 19:55:02.94
>>83
intとstringがoperator+で足せるのはJavaやC#なんかもそうだ
好みの問題は別として、別におかしくない
問題は2行目だろw
int型の変数に代入してるのに、完全に何の意味もない
intとstringがoperator+で足せるのはJavaやC#なんかもそうだ
好みの問題は別として、別におかしくない
問題は2行目だろw
int型の変数に代入してるのに、完全に何の意味もない
88 :デフォルトの名無しさん2011/10/22(土) 19:58:27.14
>>82や>>85が言う通り、intと宣言されているのにStringなのが問題の根っこ
コードを一目見て読み取れない>>83が静的型言語でマトモなコードを書けるとは到底思えない件w
コードを一目見て読み取れない>>83が静的型言語でマトモなコードを書けるとは到底思えない件w
102 :デフォルトの名無しさん2011/10/22(土) 20:15:12.69
>>81
これ、intの解釈が他の言語と違うだけじゃねーの?
intだから数値しか入れられないとおもいきや
実際にはオブジェクトだからキャストすれば何でも入れられる。
これ、intの解釈が他の言語と違うだけじゃねーの?
intだから数値しか入れられないとおもいきや
実際にはオブジェクトだからキャストすれば何でも入れられる。
104 :デフォルトの名無しさん2011/10/22(土) 20:16:49.48
>>102
× オブジェクトだから
○ 動的型付け言語だから
× オブジェクトだから
○ 動的型付け言語だから
118 :デフォルトの名無しさん2011/10/22(土) 20:48:26.64
逆に考えるんだ
>>60の例は型を指定しているせいで惑わされる
最初から変数に型が無ければ迷う事はないと
>>60の例は型を指定しているせいで惑わされる
最初から変数に型が無ければ迷う事はないと
428 :デフォルトの名無しさん2011/10/29(土) 20:21:08.06
> >>60に警告すら出さないのは静的型付けの観点から見て何のメリットがあるの?
> 実行時にすら型チェックしないのは何のメリットがあるの?
ないよ。これはJavaScriptに変換するための制限か
もしくは、まだベータ版だからだだろう。
> 実行時にすら型チェックしないのは何のメリットがあるの?
ないよ。これはJavaScriptに変換するための制限か
もしくは、まだベータ版だからだだろう。
429 :デフォルトの名無しさん2011/10/30(日) 06:25:47.82
>>428
> ないよ。これはJavaScriptに変換するための制限か
コンパイラ(トランスレータ)が静的型検査するのにターゲット言語の制限なんて関係ねえだろカス
動的型検査だってJavaScriptで実装しようと思えばできる
でもググルは敢えて、検査しなかった
静的型付けのデメリットをよく知っていて、それが致命的なものと考えたからだ
> もしくは、まだベータ版だからだだろう。
ぷ
> ないよ。これはJavaScriptに変換するための制限か
コンパイラ(トランスレータ)が静的型検査するのにターゲット言語の制限なんて関係ねえだろカス
動的型検査だってJavaScriptで実装しようと思えばできる
でもググルは敢えて、検査しなかった
静的型付けのデメリットをよく知っていて、それが致命的なものと考えたからだ
> もしくは、まだベータ版だからだだろう。
ぷ
66 :デフォルトの名無しさん2011/10/22(土) 15:43:36.94
Js_of_ocaml は OCaml と Javascript を混ぜて書けるよ
OCamlだけで書けば静的型安全だよ
Javascriptで書いた部分は動的型付けだよ
OCamlだけで書けば静的型安全だよ
Javascriptで書いた部分は動的型付けだよ
74 :デフォルトの名無しさん2011/10/22(土) 18:16:01.22
この程度は厳密に型をチェックするツールみたいなのが出てきて検出可能になるだろ
77 :デフォルトの名無しさん2011/10/22(土) 18:56:42.17
Dartが静的型?ふざけんなw
型付けできない式がある時点で静的型言語と言えるわけがねえだろw
型付けできない式がある時点で静的型言語と言えるわけがねえだろw
80 :デフォルトの名無しさん2011/10/22(土) 19:47:29.30
インターフェースは便利だよw
ただ、型推論無しの静的言語じゃ、変数をインターフェースだけで定義できないだろw
型推論の無いDartで変数の型を静的にチェックしてもらいたかったら、
具体的な型で変数を定義しろってことだ。
ただ、型推論無しの静的言語じゃ、変数をインターフェースだけで定義できないだろw
型推論の無いDartで変数の型を静的にチェックしてもらいたかったら、
具体的な型で変数を定義しろってことだ。
84 :デフォルトの名無しさん2011/10/22(土) 19:54:26.74
+は数値だけじゃなく、文字列を結合する演算子でもあって、
片方にオブジェクト型が含まれていると、
toString()呼び出しで文字列として結合するようなもんかな。
片方にオブジェクト型が含まれていると、
toString()呼び出しで文字列として結合するようなもんかな。
86 :デフォルトの名無しさん2011/10/22(土) 19:56:57.09
int型の変数が'this'という値を持てて、それがエラーにすらならないのなら
Dartの静的型って屁の役にも立たないだろw
Dartの静的型って屁の役にも立たないだろw
89 :デフォルトの名無しさん2011/10/22(土) 20:00:10.92
>>86
単なる注釈だからな。そこが静的型付けと型注釈の決定的違い。
単なる注釈だからな。そこが静的型付けと型注釈の決定的違い。
87 :デフォルトの名無しさん2011/10/22(土) 19:57:01.29
変数の型は無視して、変数の中身のオブジェクトに従って+演算子が動作してるわけだ
90 :デフォルトの名無しさん2011/10/22(土) 20:01:09.50
Dartは本当に
int n = h;
のところで警告出さないのか?
int n = h;
のところで警告出さないのか?
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上で試せる実装では、
警告どころか実行時エラーにすらならない
91 :デフォルトの名無しさん2011/10/22(土) 20:01:26.61
intとStringがHashableのsubtypeだから何の警告も出ずに実行できてしまうわけで、
hの型を具体的なStringとかにしとけば、n=h;で一応警告がでる。
Dartの型システムがまるで役に立たないと言うわけでもない。
hの型を具体的なStringとかにしとけば、n=h;で一応警告がでる。
Dartの型システムがまるで役に立たないと言うわけでもない。
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にそのまま入れるのがいいわけはないよ
103 :デフォルトの名無しさん2011/10/22(土) 20:15:54.55
>>99
正確には、値を変換しているわけじゃないから、coercionではなく、type conversionでしょ。
実行時に動的型検査するのが当然、には同意。
もっと言えば、静的型付けなら、コンパイル時に警告を出して当然。
正確には、値を変換しているわけじゃないから、coercionではなく、type conversionでしょ。
実行時に動的型検査するのが当然、には同意。
もっと言えば、静的型付けなら、コンパイル時に警告を出して当然。
95 :デフォルトの名無しさん2011/10/22(土) 20:06:13.81
subtypeやめますか
静的型やめますか
静的型やめますか
106 :デフォルトの名無しさん2011/10/22(土) 20:17:11.89
>>95
いやサブクラスの変数にスーパークラスのオブジェクトが束縛出来るのがおかしいだけだろ
普通の静的型付け言語ならキャストしないと弾かれる
いやサブクラスの変数にスーパークラスのオブジェクトが束縛出来るのがおかしいだけだろ
普通の静的型付け言語ならキャストしないと弾かれる
105 :デフォルトの名無しさん2011/10/22(土) 20:16:58.63
HashableはPythonにあるな。オブジェクトのハッシュ値を返すメソッドを実装したインターフェース。
このインタフェースを実装してる型のオブジェクトは、
Pythonなら__hash__、DartならhashCode()で、オブジェクトのハッシュ値を返す。
このインタフェースを実装してる型のオブジェクトは、
Pythonなら__hash__、DartならhashCode()で、オブジェクトのハッシュ値を返す。
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上のコンパイラがおかしいんだろう。本物のコンパイラなら、オプションなりでちゃんと警告ないしはエラーが出ると思いたい
113 :デフォルトの名無しさん2011/10/22(土) 20:37:47.43
>>108
残念ながらダウンキャストで警告が出ないのはDartのドキュメントに書かれてる
残念ながらダウンキャストで警告が出ないのはDartのドキュメントに書かれてる
114 :デフォルトの名無しさん2011/10/22(土) 20:39:40.74
>>113
そのあたりが型注釈としての落とし所なんだろうな
静的型がベースなら、絶対そんな仕様にはしないよ
そのあたりが型注釈としての落とし所なんだろうな
静的型がベースなら、絶対そんな仕様にはしないよ
137 :デフォルトの名無しさん2011/10/22(土) 21:48:11.08
>>113-114
まじか!?
い、いらなすぎる……
まじか!?
い、いらなすぎる……
109 :デフォルトの名無しさん2011/10/22(土) 20:24:32.96
Webドカタ言語を目指すのなら、警告だけでは意味ないだろうな。
ちゃんとコンパイルエラーにしないと。
ちゃんとコンパイルエラーにしないと。
111 :デフォルトの名無しさん2011/10/22(土) 20:27:48.27
>>109
お前はなにドカタ言語を使ってるの?
お前はなにドカタ言語を使ってるの?
112 :デフォルトの名無しさん2011/10/22(土) 20:29:51.50
109じゃないけど、PHP使っててローカル変数に型指定ができなくて発狂中ですw
インテリセンスがきかねーんだ
インテリセンスがきかねーんだ
115 :デフォルトの名無しさん2011/10/22(土) 20:43:40.19
そして動的型付けがベースだから変数束縛時の型チェックはしてない、という事か
119 :デフォルトの名無しさん2011/10/22(土) 20:50:52.28
結論が出たようだな。
動的型付け言語が世界を支配する!
動的型付け言語が世界を支配する!
120 :デフォルトの名無しさん2011/10/22(土) 20:59:01.38
監査機関がいるから、不正がバレるんだ。
監査機関がいなければ、不正は起こらない!
監査機関がいなければ、不正は起こらない!
121 :デフォルトの名無しさん2011/10/22(土) 21:01:28.54
>>120
正しくは、
ウソばっかりつく監査法人にみてもらっても、かえって害悪しかないよね
だな。
正しくは、
ウソばっかりつく監査法人にみてもらっても、かえって害悪しかないよね
だな。
122 :デフォルトの名無しさん2011/10/22(土) 21:03:53.85
Dartの聞き齧り情報で鬼の首を取ったように
「ググルが静的型付けが優れていると証明した!」
と言いふらしていたのが、
Dartの型注釈のダメなところが指摘されたとたんに
「Dartは動的型だからダメダメだぁー!」
楽しそうな人生だねw
「ググルが静的型付けが優れていると証明した!」
と言いふらしていたのが、
Dartの型注釈のダメなところが指摘されたとたんに
「Dartは動的型だからダメダメだぁー!」
楽しそうな人生だねw
138 :デフォルトの名無しさん2011/10/22(土) 21:52:52.20
>>122
そこで過ちを認められず、意固地になるほうがおかしいと思うが?
そこで過ちを認められず、意固地になるほうがおかしいと思うが?
139 :デフォルトの名無しさん2011/10/22(土) 22:06:00.27
でも>>122は矛盾してないけどね。
動的型付けはだめだからGoogleは静的型付けを選んだ。
だけど中途半端に残した動的型付けの機能、そのせいでダメな部分が残ってる。
動的型付けはだめだからGoogleは静的型付けを選んだ。
だけど中途半端に残した動的型付けの機能、そのせいでダメな部分が残ってる。
144 :デフォルトの名無しさん2011/10/22(土) 22:41:40.07
>>139の馬鹿さは病的だな
中途半端加えられた静的型付けの機能、そのせいでダメな部分が加えられた
だろうがw
中途半端加えられた静的型付けの機能、そのせいでダメな部分が加えられた
だろうがw
145 :デフォルトの名無しさん2011/10/22(土) 22:48:56.33
>>144
使いたくなければ静的型付け使わなければいいだけなのに、駄目な部分が加えられたとはこれいかに??
使いたくなければ静的型付け使わなければいいだけなのに、駄目な部分が加えられたとはこれいかに??
146 :デフォルトの名無しさん2011/10/22(土) 22:53:48.27
>>145は他人のコードの面倒見たりしないんだろうな…
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!を印字する
}
正直こんな型注釈が一体何の役に立つのか理解に苦しむわ……
126 :デフォルトの名無しさん2011/10/22(土) 21:07:42.66
>>123
なんでHashableが流行ってるんだよw普通にStringって書けよ警告してもらえるからw
なんでHashableが流行ってるんだよw普通にStringって書けよ警告してもらえるからw
128 :デフォルトの名無しさん2011/10/22(土) 21:09:37.46
>>126
実際にHashに関わるコードから呼ばれてたらどうなんだ?
つーか、君、ドカタ?
実際にHashに関わるコードから呼ばれてたらどうなんだ?
つーか、君、ドカタ?
132 :デフォルトの名無しさん2011/10/22(土) 21:17:20.03
>>128
ドカタって言っている人に聞きたいんだ。
君、仕事で何の言語使ってるの?
ドカタって言っている人に聞きたいんだ。
君、仕事で何の言語使ってるの?
124 :デフォルトの名無しさん2011/10/22(土) 21:04:39.98
ほとんど意味の無い監査や認証の事務に労力をすり減らす企業は実在する。
125 :デフォルトの名無しさん2011/10/22(土) 21:06:41.44
>>124
静的型付言語でシコシコ書いてるドカタのことだね!
静的型付言語でシコシコ書いてるドカタのことだね!
127 :デフォルトの名無しさん2011/10/22(土) 21:09:16.02
ダウンキャストに警告が出ないのが問題の本質だからHashableは関係ない
129 :デフォルトの名無しさん2011/10/22(土) 21:09:59.60
これ、結局動的型情報で動いてるわけだから
intという型情報を用いた最適化も無理じゃん
stringが渡ってきたらstringの加算をやるんだろ?
静的型注釈が本気で何の役にも立ってない
intという型情報を用いた最適化も無理じゃん
stringが渡ってきたらstringの加算をやるんだろ?
静的型注釈が本気で何の役にも立ってない
131 :デフォルトの名無しさん2011/10/22(土) 21:11:09.30
>>129
ま、ドキュメント程度の意味しかないだろうね。
ま、ドキュメント程度の意味しかないだろうね。
427 :デフォルトの名無しさん2011/10/29(土) 20:08:57.51
>>425
>>60に警告すら出さないのは静的型付けの観点から見て何のメリットがあるの?
実行時にすら型チェックしないのは何のメリットがあるの?
>>129の言うように型情報を用いた最適化も無理なことに何のメリットがあるの?
>>60に警告すら出さないのは静的型付けの観点から見て何のメリットがあるの?
実行時にすら型チェックしないのは何のメリットがあるの?
>>129の言うように型情報を用いた最適化も無理なことに何のメリットがあるの?
133 :デフォルトの名無しさん2011/10/22(土) 21:18:07.92
HaskellとPython
134 :デフォルトの名無しさん2011/10/22(土) 21:20:25.37
Smalltalkの仕事があったけど毎月400時間労働の酷い仕事だったよ
136 :デフォルトの名無しさん2011/10/22(土) 21:48:08.21
>>133 >>134
それで、どんなシステム作ってるの?
それで、どんなシステム作ってるの?
140 :デフォルトの名無しさん2011/10/22(土) 22:16:11.96
規格pdf一通り読んだんだが、ダウンキャストに警告ださないって明言されてるの何ページめ?
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 というパラグラフに書いてある。
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関係にないのだから。
150 :1472011/10/22(土) 22:56:26.63
すまん、ダウンキャストとはまた別問題だった
>>148ですな
>>148ですな
141 :デフォルトの名無しさん2011/10/22(土) 22:30:09.16
ググる様のドキュメントにはしっかり動的型付言語と書いてあるんだが…
142 :デフォルトの名無しさん2011/10/22(土) 22:31:38.67
>>141
そりゃ、動的か静的かと言われれば動的に決まってんだろ。JS互換あんだし
そりゃ、動的か静的かと言われれば動的に決まってんだろ。JS互換あんだし
151 :デフォルトの名無しさん2011/10/22(土) 23:01:18.68
既存の古典的な型システムとは違い、ダウンキャストの際は警告を発しませんって明記されてた。
要らんw
要らんw
152 :デフォルトの名無しさん2011/10/22(土) 23:02:52.14
>>151
しかも、その文章から漂うドヤ顔っぷりがたまらんよなw
メリットのつもりなのかw
しかも、その文章から漂うドヤ顔っぷりがたまらんよなw
メリットのつもりなのかw
154 :デフォルトの名無しさん2011/10/22(土) 23:15:18.56
>>152
一人で組んでるなら、ドヤ文通り確かに「実は中身が文字列であることをプログラマが知っている」かもしれんが、
そうでない場合のための型安全が欲しいってのに何考えてるんだろうな(;´Д`)
一人で組んでるなら、ドヤ文通り確かに「実は中身が文字列であることをプログラマが知っている」かもしれんが、
そうでない場合のための型安全が欲しいってのに何考えてるんだろうな(;´Д`)
153 :デフォルトの名無しさん2011/10/22(土) 23:08:54.47
型推論によって型注釈が無くても型安全な言語すらあるのに、
型注釈を付けても型安全じゃないDart……
型注釈を付けても型安全じゃないDart……
155 :デフォルトの名無しさん2011/10/22(土) 23:21:58.42
結局Dartの一連の話では、静的厨の無知っぷりが引き立ったな。
Dartのどこが原則静的型だかw
Dartのどこが原則静的型だかw
156 :デフォルトの名無しさん2011/10/22(土) 23:23:07.29
>>155
んー、確かにDartについて無知だったな。すまん
規格までいちいち読んでなかったからな。正直「まさか」だったわw
んー、確かにDartについて無知だったな。すまん
規格までいちいち読んでなかったからな。正直「まさか」だったわw
159 :デフォルトの名無しさん2011/10/22(土) 23:32:58.77
Dart作った本人が大規模システムじゃ静的な型付けが必要って言ってるんだから。Dartについてはこれ以上どうこう言っても仕方ないだろう。
162 :デフォルトの名無しさん2011/10/22(土) 23:38:07.03
>>159
でもDart自体はどう転んでも動的型付言語だわな。
「大規模開発だろうが、動的型付けをベースに考えざるを得ない。
型注釈ぐらいなら動的型の柔軟性を損わない範囲内で許すけど。」
というグーグルの判断でしょw
でもDart自体はどう転んでも動的型付言語だわな。
「大規模開発だろうが、動的型付けをベースに考えざるを得ない。
型注釈ぐらいなら動的型の柔軟性を損わない範囲内で許すけど。」
というグーグルの判断でしょ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上で動かせるだろ。
160 :デフォルトの名無しさん2011/10/22(土) 23:34:45.89
グーグル様の御威光ふりかざしてドヤ顔で静的型マンセーしていたのが
掌かえしたように逆ギレしてグーグルをドヤ顔よばわり
おもしろいねえw
掌かえしたように逆ギレしてグーグルをドヤ顔よばわり
おもしろいねえw
161 :デフォルトの名無しさん2011/10/22(土) 23:35:56.24
>>160
なんだ。結局グーグル様のご威光があればひれ伏しちゃうタイプなのか、動的厨は
信念の無いやつだなぁ……
なんだ。結局グーグル様のご威光があればひれ伏しちゃうタイプなのか、動的厨は
信念の無いやつだなぁ……
163 :デフォルトの名無しさん2011/10/22(土) 23:38:49.40
>>161
ひれ伏さなかったから、君の無知さ加減が暴かれたわけだがw
ひれ伏さなかったから、君の無知さ加減が暴かれたわけだがw
166 :デフォルトの名無しさん2011/10/22(土) 23:42:50.13
なんで動的厨って『動的はこう素晴らしい』って語らないで『静的厨は頭が悪い』みたいな人格攻撃しかしないの?
静的厨としては、動的厨が動的の素晴らしさをアピールできるなら、是非それにのりたいのだが
静的厨としては、動的厨が動的の素晴らしさをアピールできるなら、是非それにのりたいのだが
169 :デフォルトの名無しさん2011/10/22(土) 23:45:41.98
>>166
前のスレでは何度かやったんだがなあ
今はスレタイ変わっちゃったから「別に大規模開発での静的は否定するつもりねーからいいや」ってなっちゃった
前のスレでは何度かやったんだがなあ
今はスレタイ変わっちゃったから「別に大規模開発での静的は否定するつもりねーからいいや」ってなっちゃった
170 :デフォルトの名無しさん2011/10/22(土) 23:45:49.76
>>166
あれだけドヤ顔で「静的型の優位性をグーグルが認めた」と言いふらしておいて醜態さらしたのに、
馬鹿にするなとか言うのは、馬鹿にされている本人ぐらいなものだろww
あれだけドヤ顔で「静的型の優位性をグーグルが認めた」と言いふらしておいて醜態さらしたのに、
馬鹿にするなとか言うのは、馬鹿にされている本人ぐらいなものだろww
171 :デフォルトの名無しさん2011/10/22(土) 23:47:09.88
>>169
まぁそりゃそうか
大規模開発を動的でやるのがつらいことくらい、1度やったことありゃわかるもんな
まぁそりゃそうか
大規模開発を動的でやるのがつらいことくらい、1度やったことありゃわかるもんな
172 :デフォルトの名無しさん2011/10/22(土) 23:47:35.19
>>169
そうなんだよな。静的型付けはドカタ言語としてはピッタリなんだよ。
そうなんだよな。静的型付けはドカタ言語としてはピッタリなんだよ。
175 :デフォルトの名無しさん2011/10/22(土) 23:51:32.54
>>172
あれ?
そういや、ドカタドカタうるさい奴に
お前どんなシステム作ってるのって聞いたのに
答えがなかったな。
やっぱ、プロじゃないのか。
あれ?
そういや、ドカタドカタうるさい奴に
お前どんなシステム作ってるのって聞いたのに
答えがなかったな。
やっぱ、プロじゃないのか。
177 :デフォルトの名無しさん2011/10/22(土) 23:53:21.99
別に静的厨は俺一人じゃないしなあ・・・どうしろと
少なくとも俺除いてもう1人いるし
>>172で、お前はどんなシステム作ってんの?
少なくとも俺除いてもう1人いるし
>>172で、お前はどんなシステム作ってんの?
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
173 :デフォルトの名無しさん2011/10/22(土) 23:49:48.02
一人、動的厨を装った荒らしが混じってるみたいだな
トリップつけてくんねーかな
トリップつけてくんねーかな
174 :デフォルトの名無しさん2011/10/22(土) 23:50:35.32
>>173
だからさあ、馬鹿にされたくなかったら、馬鹿なこと言わなきゃいいの。わかった?
だからさあ、馬鹿にされたくなかったら、馬鹿なこと言わなきゃいいの。わかった?
176 :デフォルトの名無しさん2011/10/22(土) 23:53:10.62
自分の経験は示さずに他人に職歴示せと言う。ドカタって本当に馬鹿だね。
178 :デフォルトの名無しさん2011/10/22(土) 23:56:51.15
むしろ静的を望むのはドカタに制約を課したい人間だと思うんだが……
180 :デフォルトの名無しさん2011/10/22(土) 23:59:27.34
静的か動的かに関係なく、
アーキテクチャってものをしっかり考えている所(良いところ)は
自然と開発のルールが出来る。それがいわゆる制約なわけ。
これはアジャイル開発でも同じ事。
何も考えずに適当に好きかって作っていいのは
自分一人プロジェクトだけ。
アーキテクチャってものをしっかり考えている所(良いところ)は
自然と開発のルールが出来る。それがいわゆる制約なわけ。
これはアジャイル開発でも同じ事。
何も考えずに適当に好きかって作っていいのは
自分一人プロジェクトだけ。
181 :デフォルトの名無しさん2011/10/23(日) 00:01:05.57
emscriptenなんて使うとガチのCがjsになるぞw
開発速度は動的な言語のが高いし柔軟性あるし
折衷案的な選択だわな
互換性に縛られてるJSをオーバーホールするには
ありな仕様だと思うけどね
開発速度は動的な言語のが高いし柔軟性あるし
折衷案的な選択だわな
互換性に縛られてるJSをオーバーホールするには
ありな仕様だと思うけどね
184 :デフォルトの名無しさん2011/10/23(日) 00:04:30.80
>>181
開発速度が動的な言語の方が高いってのが、なんか実感わかないんだよなあ……
ケアレスミスとかが多くなるし
開発速度が動的な言語の方が高いってのが、なんか実感わかないんだよなあ……
ケアレスミスとかが多くなるし
182 :デフォルトの名無しさん2011/10/23(日) 00:02:59.99
> 開発速度は動的な言語のが高いし
それは小さいプログラムだけだよ。
システムとは呼べないような。
それは小さいプログラムだけだよ。
システムとは呼べないような。
183 :デフォルトの名無しさん2011/10/23(日) 00:04:02.27
いや、大規模開発で動的型付けより静的型付けが優れているのは、Googleに言われるまでもなく、当たり前のことだから。
185 :デフォルトの名無しさん2011/10/23(日) 00:06:51.53
>>183
その当たり前を納得しない動的厨がいたので、じゃあGoogleのDartでドヤ!ってやったらDartがひどい有様だったので逆ドヤされたのが今の状況w
その当たり前を納得しない動的厨がいたので、じゃあGoogleのDartでドヤ!ってやったらDartがひどい有様だったので逆ドヤされたのが今の状況w
186 :デフォルトの名無しさん2011/10/23(日) 00:07:09.62
数十行のファイルが2−3枚とか、そのレベルなら動的型付けの言語の方が開発速度速いと思うよ。確かに。
190 :デフォルトの名無しさん2011/10/23(日) 00:14:37.30
>>186
1人専任で設計からリリースまで半年ぐらいの条件でも
動的型付けの方が効率良いと思うよ。
メンバが4人になるぐらいから逆転する気がする。
ただし秀才天才しか居ないプロジェクトは除く。
1人専任で設計からリリースまで半年ぐらいの条件でも
動的型付けの方が効率良いと思うよ。
メンバが4人になるぐらいから逆転する気がする。
ただし秀才天才しか居ないプロジェクトは除く。
196 :デフォルトの名無しさん2011/10/23(日) 00:24:57.62
>>190
ああ、そうだね。それは同意する。
でも、実際にはプログラマーが型を意識できない、スコープを意識できない、だから動的型付けな言語を採用するってパターンなんだよね。
ウェブの開発やってるとそうだとしか思えない。
ああ、そうだね。それは同意する。
でも、実際にはプログラマーが型を意識できない、スコープを意識できない、だから動的型付けな言語を採用するってパターンなんだよね。
ウェブの開発やってるとそうだとしか思えない。
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なんて名前のグローバル変数を使っていたとしても、(あくまで仮だからねw)
そこに書きこむコードはほんの数秒で判明するだろう。
そういう場合静的だと情報の把握のスピードが違うんだよね。
なにがどれに依存していてどこで書き換えられてとか
影響範囲の追跡がかなり簡単になる。
仮にdataなんて名前のグローバル変数を使っていたとしても、(あくまで仮だからねw)
そこに書きこむコードはほんの数秒で判明するだろう。
191 :デフォルトの名無しさん2011/10/23(日) 00:17:49.49
> 1人専任で設計からリリースまで半年ぐらいの条件でも
それ小さくね?
設計からリリースまでで半年なら
開発は2人月ぐらいだろ?
それ小さくね?
設計からリリースまでで半年なら
開発は2人月ぐらいだろ?
195 :デフォルトの名無しさん2011/10/23(日) 00:23:43.41
>>191
そのくらいの規模でも、ScalaやOCamlなら
動的型付けより効率よく開発できそうだ
一方Javaなら開発に10人月くらいかかりそうw
そのくらいの規模でも、ScalaやOCamlなら
動的型付けより効率よく開発できそうだ
一方Javaなら開発に10人月くらいかかりそうw
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で泣き見たわw
PHPで泣き見たわw
199 :デフォルトの名無しさん2011/10/23(日) 00:29:25.05
>>193
> なんか静的な型の言語に幻想持ってるのが多いな
逆だ。他人が作った動的型付け言語で作られたシステムを修正するときに
影響範囲がわかりづらいなどの問題点を嫌というほど味わった。
静的型付けの幻想ではなく、動的型付けに幻滅したんだよ。
そもそも昔からCやC++やJavaなどの型付き言語をメインの開発言語で
やってきたんだ。今更幻想なんてものはない。
ただ俺にとってはそれが標準なだけ。
> なんか静的な型の言語に幻想持ってるのが多いな
逆だ。他人が作った動的型付け言語で作られたシステムを修正するときに
影響範囲がわかりづらいなどの問題点を嫌というほど味わった。
静的型付けの幻想ではなく、動的型付けに幻滅したんだよ。
そもそも昔からCやC++やJavaなどの型付き言語をメインの開発言語で
やってきたんだ。今更幻想なんてものはない。
ただ俺にとってはそれが標準なだけ。
197 :デフォルトの名無しさん2011/10/23(日) 00:26:07.43
ウェブ開発者を馬鹿にするなw
動的型付けばかり使ってるわけじゃねーよw.
動的型付けばかり使ってるわけじゃねーよw.
198 :デフォルトの名無しさん2011/10/23(日) 00:28:50.67
動的型付けプログラマのほうが型付けやスコープで痛い目に合いやすく、
それゆえに詳しいことが多い。
「痛くなければ覚えませぬ」
それゆえに詳しいことが多い。
「痛くなければ覚えませぬ」
200 :デフォルトの名無しさん2011/10/23(日) 00:30:35.17
>>198
痛い目にあったら、すぐさま静的型付けが良いってなるだろ。
痛くない方法があることを知らんのか?
痛い目にあったら、すぐさま静的型付けが良いってなるだろ。
痛くない方法があることを知らんのか?
203 :デフォルトの名無しさん2011/10/23(日) 00:37:00.32
>>200
別に型付けの静的/動的だけが言語の選択条件じゃないから
別に型付けの静的/動的だけが言語の選択条件じゃないから
204 :デフォルトの名無しさん2011/10/23(日) 00:39:33.78
>>203
何当たり前の事いってんのw
総合的に見て、大規模なら静的型付けの方が
より多くの情報を得られソースコードの把握がしやすいんだよ。
それが選択の理由。
何当たり前の事いってんのw
総合的に見て、大規模なら静的型付けの方が
より多くの情報を得られソースコードの把握がしやすいんだよ。
それが選択の理由。
201 :デフォルトの名無しさん2011/10/23(日) 00:35:00.39
世の中には、痛くてもそれが好きな人や
痛くてもすぐに忘れてしまう人がいることを
知っていおいたほうがいい。
痛くてもすぐに忘れてしまう人がいることを
知っていおいたほうがいい。
202 :デフォルトの名無しさん2011/10/23(日) 00:35:24.10
動的だと適当にやっても当面は動くからなあ。
動かなくなったときには、どうしようもなくなっている。
動かなくなったときには、どうしようもなくなっている。
205 :デフォルトの名無しさん2011/10/23(日) 00:41:05.45
ま、言語仕様だけで言語を選ぶなら
いまどきJavaなんて誰も選択しないわなw
いまどきJavaなんて誰も選択しないわなw
207 :デフォルトの名無しさん2011/10/23(日) 00:43:39.10
影響範囲が解りづらいってよく言うけどそんなに違うか?
確かにIDE駆使した静的型付け言語に比べりゃ多少手間はかかるかもしれんけど
絞り切れないなんて状況は滅多に無いと思うが
確かにIDE駆使した静的型付け言語に比べりゃ多少手間はかかるかもしれんけど
絞り切れないなんて状況は滅多に無いと思うが
209 :デフォルトの名無しさん2011/10/23(日) 00:50:27.60
>>207
全然違うよ
ほんの数秒で、全プロジェクトの中から
あるクラスのメソッドを的確に調べてくれたりする。
もちろんそのメソッド名がgetであったりしても、無関係のgetと迷うことはない。
動的型付け言語だと対処法的に冗長な名前をつけることがよくある。
タイプ数が増えて、めんどくせぇw
全然違うよ
ほんの数秒で、全プロジェクトの中から
あるクラスのメソッドを的確に調べてくれたりする。
もちろんそのメソッド名がgetであったりしても、無関係のgetと迷うことはない。
動的型付け言語だと対処法的に冗長な名前をつけることがよくある。
タイプ数が増えて、めんどくせぇw
208 :デフォルトの名無しさん2011/10/23(日) 00:44:53.49
ドカタだからスパゲティコード量産してるに決まってるじゃん
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
経験が浅いと、多人数でシステムを作った経験がないと
書くことにばかり目が言ってしまう。
実際は、書くことよりも読むことのほうがずっと多い。
過去に自分が書いたコードにバグがある。
他人の書いたソースコードを修正する。
他人が書いたソースコードをレビューする。
読むときのことを考えているかという点を見れば
その人がどれくらい出来るの人なのかがわかる。
書くことにばかり目が言ってしまう。
実際は、書くことよりも読むことのほうがずっと多い。
過去に自分が書いたコードにバグがある。
他人の書いたソースコードを修正する。
他人が書いたソースコードをレビューする。
読むときのことを考えているかという点を見れば
その人がどれくらい出来るの人なのかがわかる。
216 :デフォルトの名無しさん2011/10/23(日) 01:10:30.45
まともな型推論が無い静的型付け言語は、
型の記述が冗長になりすぎて読みにくかったりするのは確かにあるね。
その冗長な記述を読み解く方が近道だったりもすることも多いが。
型の記述が冗長になりすぎて読みにくかったりするのは確かにあるね。
その冗長な記述を読み解く方が近道だったりもすることも多いが。
217 :デフォルトの名無しさん2011/10/23(日) 01:14:31.77
さっきからドカタドカタとうるさい奴に
何のシステム作っているのか聞いたが
レスがないようだ。
何のシステム作っているのか聞いたが
レスがないようだ。
219 :デフォルトの名無しさん2011/10/23(日) 01:23:59.24
dartはdartネイティブで実行する場合は少しはマシなのかな
JSにトランスレートする場合も原理的にはもう少し型チェックを厳格にできそうだけど
多分そうしないのは効率だよな
JSにトランスレートする場合も原理的にはもう少し型チェックを厳格にできそうだけど
多分そうしないのは効率だよな
220 :デフォルトの名無しさん2011/10/23(日) 06:54:43.72
型推論は言語仕様に含める必要ないだろ
ツールやエディタがやればいい
コーディングルールにしても余計なスペースなんて入れずとも
エディタが調整して見やすくするのが正しい進化だった
読みやすさのためにスペースを何度も叩くのはバカらしい
言語仕様に何もかもを含めすぎてる
もっとツールやIDEのことを考えろ
ツールやエディタがやればいい
コーディングルールにしても余計なスペースなんて入れずとも
エディタが調整して見やすくするのが正しい進化だった
読みやすさのためにスペースを何度も叩くのはバカらしい
言語仕様に何もかもを含めすぎてる
もっとツールやIDEのことを考えろ
236 :デフォルトの名無しさん2011/10/23(日) 08:39:53.35
>>220
ツールやエディタがそれぞれ個別に型推論を実装するなんて無駄もいいところだろ
きちんと言語仕様で決めて、コンパイラが型推論するほうが良いに決まってる
エディタが型情報を必要とするならコンパイラに問い合わせれば良い
ツールやエディタがそれぞれ個別に型推論を実装するなんて無駄もいいところだろ
きちんと言語仕様で決めて、コンパイラが型推論するほうが良いに決まってる
エディタが型情報を必要とするならコンパイラに問い合わせれば良い
238 :デフォルトの名無しさん2011/10/23(日) 08:49:57.78
>>236
型推論にはコストに見合った価値がない
それを実装し活用する労力以上の価値がない
型推論を言語仕様に含めることで
プログラミング言語、開発ツールそれら全てに実装が必要となる
その実装コストを上回る成果が型推論の採用で得られるとは思えない
その程度ならコード整形ツールのおまけ機能として実装すればいいだけ
俺の主観では
型推論を採用した理由はIDEの実装を困難にすることで
競争を発生させること
IDEによる開発者の囲い込みを行うことで
開発ツールから利益を得ること
つまりバカを騙して効率低下させて金を得ようという
そういう悪意にしか見えない
簡単にIDE作れたら金儲けできないよね
型推論にはコストに見合った価値がない
それを実装し活用する労力以上の価値がない
型推論を言語仕様に含めることで
プログラミング言語、開発ツールそれら全てに実装が必要となる
その実装コストを上回る成果が型推論の採用で得られるとは思えない
その程度ならコード整形ツールのおまけ機能として実装すればいいだけ
俺の主観では
型推論を採用した理由はIDEの実装を困難にすることで
競争を発生させること
IDEによる開発者の囲い込みを行うことで
開発ツールから利益を得ること
つまりバカを騙して効率低下させて金を得ようという
そういう悪意にしか見えない
簡単にIDE作れたら金儲けできないよね
239 :デフォルトの名無しさん2011/10/23(日) 08:53:44.74
>>238
コンパイラだけが型推論を実装すればいいって
書いてるの読めませんか?
文盲ですか?
コンパイラだけが型推論を実装すればいいって
書いてるの読めませんか?
文盲ですか?
240 :デフォルトの名無しさん2011/10/23(日) 09:06:39.70
>>239
お前は無駄を主張した
だから型推論を採用する方が無駄になるという反論をすればいいのか
>型推論にはコストに見合った価値がない
つまり無駄だ
企業は営利目的で動く
企業が主導している言語の仕様は営利を優先する
金になるなら言語仕様を歪める選択肢がある
java c# dart全て企業主導
なら当然、余計なものが含まれる可能性がある
あの人たちが純粋にすばらしい言語を作り出すために動いている
そう考えるのはちょっと甘いんじゃないの
型推論が罠仕様だと疑う俺の考えの方が自然だよ
最強言語cに型推論がない
これだけでも十分すぎる理由だ
存在が理不尽で無駄でメリットがなくても、多数に受け入れられたら
それは金になるし存在理由になる
そういうものはこの世界にありふれている
型推論は世界にありふれている無駄な金儲けの手段になりうる
お前は無駄を主張した
だから型推論を採用する方が無駄になるという反論をすればいいのか
>型推論にはコストに見合った価値がない
つまり無駄だ
企業は営利目的で動く
企業が主導している言語の仕様は営利を優先する
金になるなら言語仕様を歪める選択肢がある
java c# dart全て企業主導
なら当然、余計なものが含まれる可能性がある
あの人たちが純粋にすばらしい言語を作り出すために動いている
そう考えるのはちょっと甘いんじゃないの
型推論が罠仕様だと疑う俺の考えの方が自然だよ
最強言語cに型推論がない
これだけでも十分すぎる理由だ
存在が理不尽で無駄でメリットがなくても、多数に受け入れられたら
それは金になるし存在理由になる
そういうものはこの世界にありふれている
型推論は世界にありふれている無駄な金儲けの手段になりうる
242 :デフォルトの名無しさん2011/10/23(日) 09:16:01.59
そんだけ長文書いておいて、型推論のデメリットを
「IDEの実装が大変だから」以外に言えてないのは凄いね。
それすら>>236で反論されてるけど。
「IDEの実装が大変だから」以外に言えてないのは凄いね。
それすら>>236で反論されてるけど。
250 :デフォルトの名無しさん2011/10/23(日) 10:16:26.22
>>236
コンパイル出来る状態でしか補完効かないIDEとか勘弁して欲しい。
コンパイラはコンパイラで推論して、
エディタはエディタなりの推論をするのが
正しいと思う。
コンパイル出来る状態でしか補完効かないIDEとか勘弁して欲しい。
コンパイラはコンパイラで推論して、
エディタはエディタなりの推論をするのが
正しいと思う。
252 :デフォルトの名無しさん2011/10/23(日) 10:25:49.31
>>250
途中までコンパイルできれば、そこまでの型推論の結果をコンパイラにもらえばいいだろ
MLはそういうことができる言語仕様だぞ
途中までコンパイルできれば、そこまでの型推論の結果をコンパイラにもらえばいいだろ
MLはそういうことができる言語仕様だぞ
221 :デフォルトの名無しさん2011/10/23(日) 07:01:31.86
自動インデントとかエディタ内蔵フォーマッタなんて
20年以上前からある機能
型推論とフォーマットを同列にしてる時点で
20年以上前からある機能
型推論とフォーマットを同列にしてる時点で
224 :デフォルトの名無しさん2011/10/23(日) 07:36:37.75
>>221
君さあ、自動フォーマットも型推論も30年以上の歴史があることも知らないの?
静的厨って本当に不勉強だなあ。
君さあ、自動フォーマットも型推論も30年以上の歴史があることも知らないの?
静的厨って本当に不勉強だなあ。
222 :デフォルトの名無しさん2011/10/23(日) 07:26:24.03
ドカタと呼ばれると、自分のことだと認識しているドカタがいるようだwww
223 :デフォルトの名無しさん2011/10/23(日) 07:32:45.09
結局、動的型を叩いてるバカって、自分の力量の無さを言語のせいにしているだけか。
ドカタが「オマエノカイハツケイケンヲイエー!」とか喚いていたから、
まずはお前の経験を書くのが先だろと訊いてみたのに、未だ回答がない。
つまり、そういうことだ。
ドカタが「オマエノカイハツケイケンヲイエー!」とか喚いていたから、
まずはお前の経験を書くのが先だろと訊いてみたのに、未だ回答がない。
つまり、そういうことだ。
225 :デフォルトの名無しさん2011/10/23(日) 07:41:14.03
動的型付けのメリットは大規模になると何もなくなる。
227 :デフォルトの名無しさん2011/10/23(日) 07:45:08.29
>>225
君が言う動的型のメリットと、なぜそれが大規模で消えるのかを説明せよ
君が言う動的型のメリットと、なぜそれが大規模で消えるのかを説明せよ
226 :デフォルトの名無しさん2011/10/23(日) 07:42:37.49
大規模開発で動的型言語を使いにくいのは、人を集めるのが大変だから。
動的言語で良質なコードを書けるプログラマは単価がドカタの2倍はいくし、
工期全体でスケジュールを押さえるのが難しい。
技術的興味のないプロジェクトは断わるか、ふっかけるのが普通だし。
ドカタ動員で押し切れたほうが管理する側はラクなんだよ。
動的言語で良質なコードを書けるプログラマは単価がドカタの2倍はいくし、
工期全体でスケジュールを押さえるのが難しい。
技術的興味のないプロジェクトは断わるか、ふっかけるのが普通だし。
ドカタ動員で押し切れたほうが管理する側はラクなんだよ。
228 :デフォルトの名無しさん2011/10/23(日) 07:52:00.85
型推論が静的言語で普及した現在、動的言語のいいところなんてない。
229 :デフォルトの名無しさん2011/10/23(日) 08:06:25.49
>>228
テンプレートの実体化をいちいち書いている人は多い
それが無くなるまでは、型推論が普及したとは言えない
テンプレートの実体化をいちいち書いている人は多い
それが無くなるまでは、型推論が普及したとは言えない
230 :デフォルトの名無しさん2011/10/23(日) 08:12:25.99
>>228
真の型推論が実装されているのはMLやHaskellといった一部の関数型言語だけ
とても型推論が普及したなんて言える現状ではない
また、C#/Java/C++のような「動的型付けな静的言語」のいい加減さを考えれば、
動的型付け言語の開発効率の良さは検討に値する
真の型推論が実装されているのはMLやHaskellといった一部の関数型言語だけ
とても型推論が普及したなんて言える現状ではない
また、C#/Java/C++のような「動的型付けな静的言語」のいい加減さを考えれば、
動的型付け言語の開発効率の良さは検討に値する
232 :デフォルトの名無しさん2011/10/23(日) 08:18:46.19
>>230
Haskellの型推論は完全じゃないよ。MLの型推論は完全だけど。
Haskellの型推論は完全じゃないよ。MLの型推論は完全だけど。
231 :デフォルトの名無しさん2011/10/23(日) 08:14:00.26
静的型言語で表現可能なクラス = 型推論可能な表現のクラス ⊂ 動的型言語で表現可能なクラス
例: Yコンビネータ
例: Yコンビネータ
233 :デフォルトの名無しさん2011/10/23(日) 08:21:25.42
言葉に詰まって発言者の人格や職をなじる奴はバカだし
効率は価値があるけど動的静的の選択には価値がない
型推論と開発ツールの二択なら開発ツールの方が効率がいいから価値がある
開発効率を考えるなら全ての型推論を持つ言語はVBに劣る
カードの性質を理解してない奴が語るな
型推論という戦術はIDEという戦略の前では無価値に等しい
効率は価値があるけど動的静的の選択には価値がない
型推論と開発ツールの二択なら開発ツールの方が効率がいいから価値がある
開発効率を考えるなら全ての型推論を持つ言語はVBに劣る
カードの性質を理解してない奴が語るな
型推論という戦術はIDEという戦略の前では無価値に等しい
234 :デフォルトの名無しさん2011/10/23(日) 08:24:16.70
>>233
ドカタにとってはそうなんだろうね
ドカタにとってはそうなんだろうね
237 :デフォルトの名無しさん2011/10/23(日) 08:41:38.98
>>234
>言葉に詰まって発言者の人格や職をなじる奴はバカだし
崇高な芸術プログラミングを追及するなら、lispという結末が見えている
選民思想に染まったコミュニティは常に少数派になる
それを主張する奴が、地雷が埋まってるとわかってて踏む美学の持ち主なら
その選択肢の末は滅びしかないだろう
ランチェスターの法則を理解するなら
多数のドカタに価値があって
崇高なプログラミングの価値はそれ以下だということも理解できる
まずは多数のドカタを上回る成果を挙げられる何かを提示してみなさい
それができないなら多数のドカタが最強ということだ
>言葉に詰まって発言者の人格や職をなじる奴はバカだし
崇高な芸術プログラミングを追及するなら、lispという結末が見えている
選民思想に染まったコミュニティは常に少数派になる
それを主張する奴が、地雷が埋まってるとわかってて踏む美学の持ち主なら
その選択肢の末は滅びしかないだろう
ランチェスターの法則を理解するなら
多数のドカタに価値があって
崇高なプログラミングの価値はそれ以下だということも理解できる
まずは多数のドカタを上回る成果を挙げられる何かを提示してみなさい
それができないなら多数のドカタが最強ということだ
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でまとまったサイズのコードを書く香具師は
できるだけ型を明示的に宣言する。
247 :デフォルトの名無しさん2011/10/23(日) 10:00:10.96
>>245
それは動的言語を撃ち落とすための弾丸だったような気がするが
なんで仲間割れしてるの
それは動的言語を撃ち落とすための弾丸だったような気がするが
なんで仲間割れしてるの
246 :デフォルトの名無しさん2011/10/23(日) 09:44:24.92
型推論で省略できるけど、別に型を書いてもいい
つーか、トップレベルの関数は型注釈を書くのが当たり前
ただし、自分で一から型を書かなくても、処理系が推論した型を出力させて、
それをそのままコードとして使うなんて日常的に行われてる
OCamlは型エラーがでても、その直前までの型推論の結果を出力してくれる
(そしてエディタで表示できる)から、型注釈を省略してもデバッグが大変にはならない
使った事も無いのに聞きかじりでテキトーなこと書くなよ
つーか、トップレベルの関数は型注釈を書くのが当たり前
ただし、自分で一から型を書かなくても、処理系が推論した型を出力させて、
それをそのままコードとして使うなんて日常的に行われてる
OCamlは型エラーがでても、その直前までの型推論の結果を出力してくれる
(そしてエディタで表示できる)から、型注釈を省略してもデバッグが大変にはならない
使った事も無いのに聞きかじりでテキトーなこと書くなよ
248 :デフォルトの名無しさん2011/10/23(日) 10:14:39.20
静的厨には型安全厨だけじゃなくて
型注釈厨(別名Dart厨)がいるから
型注釈厨(別名Dart厨)がいるから
251 :デフォルトの名無しさん2011/10/23(日) 10:23:25.28
このスレにおける分類(-> は支持する言語)
静的型安全性が欲しい人 -> 静的型付け言語
型注釈を強制したい人 -> 型推論の無い静的型付け言語
簡潔に書きたい/読みたい人 -> 動的型付け言語、型推論のある言語
実行時メタプログラミングしたい人 -> 動的型付け言語
静的型安全性が欲しい人 -> 静的型付け言語
型注釈を強制したい人 -> 型推論の無い静的型付け言語
簡潔に書きたい/読みたい人 -> 動的型付け言語、型推論のある言語
実行時メタプログラミングしたい人 -> 動的型付け言語
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がスコープぐらいでの挙動で十分かなー。
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
別にモジュールを補完に使う。型はチェックに使うとか決まってないだろw
それに、モジュールと型が区別できない言語なんて聞いたことがない。
それに、モジュールと型が区別できない言語なんて聞いたことがない。
262 :デフォルトの名無しさん2011/10/23(日) 12:01:51.87
静的型付け言語は処理が追いやすいっていうけど
最近は大規模な開発になるとフレームワークがオブジェクトの生成を隠蔽したり
共通の処理はインターフェースや基底クラスを使って記述したりするから
あんまり追いやすいって感じはしないな
型うんぬんよりフレームワークやパッケージなんかの基礎知識のほうが重要だと思う
最近は大規模な開発になるとフレームワークがオブジェクトの生成を隠蔽したり
共通の処理はインターフェースや基底クラスを使って記述したりするから
あんまり追いやすいって感じはしないな
型うんぬんよりフレームワークやパッケージなんかの基礎知識のほうが重要だと思う
265 :デフォルトの名無しさん2011/10/23(日) 12:13:24.64
>>262
言ってることがずれてるぞ。
オブジェクトの生成をフレームワークがしたからといって
その生成を入れる変数に型は書いてある。
インターフェースや基底クラスを使って記述しているならば、
そのインターフェースや基底クラスを使ってるクラスを
見つけ出さないといけないわけだが、
その見付け出す行為も、型があれば簡単にできる。
基礎知識は大事だからというがそれは別の話で関係ない。型は大事だ。
○○の方が重要だからといって、もう一方の方はどうでもいいと思わせるのは
ただのミスリード。
言ってることがずれてるぞ。
オブジェクトの生成をフレームワークがしたからといって
その生成を入れる変数に型は書いてある。
インターフェースや基底クラスを使って記述しているならば、
そのインターフェースや基底クラスを使ってるクラスを
見つけ出さないといけないわけだが、
その見付け出す行為も、型があれば簡単にできる。
基礎知識は大事だからというがそれは別の話で関係ない。型は大事だ。
○○の方が重要だからといって、もう一方の方はどうでもいいと思わせるのは
ただのミスリード。
267 :デフォルトの名無しさん2011/10/23(日) 12:17:51.26
>>262の言ってることは確かにずれてる。そういう次元の話じゃない。
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と同等のものを作ってみろよ
効率委員だろ
効率委員だろ
266 :デフォルトの名無しさん2011/10/23(日) 12:15:29.90
>>264
効率悪いよ。
それは文字列の扱いが面倒なのと、
メモリの扱いが面倒だから。
お前は卑怯者だ。
効率悪いよ。
それは文字列の扱いが面倒なのと、
メモリの扱いが面倒だから。
お前は卑怯者だ。
268 :デフォルトの名無しさん2011/10/23(日) 12:23:52.99
>>264
Cは弱い型付けの静的言語です。
(効率はともかく、Win32APIで出来ない事は無いんだろうけど)
Cは弱い型付けの静的言語です。
(効率はともかく、Win32APIで出来ない事は無いんだろうけど)
271 :デフォルトの名無しさん2011/10/23(日) 12:46:52.52
>>266
じゃあJavaで作ってみろや
大規模開発なら得意なんだろ?
大規模なCMS作ってミロや
じゃあJavaで作ってみろや
大規模開発なら得意なんだろ?
大規模なCMS作ってミロや
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/
276 :デフォルトの名無しさん2011/10/23(日) 13:25:14.93
>>272
それしかねえのかよ
それしかねえのかよ
279 :デフォルトの名無しさん2011/10/23(日) 14:25:12.54
>>272がJavaでCMS作ってくれるらしいから期待しとこうぜ
269 :デフォルトの名無しさん2011/10/23(日) 12:42:14.17
○○で××と同等のものを作ってみろよ
効率委員だろ
○○に嫌いな言語を
××に無茶な要求を入れてください
効率委員だろ
○○に嫌いな言語を
××に無茶な要求を入れてください
274 :デフォルトの名無しさん2011/10/23(日) 13:11:05.89
それ、5年ぐらい前の知識だろw
やっぱ止まってんのな。否定する人ってその頃から知識が。
やっぱ止まってんのな。否定する人ってその頃から知識が。
277 :デフォルトの名無しさん2011/10/23(日) 14:03:53.92
動的型言語で10-20年前に開拓したものを再実装するのが静的ドカタ言語の使い方
278 :デフォルトの名無しさん2011/10/23(日) 14:20:00.14
>>277
動的型言語の良い所を取り入れつつ、動的型言語より大規模開発に向く
良い事じゃないか
動的型言語の良い所を取り入れつつ、動的型言語より大規模開発に向く
良い事じゃないか
280 :デフォルトの名無しさん2011/10/23(日) 15:01:45.27
動的言語で何が開拓されたんだ?
290 :デフォルトの名無しさん2011/10/23(日) 16:27:58.11
>>280
IDE
ビットマップディスプレイ
GUI
関数プログラミング
オブジェクト指向プログラミング
論理プログラミング
単体テスト
XP/アジャイル開発
IDE
ビットマップディスプレイ
GUI
関数プログラミング
オブジェクト指向プログラミング
論理プログラミング
単体テスト
XP/アジャイル開発
291 :デフォルトの名無しさん2011/10/23(日) 16:34:50.75
何か繋がった
>>287だから、>>290を実験的に作るのが容易で、静的言語で完成度を上げる流れが脈々と・・・
>>287だから、>>290を実験的に作るのが容易で、静的言語で完成度を上げる流れが脈々と・・・
293 :デフォルトの名無しさん2011/10/23(日) 16:42:41.70
>>291
そゆこと
精鋭の動的型プログラマが開拓して、5-10年の試行錯誤を経て定型化した技術を
大量の静的型ドカタがドヤ顔で乱用するわけさw
そゆこと
精鋭の動的型プログラマが開拓して、5-10年の試行錯誤を経て定型化した技術を
大量の静的型ドカタがドヤ顔で乱用するわけさw
281 :デフォルトの名無しさん2011/10/23(日) 15:09:36.59
リスト操作系は大概動的言語のが強いイメージがあるな
282 :デフォルトの名無しさん2011/10/23(日) 15:16:16.14
>>281
どっちかと言うと、それは手続き型か関数型かの問題の様な
どっちかと言うと、それは手続き型か関数型かの問題の様な
283 :デフォルトの名無しさん2011/10/23(日) 15:26:37.29
>>282
でも手続き型でも最近の動的言語って関数型的なリスト操作導入してるの多くね?
俺がそういうのしか触ってないだけ?
でも手続き型でも最近の動的言語って関数型的なリスト操作導入してるの多くね?
俺がそういうのしか触ってないだけ?
286 :デフォルトの名無しさん2011/10/23(日) 16:06:46.85
>>283
うん
だから、動的型か静的型かはあまり関係ないよね
それ言ったらruby/pythonより静的型のhaskell/OCmalの方が得意というイメージ
うん
だから、動的型か静的型かはあまり関係ないよね
それ言ったらruby/pythonより静的型のhaskell/OCmalの方が得意というイメージ
289 :デフォルトの名無しさん2011/10/23(日) 16:15:19.76
>>286
成る程、確かにそうだな
成る程、確かにそうだな
287 :デフォルトの名無しさん2011/10/23(日) 16:08:45.88
動的型付けの方が言語の実装は簡単。
292 :デフォルトの名無しさん2011/10/23(日) 16:38:42.54
MVC
メタプログラミング/レフレクション
イベント駆動
連想配列
も、だいたいLISP/Scheme/Smalltalk界隈だな。
メタプログラミング/レフレクション
イベント駆動
連想配列
も、だいたいLISP/Scheme/Smalltalk界隈だな。
294 :デフォルトの名無しさん2011/10/23(日) 16:58:47.47
GCもLISP発だっけ?
297 :デフォルトの名無しさん2011/10/23(日) 17:19:56.44
>>294
1960に論文が出て、後にLISPに実装された。
1960に論文が出て、後にLISPに実装された。
295 :デフォルトの名無しさん2011/10/23(日) 17:07:21.49
Lispと言えば、昔のCommonLispは手続き型言語の機能を取り込んでたらしいね。
(forとかの実装はその頃らしい)
何の言語の影響受けたんだろ?Fortlan?
(forとかの実装はその頃らしい)
何の言語の影響受けたんだろ?Fortlan?
296 :デフォルトの名無しさん2011/10/23(日) 17:10:00.23
>>295
取り込んでいたも何も、Lispは今も昔も「純粋な関数型ではない」言語だよ
てかFORTRANの影響を受けていない高級言語はほとんど無いだろう
取り込んでいたも何も、Lispは今も昔も「純粋な関数型ではない」言語だよ
てかFORTRANの影響を受けていない高級言語はほとんど無いだろう
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なんて名前のグローバル変数を使っていたとしても、(あくまで仮だからねw)
そこに書きこむコードはほんの数秒で判明するだろう。
そういう場合静的だと情報の把握のスピードが違うんだよね。
なにがどれに依存していてどこで書き換えられてとか
影響範囲の追跡がかなり簡単になる。
仮にdataなんて名前のグローバル変数を使っていたとしても、(あくまで仮だからねw)
そこに書きこむコードはほんの数秒で判明するだろう。
306 :デフォルトの名無しさん2011/10/23(日) 19:27:34.03
>>300
> 仮にdataなんて名前のグローバル変数を使っていたとしても、(あくまで仮だからねw)
> そこに書きこむコードはほんの数秒で判明するだろう。
え?まさか、動的型付け言語では、それができないと思っている?
おまえみたいのがいるから静的型はドカタとか無知とか言われるんだよ (-_-#)
> 仮にdataなんて名前のグローバル変数を使っていたとしても、(あくまで仮だからねw)
> そこに書きこむコードはほんの数秒で判明するだろう。
え?まさか、動的型付け言語では、それができないと思っている?
おまえみたいのがいるから静的型はドカタとか無知とか言われるんだよ (-_-#)
308 :デフォルトの名無しさん2011/10/23(日) 19:33:31.29
>>306
なんでアホらしすぎてスルーされてるものをむしかえすんだ?
相手グループの中で一番アホな人間を狙い撃ちして、相手グループはアホとか言われてもなぁ
なんでアホらしすぎてスルーされてるものをむしかえすんだ?
相手グループの中で一番アホな人間を狙い撃ちして、相手グループはアホとか言われてもなぁ
315 :デフォルトの名無しさん2011/10/23(日) 23:24:13.68
>>306
さすがに、あそこまでのアホは静的型付け派でも一握り
(ぶっちゃけて言えばJavaドカタ)だけだと思ってるよ
さすがに、あそこまでのアホは静的型付け派でも一握り
(ぶっちゃけて言えばJavaドカタ)だけだと思ってるよ
396 :デフォルトの名無しさん2011/10/29(土) 11:07:23.57
>>298で「具体的なデータもあるんだからしょうがない」と書いといて
>>299で根拠を言えと言われたら
>>300を返すようなスレですからねwww
グローバル変数www
>>299で根拠を言えと言われたら
>>300を返すようなスレですからねwww
グローバル変数www
397 :デフォルトの名無しさん2011/10/29(土) 11:17:36.20
>>396
人格否定しかできないの?
人格否定しかできないの?
301 :デフォルトの名無しさん2011/10/23(日) 19:11:28.69
RubyもPython も言語仕様に静的型を全面導入しても問題なさそうだが。
302 :デフォルトの名無しさん2011/10/23(日) 19:20:01.08
>>301
そのためには、実行時メタプログラミングだけじゃなく
コンパイル時メタプログラミングを導入しないといけないだろうね。
そのためには、実行時メタプログラミングだけじゃなく
コンパイル時メタプログラミングを導入しないといけないだろうね。
303 :デフォルトの名無しさん2011/10/23(日) 19:22:28.47
>>302
実装は大変になるが。
C#に似てくるなあ。
実装は大変になるが。
C#に似てくるなあ。
307 :デフォルトの名無しさん2011/10/23(日) 19:28:32.06
>>302
少なくともPythonの場合、型デコレータはコンパイル時メタプログラミングで実装されているが?
少なくともPythonの場合、型デコレータはコンパイル時メタプログラミングで実装されているが?
304 :デフォルトの名無しさん2011/10/23(日) 19:23:06.85
コンパイル時メタプログラミングといっても、
C++みたいなのはだめだよ。
C++は数学的と言うか、定義でメタプログラミングしている。
はっきり言って、定義でメタプログラミングするのは難しい。
じゃなくて、コードでメタプログラミングする。
コンパイル時に(実行時メタプログラミングみたいに)
コードを実行し、そのコードで書き換える。
C++みたいなのはだめだよ。
C++は数学的と言うか、定義でメタプログラミングしている。
はっきり言って、定義でメタプログラミングするのは難しい。
じゃなくて、コードでメタプログラミングする。
コンパイル時に(実行時メタプログラミングみたいに)
コードを実行し、そのコードで書き換える。
305 :デフォルトの名無しさん2011/10/23(日) 19:26:53.90
コンパイル時メタプログラミングが
出来る言語としてPerlがある。
ただ惜しいことに、静的型付け言語ではない。
出来る言語としてPerlがある。
ただ惜しいことに、静的型付け言語ではない。
310 :デフォルトの名無しさん2011/10/23(日) 19:55:11.85
PHPに仕事を奪われて肩身の狭い思いをしているJavaerの先輩こんばんわw
316 :デフォルトの名無しさん2011/10/24(月) 02:56:59.28
PHPって、Javaとか.NETとは競合してないだろう。多分、PythonとかRuby使いたいなあと思いつつ、仕方なく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
マスコミによるブルーカラー=ドカタ、という刷り込みを信じ込んでる人は、ホワイトカラー犯罪課が何故あるのか知らないだろうな。
当時のアメリカのブルーカラーは、生産現場に近い、ぐらいの意味。
当時は単純な事務計算は機械化が進んでいたが、より広い分野の生産現場で使える適切な言語がなかった。
当時のアメリカのブルーカラーは、生産現場に近い、ぐらいの意味。
当時は単純な事務計算は機械化が進んでいたが、より広い分野の生産現場で使える適切な言語がなかった。
321 :デフォルトの名無しさん2011/10/24(月) 10:36:52.93
グローバル変数の件で無知をさらしたので
必死になって話をそらしてるんですね、わかります
必死になって話をそらしてるんですね、わかります
322 :デフォルトの名無しさん2011/10/24(月) 12:52:38.34
効率でまともな事言ってるのはIDEに好意的な連中だけだな
他の連中は人格攻撃や揚げ足取りばかりで聞いてられない
結論は出たね
他の連中は人格攻撃や揚げ足取りばかりで聞いてられない
結論は出たね
324 :デフォルトの名無しさん2011/10/24(月) 13:30:12.80
JavaでWordPressやDrupalやXOOPなど高機能なCMSがない理由を教えてください^^
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みたいなのが生き
残るんじゃないのかな。
325 :uy2011/10/24(月) 14:35:21.29
スレタイワロター
ずいぶん譲歩してきたな
一般的な手法での大規模開発では効率悪いよ
JAVAなんかと同じ方法で大規模開発しようとしたら乙ル
動的言語で大規模開発やるなら、ファイル単位でかなり細かく分ける必要がある
設計できる子が少ない
ずいぶん譲歩してきたな
一般的な手法での大規模開発では効率悪いよ
JAVAなんかと同じ方法で大規模開発しようとしたら乙ル
動的言語で大規模開発やるなら、ファイル単位でかなり細かく分ける必要がある
設計できる子が少ない
329 :デフォルトの名無しさん2011/10/24(月) 16:05:58.79
>>325
んなこたーない
XOOPとか何人の開発者が関わってると思ってんだ?
発想がまるで逆だよ。
動的言語だと担当分けて抱え込むより、
細かなコミットでCIな開発を進めるのが手筋。
んなこたーない
XOOPとか何人の開発者が関わってると思ってんだ?
発想がまるで逆だよ。
動的言語だと担当分けて抱え込むより、
細かなコミットでCIな開発を進めるのが手筋。
353 :uy2011/10/25(火) 02:30:39.21
>>329
日本語読めてる?
お前のレスって俺のレスを太くなぞっただけで
これを逆とか言っちゃうなら、お前の頭が逆なんじゃね?
日本語読めてる?
お前のレスって俺のレスを太くなぞっただけで
これを逆とか言っちゃうなら、お前の頭が逆なんじゃね?
375 :uy2011/10/27(木) 01:57:38.34
>>354
ええええ・・・・・・・やばいよお前
>>325の、どこに「担当」なんて言葉があるの
マジ大丈夫か・・・・・・・
一応、俺の考えとほぼ同じなわけで、uyコテの形式上、ど派手に煽るわけにもいかないから
一人で勘違いして突っ走っちゃうと・・・
対処に・・・困るんすけど・・・
ええええ・・・・・・・やばいよお前
>>325の、どこに「担当」なんて言葉があるの
マジ大丈夫か・・・・・・・
一応、俺の考えとほぼ同じなわけで、uyコテの形式上、ど派手に煽るわけにもいかないから
一人で勘違いして突っ走っちゃうと・・・
対処に・・・困るんすけど・・・
326 :デフォルトの名無しさん2011/10/24(月) 14:38:37.82
CMSの話題を持ち出されると急に反論できないのが静的お片づけ言語愛好者(笑い)
334 :デフォルトの名無しさん2011/10/24(月) 17:21:21.33
PythonベースのCMSなんてあったのか。
いや無いわけはないのだが完全に視野の外だわ。
いや無いわけはないのだが完全に視野の外だわ。
335 :デフォルトの名無しさん2011/10/24(月) 18:00:42.97
そのCMSとやらはDSLだろ
汎用言語の仕様の話からずいぶんと離れたな
それで、そのCMSとやらはチューリング完全なんだよな
そうでないならBrainfuckの方がよほどましなんだけど
汎用言語の仕様の話からずいぶんと離れたな
それで、そのCMSとやらはチューリング完全なんだよな
そうでないならBrainfuckの方がよほどましなんだけど
341 :デフォルトの名無しさん2011/10/24(月) 19:47:41.23
要するに>>335はCMSについて何もしらないけど口だけ出してみたってことだろう
TeXやPostScriptはチューリング完全だけど、ドキュメントフォーマットとして
停止性が判定できないのはまずいから、PDFってわざとループや再帰を外したんだよな
確か
TeXやPostScriptはチューリング完全だけど、ドキュメントフォーマットとして
停止性が判定できないのはまずいから、PDFってわざとループや再帰を外したんだよな
確か
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にチューリング完全を求めるとか、わけわからん。
340 :デフォルトの名無しさん2011/10/24(月) 19:35:29.13
動的静的以前の問題だろ
普通は両方使い分けるし
必要ならチューリング完全でないDSLも作るw
普通は両方使い分けるし
必要ならチューリング完全でないDSLも作るw
342 :デフォルトの名無しさん2011/10/24(月) 20:10:00.58
pythonでCMSなんて見栄張りたい奴だけ
Rubyなんてrorとredmineを除いて素晴らしいフレームワークもCMSも皆無
Rubyなんてrorとredmineを除いて素晴らしいフレームワークもCMSも皆無
350 :デフォルトの名無しさん2011/10/25(火) 00:47:07.75
>>342
Sinatra,Ramaze,Rackなど増えてるだろ
Sinatra,Ramaze,Rackなど増えてるだろ
343 :デフォルトの名無しさん2011/10/24(月) 20:14:04.40
rubyはcmsはないがtwitterが大きいな
性能稼ぐためにjavaに行くみたいだけど
性能稼ぐためにjavaに行くみたいだけど
345 :デフォルトの名無しさん2011/10/24(月) 22:25:04.70
>>343
ぶっちゃけRubyはワンライナーテキストフィルタ特化の言語でいいと思う
ぶっちゃけRubyはワンライナーテキストフィルタ特化の言語でいいと思う
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/
346 :デフォルトの名無しさん2011/10/24(月) 23:06:38.53
それならperlで十分
355 :デフォルトの名無しさん2011/10/25(火) 07:36:10.48
>>346
てか、Rubyってそのポジションを狙ってる言語なんじゃないの?
てか、Rubyってそのポジションを狙ってる言語なんじゃないの?
356 :デフォルトの名無しさん2011/10/25(火) 07:55:44.09
>>355
1ライナー的な短い勝負でperlに勝つのは無理だろう
1pageなら別だが
1ライナー的な短い勝負でperlに勝つのは無理だろう
1pageなら別だが
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/
354 :デフォルトの名無しさん2011/10/25(火) 06:14:54.31
325=uy ファイル単位で担当分けろ!
329 担当分けするな、こまめにコミットしてCIしろ!
どう考えたら同じに見えるんだろうwww
329 担当分けするな、こまめにコミットしてCIしろ!
どう考えたら同じに見えるんだろうwww
357 :デフォルトの名無しさん2011/10/25(火) 12:12:57.87
>>354
担当者を分けるためじゃなく、可読性向上のために
ファイル単位に細分化する(細かすぎるのも良くないが)
特にPerlやPythonはファイルスコープがあるので
スコープを分割する意味もある
担当者を分けるためじゃなく、可読性向上のために
ファイル単位に細分化する(細かすぎるのも良くないが)
特にPerlやPythonはファイルスコープがあるので
スコープを分割する意味もある
358 :デフォルトの名無しさん2011/10/25(火) 14:14:12.88
>>357
何もわかってないドカタだから
> 担当者を分けるためじゃなく、可読性向上のために
> ファイル単位に細分化する(細かすぎるのも良くないが)
みたいな、主語がないクソ文を書いてドヤ顔ができるんだろうな。
何もわかってないドカタだから
> 担当者を分けるためじゃなく、可読性向上のために
> ファイル単位に細分化する(細かすぎるのも良くないが)
みたいな、主語がないクソ文を書いてドヤ顔ができるんだろうな。
360 :デフォルトの名無しさん2011/10/25(火) 21:42:27.86
>>358
ドカタがドカタって言ってるのを見ると
笑えるんだけどwww
ドカタがドカタって言ってるのを見ると
笑えるんだけどwww
376 :uy2011/10/27(木) 02:05:10.16
>>357 は、分かってる
>>358 は、分かってない
ここまで、圧倒的に知識劣ってる相手が
しかも俺ではなく、他の名無しに論破されて発狂しちゃう様を見ると・・・ とても切ない気持ちになる
俺が1レスでトドメをさして論破してやれば、他の名無しに痛いところつかれたレスをくらうこともなかったかもしれない
かれの心のダメージを最小限に抑えられたかもしれない
次からは、やっぱり長文になっても1レスで論破してやるようにするよ。みててかわいそーだ
冬は寒いな.......
>>358 は、分かってない
ここまで、圧倒的に知識劣ってる相手が
しかも俺ではなく、他の名無しに論破されて発狂しちゃう様を見ると・・・ とても切ない気持ちになる
俺が1レスでトドメをさして論破してやれば、他の名無しに痛いところつかれたレスをくらうこともなかったかもしれない
かれの心のダメージを最小限に抑えられたかもしれない
次からは、やっぱり長文になっても1レスで論破してやるようにするよ。みててかわいそーだ
冬は寒いな.......
359 :デフォルトの名無しさん2011/10/25(火) 20:16:50.02
どこにキレるポイントがあったんだよw
好戦的すぎるだろwww
好戦的すぎるだろwww
361 :デフォルトの名無しさん2011/10/25(火) 23:33:44.90
人はなぜ大規模とかグローバルとかセカイとか言いたがるのか
363 :デフォルトの名無しさん2011/10/26(水) 03:30:26.59
「最初に作った時にはこんなに大規模になる予定ではなかったのにー」っていうのは、とてもありがち。
それが、便利だったから、予定以上に使われたわけだが。
それが、便利だったから、予定以上に使われたわけだが。
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
それはハスケラ特有の症例で、心の病の一つ
ハスケルという言語を使っていると、世の中のあらゆる事柄すべてが
ハスケルを中心に廻っているように見えるらしい
従って、あらゆる関数型言語は静的実行かつ静的型付けでなければならないし、
遅延評価が常識であり、一切の副作用は認めようとしない
ハスケラにとって関数型言語とはハスケルのことであり、
その窓から見える世界が彼らのすべて
それはハスケラ特有の症例で、心の病の一つ
ハスケルという言語を使っていると、世の中のあらゆる事柄すべてが
ハスケルを中心に廻っているように見えるらしい
従って、あらゆる関数型言語は静的実行かつ静的型付けでなければならないし、
遅延評価が常識であり、一切の副作用は認めようとしない
ハスケラにとって関数型言語とはハスケルのことであり、
その窓から見える世界が彼らのすべて
583 :デフォルトの名無しさん2011/11/04(金) 19:09:39.19
>>366
368 :デフォルトの名無しさん2011/10/26(水) 12:34:42.64
コボラ、ジャバラ、ハスケラ
どれも思考停止という意味では仲間同士
どれも思考停止という意味では仲間同士
369 :デフォルトの名無しさん2011/10/26(水) 14:22:28.42
>コボラ、ジャバラ、ハスケラ
どこの怪獣だよ
どこの怪獣だよ
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
まだだ、まだ判らんよ。
人類だって、地球上に数百人しかいなかった時期があったからな!
人類だって、地球上に数百人しかいなかった時期があったからな!
377 :デフォルトの名無しさん2011/10/27(木) 06:05:35.20
uyの自演が必死すぎて可哀想…
381 :uy2011/10/27(木) 12:25:09.41
>>377
うわあああああああああwwwwwwwwww
ついに自演とかいいはじめちゃったよおおおおおおおおwwwwwwww
病気wwwwwwwwwwwwww発覚wwwwwwwwwwww
どうするのおまえ???????wwwwwwWWWWWWww
自分を煽る奴は全員uyかwwwwwwwwwww 自分を煽る名無しは全員uyかwwwwwwwww都合がいいなうぇwwwwwwwww
病気かよ・・・・・・・・
うわあああああああああwwwwwwwwww
ついに自演とかいいはじめちゃったよおおおおおおおおwwwwwwww
病気wwwwwwwwwwwwww発覚wwwwwwwwwwww
どうするのおまえ???????wwwwwwWWWWWWww
自分を煽る奴は全員uyかwwwwwwwwwww 自分を煽る名無しは全員uyかwwwwwwwww都合がいいなうぇwwwwwwwww
病気かよ・・・・・・・・
379 :デフォルトの名無しさん2011/10/27(木) 11:11:57.04
罵声
人格攻撃
特定の集団を攻撃
職業や身体的特徴などで差別
主観の押し付け
議論と関係ありそうで無関係な事実を突きつけて反論を要求する
エア敵を作り出して攻撃し始める
議論のルールを守れない奴にプログラムのルールを守れるのだろうか
人格攻撃
特定の集団を攻撃
職業や身体的特徴などで差別
主観の押し付け
議論と関係ありそうで無関係な事実を突きつけて反論を要求する
エア敵を作り出して攻撃し始める
議論のルールを守れない奴にプログラムのルールを守れるのだろうか
380 :デフォルトの名無しさん2011/10/27(木) 12:04:35.20
>>379
纏めると、「詭弁」。
纏めると、「詭弁」。
382 :uy2011/10/27(木) 12:27:47.62
驚いた
最近はこんな奴がいるんだな
そのうちリアルで誰かに説教されても
「こいつuyだろ・・・・・」とか思いはじめそうで怖い
病気だよそれ病気
治療方法は・・・なんだ???
この業界から消えろとしか
最近はこんな奴がいるんだな
そのうちリアルで誰かに説教されても
「こいつuyだろ・・・・・」とか思いはじめそうで怖い
病気だよそれ病気
治療方法は・・・なんだ???
この業界から消えろとしか
383 :デフォルトの名無しさん2011/10/27(木) 12:49:05.71
ゴールのないマラソン
勝利目標のない戦争
走り続けていたらいつかゴールが見えてくる
敵を倒し続けていればいつか戦争は終わる
そうやって全ての人生を費やそうとする無数の人たち
その人たちにゴールがないことを教えてあげたい
敵を倒し続けても戦争は終わらないことを伝えてあげたい
すべてのにちゃんねらーにありがとう
そしてuy君、卒業おめでとう
勝利目標のない戦争
走り続けていたらいつかゴールが見えてくる
敵を倒し続けていればいつか戦争は終わる
そうやって全ての人生を費やそうとする無数の人たち
その人たちにゴールがないことを教えてあげたい
敵を倒し続けても戦争は終わらないことを伝えてあげたい
すべてのにちゃんねらーにありがとう
そしてuy君、卒業おめでとう
406 :デフォルトの名無しさん2011/10/29(土) 13:07:16.42
特定の個人の詭弁を
鸚鵡返しして
集団の見解とみなして攻撃するのか
挑発が目的ってところだな
明確な敵がいて戦って勝ち続ければ俺の勝利と考えてるのなら
>>383
end
議論と討論の区別がついてなくて
議論している人に討論しかけてるというパターンか
鸚鵡返しして
集団の見解とみなして攻撃するのか
挑発が目的ってところだな
明確な敵がいて戦って勝ち続ければ俺の勝利と考えてるのなら
>>383
end
議論と討論の区別がついてなくて
議論している人に討論しかけてるというパターンか
384 :デフォルトの名無しさん2011/10/27(木) 16:31:31.91
自分から「俺の」と書いておきながら必死で否定するuy…
ブザマ (・∇ ・)
ブザマ (・∇ ・)
385 :デフォルトの名無しさん2011/10/27(木) 21:01:25.71
自演かなんかしらんがキモ過ぎる
自宅の壁とお話してて下さいね
自宅の壁とお話してて下さいね
387 :デフォルトの名無しさん2011/10/29(土) 10:04:03.52
平均より上のレベルのチームが使えば
動的言語で効率は上がるけど、
ドカタが使っても効率的かは分からない、か
妥当な結論だな
動的言語で効率は上がるけど、
ドカタが使っても効率的かは分からない、か
妥当な結論だな
388 :デフォルトの名無しさん2011/10/29(土) 10:09:11.52
平均より上でも、人数多くて大規模になれば
動的言語は効率下がるよ。
ただ、人数が多くなると、高いレベルの人ばかり
集めるのはコストもかかるし現実的ではないから
必然的にレベルも下がる。
そこがレベルが原因だと勘違いする元凶だけど、
実際は人数が多くて大規模になれば
レベルに関係なく、効率は下がる。
動的言語は効率下がるよ。
ただ、人数が多くなると、高いレベルの人ばかり
集めるのはコストもかかるし現実的ではないから
必然的にレベルも下がる。
そこがレベルが原因だと勘違いする元凶だけど、
実際は人数が多くて大規模になれば
レベルに関係なく、効率は下がる。
389 :3872011/10/29(土) 10:44:57.62
>>388
俺は386のリンク先の内容を要約しただけだが、
あんたの意見にはデータに基づく根拠があるの?
俺は386のリンク先の内容を要約しただけだが、
あんたの意見にはデータに基づく根拠があるの?
391 :デフォルトの名無しさん2011/10/29(土) 10:49:20.16
>>389
要約になってませんよw
要約になってませんよw
390 :デフォルトの名無しさん2011/10/29(土) 10:48:50.31
主観の押し付け
職業や身体的特徴などで差別
個人の能力の評価
プログラムに関係する話をしていない
文体を丁寧にしたところで
発言の目的が見え透いているから何を考えてるか手に取るようにわかる
自分を天才だと認めて欲しい、自己顕示欲
他人を見下して優越感に浸って虚栄心を満たしたい
自己顕示欲を満たすためにドカタに対するレイシズムを展開する
みんなが黙ってるのはお前に反論できないからじゃなく
関わりたくないから
俺がお前に関わってるのは他人の精神を分析する能力を向上させたいから
お前のために無償の労力や賞賛を投げかける奴はいない
こういう行動で金になるのは政治的目的や企業活動を妨害する目的、ヤクザだな
ネットヤクザ
職業や身体的特徴などで差別
個人の能力の評価
プログラムに関係する話をしていない
文体を丁寧にしたところで
発言の目的が見え透いているから何を考えてるか手に取るようにわかる
自分を天才だと認めて欲しい、自己顕示欲
他人を見下して優越感に浸って虚栄心を満たしたい
自己顕示欲を満たすためにドカタに対するレイシズムを展開する
みんなが黙ってるのはお前に反論できないからじゃなく
関わりたくないから
俺がお前に関わってるのは他人の精神を分析する能力を向上させたいから
お前のために無償の労力や賞賛を投げかける奴はいない
こういう行動で金になるのは政治的目的や企業活動を妨害する目的、ヤクザだな
ネットヤクザ
393 :デフォルトの名無しさん2011/10/29(土) 11:02:43.44
> Rubyプロジェクトはほとんどの場合、他のプロジェクトよりも短く、小規模のようだ。
結局これに尽きるわw
結局これに尽きるわw
395 :デフォルトの名無しさん2011/10/29(土) 11:06:51.12
卑怯な書き方だな
我々天才は
○○を必要としない
××を使う
つまり我々と同じことをやってもバカだと失敗する
反論した奴には、それはお前がバカだからだと最初に釘をさしておいただろう
まじで軽蔑する、支持しない
我々天才は
○○を必要としない
××を使う
つまり我々と同じことをやってもバカだと失敗する
反論した奴には、それはお前がバカだからだと最初に釘をさしておいただろう
まじで軽蔑する、支持しない
405 :デフォルトの名無しさん2011/10/29(土) 12:49:35.76
>>395
それ、静的型厨房の常套句だねえ♪
それ、静的型厨房の常套句だねえ♪
398 :デフォルトの名無しさん2011/10/29(土) 11:20:17.38
Groovy、F#、Python、Smalltalkでも同じような結果(生産性が向上する)
になるかもしれないって書いてるから、ことさら動的型付け言語だけを
贔屓してるわけじゃないんだな
になるかもしれないって書いてるから、ことさら動的型付け言語だけを
贔屓してるわけじゃないんだな
399 :デフォルトの名無しさん2011/10/29(土) 11:24:16.50
動的でも静的でも大体同じだよ
同じというのは肯定でも否定でもないよ
同じというのは肯定でも否定でもないよ
401 :デフォルトの名無しさん2011/10/29(土) 11:47:44.07
Javaがぶっちぎりでウンコなだけで
動的型言語が優れてるわけじゃない
動的型言語が優れてるわけじゃない
403 :デフォルトの名無しさん2011/10/29(土) 12:12:15.36
>>401-402
この2つはワンセットだな
にしてもレスはえぇよwwどんだけwww
この2つはワンセットだな
にしてもレスはえぇよwwどんだけwww
404 :デフォルトの名無しさん2011/10/29(土) 12:28:41.57
他人を自分の思いのままにコントロールすることで得られる全能感でも味わいたいのじゃないの
この争いはわしが育てた
もしくはまじめな話になるのを妨害しているのか
荒らしてる奴の精神分析して理解しておけば
リアルでいやな目に遭うのを回避できるからもっとやって欲しい
この争いはわしが育てた
もしくはまじめな話になるのを妨害しているのか
荒らしてる奴の精神分析して理解しておけば
リアルでいやな目に遭うのを回避できるからもっとやって欲しい
407 :デフォルトの名無しさん2011/10/29(土) 13:19:38.84
討論にしてもルールすら守ってないし
虚栄心を満たしたいのだろうか
自分がバカにしてる他人に認められてうれしいわけないから
ストレス解消程度にしか考えてないのだろうな
もしくは他人に時間を無駄に使わせることに喜びを感じたり
他人が自分のために時間を割くことに喜びを感じてるのだろうか
寂しいからかかまってかまって欲しいの
虚栄心を満たしたいのだろうか
自分がバカにしてる他人に認められてうれしいわけないから
ストレス解消程度にしか考えてないのだろうな
もしくは他人に時間を無駄に使わせることに喜びを感じたり
他人が自分のために時間を割くことに喜びを感じてるのだろうか
寂しいからかかまってかまって欲しいの
408 :デフォルトの名無しさん2011/10/29(土) 16:03:18.69
GoogleとかTwitterみたいな優秀なプログラマー揃いの企業でもDartでJavaScriptに型を導入しようとしたり、Rubyを捨ててScalaへ移行してるわけだからな。
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
>>412
読んでお前が反論しろ。
なんで、相手に読めといって終わるバカが多いのか。
読んでお前が反論しろ。
なんで、相手に読めといって終わるバカが多いのか。
414 :デフォルトの名無しさん2011/10/29(土) 16:53:42.74
型があればより安全に書ける、その代わり、型による制約で記述量が増える。小規模な開発なら型がない方が適してるだろうし、大規模な開発なら型がある方が適してる。
415 :デフォルトの名無しさん2011/10/29(土) 16:54:40.62
馬鹿は型注釈と静的型の区別がつかないので
動的型言語に型注釈を追加しました。
ぶっちゃけコメントと大差ないですが、馬鹿には十分でしょ? < Googleの言い分
動的型言語に型注釈を追加しました。
ぶっちゃけコメントと大差ないですが、馬鹿には十分でしょ? < Googleの言い分
418 :デフォルトの名無しさん2011/10/29(土) 16:59:17.11
あ、やっぱりその程度の認識だったんだ。
Googleがそんな事するわけがないだろ。
常識で考えろやw
Googleがそんな事するわけがないだろ。
常識で考えろやw
419 :デフォルトの名無しさん2011/10/29(土) 17:07:47.89
プログラマの常識で考えると、Dartの規格を見て静的型だと間違えるはずないんだが
土方はその常識の範疇を超えてるからな・・・
ここは土方のレベルすら読み切ったGoogleを褒めるべき。
土方はその常識の範疇を超えてるからな・・・
ここは土方のレベルすら読み切ったGoogleを褒めるべき。
431 :デフォルトの名無しさん2011/10/30(日) 12:12:19.02
>>430
笑w
えっと、解説するとそこは>>419に書いてある文章を
修正したものだから、本当に上から目線なのは>>419なんだよ
笑w
えっと、解説するとそこは>>419に書いてある文章を
修正したものだから、本当に上から目線なのは>>419なんだよ
432 :デフォルトの名無しさん2011/10/30(日) 12:34:49.83
>>431
上から目線なのは文型のせいだと思っちゃうほどドカタなの?
上から目線なのは文型のせいだと思っちゃうほどドカタなの?
420 :デフォルトの名無しさん2011/10/29(土) 17:31:21.72
Googleを褒めるのは静的型付け言語のメリットに気づいた所で、
お前の言うゲスな考えをGoogleがしていることじゃないんだがw
お前の言うゲスな考えをGoogleがしていることじゃないんだがw
421 :デフォルトの名無しさん2011/10/29(土) 17:37:47.49
>>421
お前はよくわかってるからもう来なくていいよ。
お前はよくわかってるからもう来なくていいよ。
422 :デフォルトの名無しさん2011/10/29(土) 17:50:17.84
>>421
俺もそう思うわwwww
俺もそう思うわwwww
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を重用してるのが象徴的だな。
430 :デフォルトの名無しさん2011/10/30(日) 11:57:24.07
> Googleを褒めるのは静的型付け言語のメリットに気づいた所
ドカタがGoogleに上から目線でワロタwww
ドカタがGoogleに上から目線でワロタwww
435 :デフォルトの名無しさん2011/10/31(月) 12:30:15.75
静的なチェックはもう少し厳しくなるんじゃね
実行時のチェックはjs変換ではしないよな
専用vmならやるかもだが
実行時のチェックはjs変換ではしないよな
専用vmならやるかもだが
438 :デフォルトの名無しさん2011/11/01(火) 01:44:36.74
C++を捨てた時のことを思い出す。テンプレを使い込んだプログラミング
にはまった時のことだったな。考え方を抽象化してそれをプログラミング
にしていくと、あまりにも手に負えなくなったので言語を切り替えた。
しばらく前にOcamlとC#の例が紹介された論文があったが、あれ状態で
もういらん。。。 となってしまったな。
にはまった時のことだったな。考え方を抽象化してそれをプログラミング
にしていくと、あまりにも手に負えなくなったので言語を切り替えた。
しばらく前にOcamlとC#の例が紹介された論文があったが、あれ状態で
もういらん。。。 となってしまったな。
440 :デフォルトの名無しさん2011/11/01(火) 09:05:06.90
テンプレート使わなきゃいい話
443 :デフォルトの名無しさん2011/11/01(火) 12:44:31.33
>>440
目的がその場限りの取り組みならそれでOKだが、柔軟性を求めた
作りを考えだすと、途端にシンタックスノイズがすごく邪魔になる。
そんな状況ならば、もっと抽象的な記述が得意な方をやればいい
のではないか?と考えたくらいかな。僕はLispの方に向かったけど
OcamlやHaskellでもよかったかなとは思うところはあるな。
抽象化の記述が弱ければ、とたんに建設資材を組み立てるだけみたいな
プログラミングになりがちで余り頭がいらないから、それならそんな人
に任せばいいだけかな。そうゆうことが好きな人も多いみたいだし。
目的がその場限りの取り組みならそれでOKだが、柔軟性を求めた
作りを考えだすと、途端にシンタックスノイズがすごく邪魔になる。
そんな状況ならば、もっと抽象的な記述が得意な方をやればいい
のではないか?と考えたくらいかな。僕はLispの方に向かったけど
OcamlやHaskellでもよかったかなとは思うところはあるな。
抽象化の記述が弱ければ、とたんに建設資材を組み立てるだけみたいな
プログラミングになりがちで余り頭がいらないから、それならそんな人
に任せばいいだけかな。そうゆうことが好きな人も多いみたいだし。
442 :デフォルトの名無しさん2011/11/01(火) 10:43:47.43
テンプレートが無いC++なんてただの面倒くさいJavaみたいなもの
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++がゴミというのに異存ないがね
450 :デフォルトの名無しさん2011/11/01(火) 16:47:46.70
プリミティブ型が無かろうが、C++で型安全な汎用コンテナ作ろうと思ったらテンプレート必須
451 :デフォルトの名無しさん2011/11/01(火) 16:48:36.56
プログラミング言語や製品や企業や政党や宗教なんかに
過剰な思い入れをする人たちはそれらを物や組織を、その観念を超えて
一つの人格だと認識するようになる傾向にあるらしい
病的なレベルになると「俺がガンダムだ」と言うような
自分そのものだと自称する傾向にあるらしいな
つまり449は自分のことをc++だと思い込んでいるのだと俺は結論付ける
過剰な思い入れをする人たちはそれらを物や組織を、その観念を超えて
一つの人格だと認識するようになる傾向にあるらしい
病的なレベルになると「俺がガンダムだ」と言うような
自分そのものだと自称する傾向にあるらしいな
つまり449は自分のことをc++だと思い込んでいるのだと俺は結論付ける
453 :デフォルトの名無しさん2011/11/01(火) 18:37:26.54
この世界の人って、頭のネジが壊れてるほうがいい仕事をする。
454 :デフォルトの名無しさん2011/11/01(火) 18:58:31.89
巨大なプロジェクトになるなら、静的な方が開発効率もパフォーマンスも高い。
459 :デフォルトの名無しさん2011/11/01(火) 20:45:46.70
>>454
「静的型」と書いて「ドカタ」と読むかんじだな
「静的型」と書いて「ドカタ」と読むかんじだな
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だろう
460 :デフォルトの名無しさん2011/11/01(火) 20:55:44.28
どっちかっつうと
動的型→ドウテキカタ→ドカタ
じゃないのか
動的型→ドウテキカタ→ドカタ
じゃないのか
461 :デフォルトの名無しさん2011/11/01(火) 21:02:26.20
動的言語とか型推論系の言語って 大人数より少人数で開発するのに向いてる
言語だから454のいう事も少し理解できる。無駄に人数が必要な言語ってコスト
の面でもあまりよくないけど、その無駄をふくらませて作らせるのが正しいの
かもね。俺には理解できんが。問題は少数精鋭形に向いてると言っても、その
精鋭を集めるのが大変というジレンマがあるくらいかな。
言語だから454のいう事も少し理解できる。無駄に人数が必要な言語ってコスト
の面でもあまりよくないけど、その無駄をふくらませて作らせるのが正しいの
かもね。俺には理解できんが。問題は少数精鋭形に向いてると言っても、その
精鋭を集めるのが大変というジレンマがあるくらいかな。
463 :デフォルトの名無しさん2011/11/01(火) 21:18:22.36
金さえ出せば少数精鋭を集めるのは難しくないだろう。
相場の数倍とかになるだろうけどなw
で、そうやって高い金だして雇っても
費用対効果をうまく出すのは難しいんだよね。
なぜならプロジェクト全体を見ると難しい所と簡単な所がある。
難しい所ってのは、プロジェクトの基盤の部分だが、量としては少ない。
それに対して、簡単なところは、単純作業的な所は、量は多い。
簡単な所を高い金だして雇った人にさせても無駄が多い。
プロジェクト全体の効率を考えると、簡単なところは新人、下請け、
オフショアなどにやらせるという考えがでてくる。
そうなると、どうしてもコードをコントロールしやすい静的言語になっちゃうんだよね。
相場の数倍とかになるだろうけどなw
で、そうやって高い金だして雇っても
費用対効果をうまく出すのは難しいんだよね。
なぜならプロジェクト全体を見ると難しい所と簡単な所がある。
難しい所ってのは、プロジェクトの基盤の部分だが、量としては少ない。
それに対して、簡単なところは、単純作業的な所は、量は多い。
簡単な所を高い金だして雇った人にさせても無駄が多い。
プロジェクト全体の効率を考えると、簡単なところは新人、下請け、
オフショアなどにやらせるという考えがでてくる。
そうなると、どうしてもコードをコントロールしやすい静的言語になっちゃうんだよね。
464 :デフォルトの名無しさん2011/11/01(火) 21:36:52.83
対人費用のことを考えると 低価格大人数と高価格少人数じゃかわらん
という意見ももっともだな。どこに最適な所があるかはなんとも言えないけど
言ってることはわかるよ。1割の凄腕系と9割のアリで十分という考えは
成り立つかもね。
宇曽かマコトか解からんけど、
ただ、モチベーションが保てない開発言語から別のに移して飛躍的に生産性が
伸びたという報告もあるからなぁ。ScalaとかClojureはそのへんの最右翼なん
だけど、その違いって触った人しかわからないのと、保守的すぎる風土が多い
日本というのが一番問題かもね。
という意見ももっともだな。どこに最適な所があるかはなんとも言えないけど
言ってることはわかるよ。1割の凄腕系と9割のアリで十分という考えは
成り立つかもね。
宇曽かマコトか解からんけど、
ただ、モチベーションが保てない開発言語から別のに移して飛躍的に生産性が
伸びたという報告もあるからなぁ。ScalaとかClojureはそのへんの最右翼なん
だけど、その違いって触った人しかわからないのと、保守的すぎる風土が多い
日本というのが一番問題かもね。
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
表向きの理由→少数精鋭であるっ(キリッ
本当の理由→たくさん雇ったら金がかかるから、バカを天才扱いしてサビ残させて節約すっか
バカ達の会話→俺たち天才だしな、凡人とは違うのだよ凡人とは
ああ、もちろんこのスレの人たちはみんな天才だと思いますけど
たまにいるんですよね勘違いする人が、九割ぐらいの人は勘違いする
でもこのスレの人たちのほとんどは一割の天才だから気にしないでください
本当の理由→たくさん雇ったら金がかかるから、バカを天才扱いしてサビ残させて節約すっか
バカ達の会話→俺たち天才だしな、凡人とは違うのだよ凡人とは
ああ、もちろんこのスレの人たちはみんな天才だと思いますけど
たまにいるんですよね勘違いする人が、九割ぐらいの人は勘違いする
でもこのスレの人たちのほとんどは一割の天才だから気にしないでください
471 :デフォルトの名無しさん2011/11/02(水) 15:41:09.23
反論できないからレッテル貼って挑発してるようにしか見えない
少数精鋭がすごいなんて根拠もデータもないし
歴史上は数の多い勢力が大抵の場合は勝ってる
金がないから少数を育てて少数精鋭にするしかないというのが事実
少数精鋭が常に勝つのであればマイクロソフトもグーグルもアップルも
なんであんなに大きいのだろうな
少数精鋭の方が効率がいいのに
俺は頭が悪いからわからないよ
少数精鋭よりも多人数の方がつおいんじゃないの
少数精鋭がすごいなんて根拠もデータもないし
歴史上は数の多い勢力が大抵の場合は勝ってる
金がないから少数を育てて少数精鋭にするしかないというのが事実
少数精鋭が常に勝つのであればマイクロソフトもグーグルもアップルも
なんであんなに大きいのだろうな
少数精鋭の方が効率がいいのに
俺は頭が悪いからわからないよ
少数精鋭よりも多人数の方がつおいんじゃないの
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
思考停止してるんじゃないの
金がなくて人をたくさん雇えないから権威にすがったり
少数精鋭だと虚勢を張ってるだけじゃないの
そして現状に妥協した結果
人が多くなると管理が難しくなるのは当然
少数精鋭でいいという考えはその難しさから逃げてるだけ
資産を増やして数を増やして管理を考えるのが正道
その道を通ったから大企業になるだろ
大企業になればあらゆる主導権を握るから
弱小企業は常に大企業に振り回される
俺は自分で規模の大きいプログラムを効率よく作る方法を模索してるけど
お前は違うよな
周りがそういってるから
権威が言った、有名な著書にそう書いてあるから
人月の神話を銀の弾丸のように使い出したら、それはギャグでしかないだろ
無数ある戦略を一つに絞って複数の目的に対応しようというのは
組織運営に反している、愚考だろ
金がなくて人をたくさん雇えないから権威にすがったり
少数精鋭だと虚勢を張ってるだけじゃないの
そして現状に妥協した結果
人が多くなると管理が難しくなるのは当然
少数精鋭でいいという考えはその難しさから逃げてるだけ
資産を増やして数を増やして管理を考えるのが正道
その道を通ったから大企業になるだろ
大企業になればあらゆる主導権を握るから
弱小企業は常に大企業に振り回される
俺は自分で規模の大きいプログラムを効率よく作る方法を模索してるけど
お前は違うよな
周りがそういってるから
権威が言った、有名な著書にそう書いてあるから
人月の神話を銀の弾丸のように使い出したら、それはギャグでしかないだろ
無数ある戦略を一つに絞って複数の目的に対応しようというのは
組織運営に反している、愚考だろ
478 :デフォルトの名無しさん2011/11/02(水) 16:19:22.64
指摘のようでただの一方的な決め付けによる憶測ってところがミソな
479 :デフォルトの名無しさん2011/11/02(水) 16:39:49.39
その批判した奴の意見が多数に支持されるようになったら
おまえはそれを素直に受け入れることができるのだろうか
自分の未来を削る覚悟がないのなら他人を批判なんてしないほうがいいよ
お前の否定した技術が必須になったときに受け入れられずに出遅れる
お前の否定した連中と同じ立場になったら発狂するしかないだろ
俺は少数精鋭は選択肢の一つに過ぎず銀の弾丸ではないと主張しただけ
過去のいろいろなジャンルの本を読んで理解した重要な部分を
各所にちりばめてそれをやってるから
俺の発言をすべて批判したら、お前の選択肢が大幅になくなる
そのための長文だ
俺は技術的に減るものはないけど、おれの発言や人格を批判した奴は
様々な選択肢に制約がかかるだろうな
だから存分に俺をバカにしなさい、俺にデメリットはない
部分的な批判されると困るけど、ここまで言われてそれをすると
その無駄に高いプライドに傷がつくよね
おまえはそれを素直に受け入れることができるのだろうか
自分の未来を削る覚悟がないのなら他人を批判なんてしないほうがいいよ
お前の否定した技術が必須になったときに受け入れられずに出遅れる
お前の否定した連中と同じ立場になったら発狂するしかないだろ
俺は少数精鋭は選択肢の一つに過ぎず銀の弾丸ではないと主張しただけ
過去のいろいろなジャンルの本を読んで理解した重要な部分を
各所にちりばめてそれをやってるから
俺の発言をすべて批判したら、お前の選択肢が大幅になくなる
そのための長文だ
俺は技術的に減るものはないけど、おれの発言や人格を批判した奴は
様々な選択肢に制約がかかるだろうな
だから存分に俺をバカにしなさい、俺にデメリットはない
部分的な批判されると困るけど、ここまで言われてそれをすると
その無駄に高いプライドに傷がつくよね
480 :デフォルトの名無しさん2011/11/02(水) 16:45:24.89
>>479
> 俺は少数精鋭は選択肢の一つに過ぎず銀の弾丸ではないと主張しただけ
いや、大人数のほうがいいと言った。
> 俺は少数精鋭は選択肢の一つに過ぎず銀の弾丸ではないと主張しただけ
いや、大人数のほうがいいと言った。
481 :デフォルトの名無しさん2011/11/02(水) 16:47:00.51
よくわからんのだけど、彼の違う意見を持つのは一人という感覚に見える。
482 :デフォルトの名無しさん2011/11/02(水) 17:04:41.75
原発が爆発してからよくわかった
普段から空気読めよと主張している奴が風評ひょーうと言って押し付けてる
明らかに異常な状態の中でクールな俺ら最強じゃねというアホども
何騒いでんだよみっともない、たかが原発が爆発しただけじゃねーか
自分の命を削ってまで周りに合わせようという努力
汚染された空気を読めないくせに俺みたいに空気読めよと押し付ける
ついでに汚染された食い物も押し付ける
これを見てると自分で考えない人たちがいかに危険かがわかる
だから全部疑うことにした
メリットデメリットがはっきりわからないものは全て疑うことにした
そうしなければただちに死ぬ
お前の押し付けているその考えは汚染されている可能性があります
普段から空気読めよと主張している奴が風評ひょーうと言って押し付けてる
明らかに異常な状態の中でクールな俺ら最強じゃねというアホども
何騒いでんだよみっともない、たかが原発が爆発しただけじゃねーか
自分の命を削ってまで周りに合わせようという努力
汚染された空気を読めないくせに俺みたいに空気読めよと押し付ける
ついでに汚染された食い物も押し付ける
これを見てると自分で考えない人たちがいかに危険かがわかる
だから全部疑うことにした
メリットデメリットがはっきりわからないものは全て疑うことにした
そうしなければただちに死ぬ
お前の押し付けているその考えは汚染されている可能性があります
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
多数派の意見を尊重して権力に媚て
少数派の意見をバカにして軽視するハッカーの皆さんへ
もう一度読み返してみてはいかがでしょうか
結局、チキンだから多数派にいなければ落ち着かないんだろ
空気を尊重し多数派に媚びるチキンハッカー
今からハッキングですかお疲れ様です、チキンは照り焼きでお願いします
少数派の意見をバカにして軽視するハッカーの皆さんへ
もう一度読み返してみてはいかがでしょうか
結局、チキンだから多数派にいなければ落ち着かないんだろ
空気を尊重し多数派に媚びるチキンハッカー
今からハッキングですかお疲れ様です、チキンは照り焼きでお願いします
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
さらにその左には依存型の壁があったりする
具体的に言うとモナド則を保証するモナドしか受け付けない型とか書ける
具体的に言うとモナド則を保証するモナドしか受け付けない型とか書ける
499 :デフォルトの名無しさん2011/11/02(水) 22:15:21.12
ヌルやキャストは戦略的撤退のようなもので
それが下手糞なやつは、全滅するまで意地を張るから困る
それが下手糞なやつは、全滅するまで意地を張るから困る
501 :デフォルトの名無しさん2011/11/02(水) 22:23:19.73
アルゴリズムトレードのシステムとかで結構使用例があるみたいだよ
502 :デフォルトの名無しさん2011/11/02(水) 22:36:11.12
haskellはええぞ。haskellはええぞ。haskellはええぞ。haskellはええぞ。
でも、学習時間が比較的長くかかるような気がする。モナドまで理解しようと
しなくてもプログラミングはできる。でも、この言語実際に仕事で
使った人がブログで書いてたのはやっぱり少人数向けなんだなと思った。
haskeller位になるとそれなりにプライドもあるだろうから、俺が俺がになるん
かもしれん。金融系のほうでは関数型つかってるところがチラホラあるらしいね。
外資だったと思うが。
でも、学習時間が比較的長くかかるような気がする。モナドまで理解しようと
しなくてもプログラミングはできる。でも、この言語実際に仕事で
使った人がブログで書いてたのはやっぱり少人数向けなんだなと思った。
haskeller位になるとそれなりにプライドもあるだろうから、俺が俺がになるん
かもしれん。金融系のほうでは関数型つかってるところがチラホラあるらしいね。
外資だったと思うが。
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と比べちゃうと、そういう傾向はあるな
509 :デフォルトの名無しさん2011/11/03(木) 14:57:49.96
またドカ太郎がでてきたのかw
いい加減ドカ太郎はなに言語使っているか言えよ。
>>507-508
お前のことだぞ。
いい加減ドカ太郎はなに言語使っているか言えよ。
>>507-508
お前のことだぞ。
508 :デフォルトの名無しさん2011/11/03(木) 14:43:42.40
無能系ドカタはJavaに走る。開発効率の悪さは
人数とサービス残業で埋め合わせる。
人数とサービス残業で埋め合わせる。
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はポインタの壁があったな。ポインタを理解してたら、動的でも有利だけどな。
515 :デフォルトの名無しさん2011/11/03(木) 16:32:34.74
>>512
参照にはないポインタ特有の発想の壁もあるけど
あれの最大の壁は表記の壁だと思う…例えば
ポインタ宣言時、型のほうではなく変数名のほうに付ける要素であるということ、
それでいて代入時はそれが要らないこと、
配列と混じった場合の優先順位の解りにくさ、関数ポインタのカオス書式
この辺りは表記がもうちょい考慮されてたら脱落者が相当減ると思うのだが…
参照にはないポインタ特有の発想の壁もあるけど
あれの最大の壁は表記の壁だと思う…例えば
ポインタ宣言時、型のほうではなく変数名のほうに付ける要素であるということ、
それでいて代入時はそれが要らないこと、
配列と混じった場合の優先順位の解りにくさ、関数ポインタのカオス書式
この辺りは表記がもうちょい考慮されてたら脱落者が相当減ると思うのだが…
513 :デフォルトの名無しさん2011/11/03(木) 15:32:32.28
ポインタの壁を超えられないバカのためのJavaなのに
ぬるぽで苦しめられるとか皮肉だな
ぬるぽで苦しめられるとか皮肉だな
514 :デフォルトの名無しさん2011/11/03(木) 16:10:47.05
gcでポインタを上手に隠蔽した所で、隠し切れないところは出てくるからね。
でもこの板に来るような人って、最低限そのくらいの壁を超えてそうに思うけど
甘いかな?
でもこの板に来るような人って、最低限そのくらいの壁を超えてそうに思うけど
甘いかな?
516 :デフォルトの名無しさん2011/11/03(木) 17:03:37.21
確かに配列とポインタ変数は紛らわしいが
型にポインタつけるのはC的には無しだろうな
変に参照やらクロージャやらなんやら取り込んだC++はアレだがね
Java位でいんじゃね
型にポインタつけるのはC的には無しだろうな
変に参照やらクロージャやらなんやら取り込んだC++はアレだがね
Java位でいんじゃね
517 :デフォルトの名無しさん2011/11/04(金) 05:08:59.49
高階関数をあつかえるのは関数型言語だけ、みたいな思い込みが多いな。
自画自賛も結構だが、高階関数や遅延評価ぐらいで唯我独尊するのって恥ずかしいよね。
自画自賛も結構だが、高階関数や遅延評価ぐらいで唯我独尊するのって恥ずかしいよね。
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
という定義ができません。これはあまりに非効率で話になりません
524 :デフォルトの名無しさん2011/11/04(金) 09:40:01.44
>>521-522
高階関数ってのは、関数を引数に渡せたり、関数を戻り値にすることができる、関数のことだよね?
関数をカリー化するのは、高階関数を上手く利用した手法だと思うけど、
それを高階関数だって言うのは違うんじゃないの?
高階関数ってのは、関数を引数に渡せたり、関数を戻り値にすることができる、関数のことだよね?
関数をカリー化するのは、高階関数を上手く利用した手法だと思うけど、
それを高階関数だって言うのは違うんじゃないの?
530 :デフォルトの名無しさん2011/11/04(金) 10:49:10.30
>>529
だから>>521はこう書いてるんだから、これは部分適用ではなくカリー化だろう。
>と書いたら sum の型は当然 int->(int->int) になる。
だから>>521はこう書いてるんだから、これは部分適用ではなくカリー化だろう。
>と書いたら sum の型は当然 int->(int->int) になる。
536 :デフォルトの名無しさん2011/11/04(金) 10:57:31.55
>>521において、let incr = sum 1 の操作は部分適用で、
部分適用をこの形式で記述できるなら sum はカリー化されていると言える。
部分適用をこの形式で記述できるなら sum はカリー化されていると言える。
538 :デフォルトの名無しさん2011/11/04(金) 10:59:11.95
>>536
sum は 「intを引数にとって、int->int を返す一引数関数」なんだから
部分適用じゃないよ
sum は 「intを引数にとって、int->int を返す一引数関数」なんだから
部分適用じゃないよ
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 はごく普通の関数適用であり、部分適用ではない。
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
それは高階関数だけじゃなくて、カリー化もサポートしてる言語の話だな
もちろんカリー化があるほうが便利
もちろんカリー化があるほうが便利
525 :デフォルトの名無しさん2011/11/04(金) 10:37:37.08
>>523
正確に言えば、関数の部分適用な。
正確に言えば、関数の部分適用な。
526 :デフォルトの名無しさん2011/11/04(金) 10:40:21.51
>>525
いや、カリー化の方が正確だろう。
いや、カリー化の方が正確だろう。
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にするのは関数適用
527 :デフォルトの名無しさん2011/11/04(金) 10:41:40.23
カリーとかも使えれば便利だけど、分かりにくいよな。
535 :デフォルトの名無しさん2011/11/04(金) 10:55:28.54
OCaml って今でも 3 + 3 = 5 なの?
537 :デフォルトの名無しさん2011/11/04(金) 10:57:57.22
>>535
違うよ、っていうか過去にそんなバージョンあったか?
違うよ、っていうか過去にそんなバージョンあったか?
539 :デフォルトの名無しさん2011/11/04(金) 11:02:02.58
>>537
すまんwネタです。
OCaml のランタイムシステム。GC がポインタと即値を区別できるように
int は左 1 ビットシフトして最下位ビットに 1 を立ててなかったっけ。
すまんwネタです。
OCaml のランタイムシステム。GC がポインタと即値を区別できるように
int は左 1 ビットシフトして最下位ビットに 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
ドカタというか、職業プログラマが時間をかけて関数型プログラミングを深く知るメリットはまだ少ないと思う。
一部LL系のアーリーアダプタが注目して遊んでいるという程度で、
(パイロットプロジェクトを除く)案件で使われる(=業務経歴書上のアピールポイントになる)には、まだ数年かかると思われ。
一部LL系のアーリーアダプタが注目して遊んでいるという程度で、
(パイロットプロジェクトを除く)案件で使われる(=業務経歴書上のアピールポイントになる)には、まだ数年かかると思われ。
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の古さわかってんの? ファーストクラスの関数が〜 と言ってるが。
視野狭くない?
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のように
普通に使われている言語に「当たり前」にある要素だし
インターネット以降の世代では、知識ベースの共有がそれこそ桁違いだ
552 :デフォルトの名無しさん2011/11/04(金) 13:09:12.28
頭が普通ならばさほど時間がかからんと思うよ。問題は手続きやオブジェクト指向
で凝り固まった概念に浸った人。かれらは初心者より違うものを受け付けない傾向
にある。でも、そういった人は淘汰されるから。
速さが違うと言っても日本の中の多くは保守的な国でなかなか悪習を変えないから
その悪癖がどこまで悪影響としてでるかだよね。
で凝り固まった概念に浸った人。かれらは初心者より違うものを受け付けない傾向
にある。でも、そういった人は淘汰されるから。
速さが違うと言っても日本の中の多くは保守的な国でなかなか悪習を変えないから
その悪癖がどこまで悪影響としてでるかだよね。
553 :デフォルトの名無しさん2011/11/04(金) 13:11:52.21
ハードウエアが1CPUで高速化しまくる方向から変わってるからなぁ。
プログラミングも変化せざる負えないよね。実際多CPUにうまく対応
する言語もいくつも出てきてるしね。利用する何か?によってかわるだろうが
プログラミングも変化せざる負えないよね。実際多CPUにうまく対応
する言語もいくつも出てきてるしね。利用する何か?によってかわるだろうが
555 :デフォルトの名無しさん2011/11/04(金) 13:43:33.99
Lisperって態度ばかりでかくて
まともなプログラム作れない屑ばかり
まともなプログラム作れない屑ばかり
556 :デフォルトの名無しさん2011/11/04(金) 13:45:25.00
精鋭云々ということで言うと、日本ではプログラマとしてのセンスと
同等かそれ以上に英語が壁のような気がするな
fizzbuzz書けないのもダメだが、英語できないやつは自動的に精鋭にはなれない
同等かそれ以上に英語が壁のような気がするな
fizzbuzz書けないのもダメだが、英語できないやつは自動的に精鋭にはなれない
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.
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
557 :デフォルトの名無しさん2011/11/04(金) 13:45:40.99
ここ数レスの中で一番態度がでかいのは555ですが、あなたはLisperですか?
558 :デフォルトの名無しさん2011/11/04(金) 13:54:29.35
個人的には、年寄りから若者まで、開発現場の皆が使える言語を使うのが効率的だと思う。
ま、皆が関数型言語を使うようになったら自分もそれに合わせるよ。
開発言語なんて何でもいいよ。俺が合わせるから、主義主張のある人たちで議論してください。
決まったら言って。
つー感じ。どーでもいい
ま、皆が関数型言語を使うようになったら自分もそれに合わせるよ。
開発言語なんて何でもいいよ。俺が合わせるから、主義主張のある人たちで議論してください。
決まったら言って。
つー感じ。どーでもいい
563 :デフォルトの名無しさん2011/11/04(金) 15:11:27.48
>>558
それと同じ主張は何か開発関係の本でも書いてたな
プロジェクトを成功させたかったら、皆の慣れ親しんだ言語を使え。みたいな
それと同じ主張は何か開発関係の本でも書いてたな
プロジェクトを成功させたかったら、皆の慣れ親しんだ言語を使え。みたいな
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.
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でやれとか言われても困るだろ
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/
567 :デフォルトの名無しさん2011/11/04(金) 16:15:00.64
>>565
つまり関数型言語はオブジェクト指向的モデルを表現できない、
その程度の劣った言語ということだね。
つまり関数型言語はオブジェクト指向的モデルを表現できない、
その程度の劣った言語ということだね。
568 :デフォルトの名無しさん2011/11/04(金) 16:28:31.49
いや、Javaのような言語は劣ってるとしか書いてないよね?
569 :デフォルトの名無しさん2011/11/04(金) 16:58:13.32
>>568
キミ、読解力が絶望的に低いねw
キミ、読解力が絶望的に低いねw
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はそんなに簡単ではないと思う
静的型と実行時型情報が共存していたら混乱するのが普通だろう
静的型と実行時型情報が共存していたら混乱するのが普通だろう
581 :デフォルトの名無しさん2011/11/04(金) 19:00:28.30
>>576
じゃあHaskellもだめだな
じゃあHaskellもだめだな
577 :デフォルトの名無しさん2011/11/04(金) 17:45:28.99
まあコボラの二の舞にだけはなるなよ
Javaの仕事はすぐにはなくならないだろうから、それをやっていればいい
若い人に無理やりCOBOLのやりかたを押し付けることだけはするな
Javaの仕事はすぐにはなくならないだろうから、それをやっていればいい
若い人に無理やりCOBOLのやりかたを押し付けることだけはするな
578 :デフォルトの名無しさん2011/11/04(金) 18:43:59.68
まぁまぁそんな怒りなさんな。その元記事って
excelのチーフマネージャーだろ?Haskellとは関係ない人ちゃう?
excelのチーフマネージャーだろ?Haskellとは関係ない人ちゃう?
579 :デフォルトの名無しさん2011/11/04(金) 18:53:24.46
頭を固くしないためにも2,3年に一つは新しい言語にトライすることは
いいよ。年寄りが頭が硬いと思われてるは新しいことにトライする気力が
生まれないから。新しいものにトライするのがダリーっていうタイプは、
年齢にかかわらず終わってるのは事実かも。
いいよ。年寄りが頭が硬いと思われてるは新しいことにトライする気力が
生まれないから。新しいものにトライするのがダリーっていうタイプは、
年齢にかかわらず終わってるのは事実かも。
582 :デフォルトの名無しさん2011/11/04(金) 19:01:46.18
>>579
ハスケラはハスケル最高で思考停止だけどな
ハスケラはハスケル最高で思考停止だけどな
580 :デフォルトの名無しさん2011/11/04(金) 18:55:06.63
1年に一つとか言うのもあるけど流石にそれは浅くなりすぎるからな
2,3年に一つは丁度いいと思う
2,3年に一つは丁度いいと思う
584 :デフォルトの名無しさん2011/11/04(金) 19:12:20.61
C言語は、新しいアセンブリ言語にトライする人達にひどいことをしたよね
593 :デフォルトの名無しさん2011/11/04(金) 20:13:44.88
>>584
アセンブリは言語じゃねーよ
ただの命令の羅列だろうが
アセンブリは言語じゃねーよ
ただの命令の羅列だろうが
594 :デフォルトの名無しさん2011/11/04(金) 20:26:09.24
>>593
プログラミング言語ではないが
言語ではあると思うよ流石に
プログラミング言語ではないが
言語ではあると思うよ流石に
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++が無理程度のやつは
どっちにしろ大したもんは作れない
592 :デフォルトの名無しさん2011/11/04(金) 20:09:19.44
>>589
C++は書くのは簡単だが他人のコードを読むのは辛い
Perlみたいなもん
C++は書くのは簡単だが他人のコードを読むのは辛い
Perlみたいなもん
590 :デフォルトの名無しさん2011/11/04(金) 19:49:41.34
結局お前たちの努力なんてやらなくていい努力を全部排除して
必要最小限の部分だけの努力なんだ
生活するための努力、立場を得るための努力
環境を得るための努力、それら様々な努力をしなくても
生まれつき持っている
お前は勉強する努力だけでいいんだからな
それだけやって楽に高学歴を得て、時間が余ったから言語オタやって気楽でいいよな
一度何もかも捨ててやらなくてもよかった努力をすべてやった上で
言語オタやれるんだったら
それで認めてやるよ
必要最小限の部分だけの努力なんだ
生活するための努力、立場を得るための努力
環境を得るための努力、それら様々な努力をしなくても
生まれつき持っている
お前は勉強する努力だけでいいんだからな
それだけやって楽に高学歴を得て、時間が余ったから言語オタやって気楽でいいよな
一度何もかも捨ててやらなくてもよかった努力をすべてやった上で
言語オタやれるんだったら
それで認めてやるよ
597 :デフォルトの名無しさん2011/11/04(金) 22:01:42.83
すっかり動的型付けとは関係無い話になったな
まあ高階関数やクロージャの有無に比べれば静的/動的なんて些細な違いだからな
まあ高階関数やクロージャの有無に比べれば静的/動的なんて些細な違いだからな
601 :デフォルトの名無しさん2011/11/05(土) 07:57:09.79
高階関数やクロージャがあっても動的型付けではどうしようもない
動的型つけ言語で効率がいいのは手のひらサイズまで
動的型つけ言語で効率がいいのは手のひらサイズまで
603 :デフォルトの名無しさん2011/11/05(土) 08:31:10.27
20万行のC++をschemeで書き換えたら3万行。
たしかにコンパクトになる。>>601 無駄に膨れてるから錯覚を起こすのでは?
たしかにコンパクトになる。>>601 無駄に膨れてるから錯覚を起こすのでは?
602 :デフォルトの名無しさん2011/11/05(土) 08:17:28.79
逆だろ。クロージャなんてあってもなくてもどうにでもなるけど、型付けが静的か動的かって言うのは致命的な差を生む。
604 :デフォルトの名無しさん2011/11/05(土) 09:03:03.73
致命的と確定すれば後は開き直るだけだが
静的と動的が入り乱れる言語を選ぶと、一挙手一投足が致命傷となりうる恐怖の連続
静的と動的が入り乱れる言語を選ぶと、一挙手一投足が致命傷となりうる恐怖の連続
608 :デフォルトの名無しさん2011/11/05(土) 12:02:36.23
>>604
OCaml最強伝説の幕開けか
あれは完全に静的だからな
OCaml最強伝説の幕開けか
あれは完全に静的だからな
605 :デフォルトの名無しさん2011/11/05(土) 09:56:41.96
多分Java8にクロージャが入るまで
クロージャなんて重要じゃないと言い続けるよ
だってJavaドカタだから
クロージャなんて重要じゃないと言い続けるよ
だってJavaドカタだから
606 :デフォルトの名無しさん2011/11/05(土) 11:55:20.35
>20万行のC++をschemeで書き換えたら3万行
脳内移植御苦労さん
脳内移植御苦労さん
637 :デフォルトの名無しさん2011/11/05(土) 15:10:23.16
644 :デフォルトの名無しさん2011/11/05(土) 15:37:49.69
>>637
glueコードとか静的言語だけで開発していれば必要ないコード
本来必要ないコードの量が減ったとかいばられても困るわ
glueコードとか静的言語だけで開発していれば必要ないコード
本来必要ないコードの量が減ったとかいばられても困るわ
653 :デフォルトの名無しさん2011/11/05(土) 16:49:48.92
>>644
減ったコードの大部分がglueコードだと思っちゃったの?
どうやったらそんなにアホになれるの?
減ったコードの大部分がglueコードだと思っちゃったの?
どうやったらそんなにアホになれるの?
607 :デフォルトの名無しさん2011/11/05(土) 11:58:40.13
http://groups.google.com/group/clojure/browse_thread/thread/b18f9006c068f0a0?pli=1
短く書けると噂のScalaでも、
Clojureと比べるとこんだけ差が出るんだな
短く書けると噂のScalaでも、
Clojureと比べるとこんだけ差が出るんだな
609 :デフォルトの名無しさん2011/11/05(土) 12:23:14.30
>>607
たったの1000行とかw
スレタイ読めないのかよ
たったの1000行とかw
スレタイ読めないのかよ
610 :デフォルトの名無しさん2011/11/05(土) 12:25:15.11
>>609
読んだらプログラム書いた奴が未熟なだけって結論出てるじゃねえかよ
アホか
読んだらプログラム書いた奴が未熟なだけって結論出てるじゃねえかよ
アホか
611 :デフォルトの名無しさん2011/11/05(土) 12:26:44.29
>>609
1000行が100万行になったら比率が変わるのか?
どんな理屈で?
1000行が100万行になったら比率が変わるのか?
どんな理屈で?
612 :デフォルトの名無しさん2011/11/05(土) 12:30:16.88
1000行以上のプログラム書いたことない奴は帰れよ
642 :デフォルトの名無しさん2011/11/05(土) 15:29:41.07
>>612
1000行ってのはたった 1Kstep なんだが....
せめて 10000行(10Kstep) と言って欲しかった
このくらいになるとモジュール化されたコード設計が必要になる
それ以下だとプログラム全体の構造を頭の中で把握できるから、
どんな言語でもコーディング技法(テクニック)で乗り切れてしまう
1000行ってのはたった 1Kstep なんだが....
せめて 10000行(10Kstep) と言って欲しかった
このくらいになるとモジュール化されたコード設計が必要になる
それ以下だとプログラム全体の構造を頭の中で把握できるから、
どんな言語でもコーディング技法(テクニック)で乗り切れてしまう
613 :デフォルトの名無しさん2011/11/05(土) 12:32:04.28
ああ、1000行以上のプログラム書いた事無いから
大規模になったら「理由も無く」差が無くなると思っちゃったんだね
大規模になったら「理由も無く」差が無くなると思っちゃったんだね
614 :デフォルトの名無しさん2011/11/05(土) 12:35:09.68
1000行以上のプログラム書いたことないの
おまえだろw
おまえだろw
645 :デフォルトの名無しさん2011/11/05(土) 15:39:36.03
>>614
なんとかなるものだよ
たとえばRubyでは
target = source_array.select {.....}.sort_by {.....}.map {.....}.inject(...) {.....}
みたいなコードを書く (実際にはコードを折り曲げるから、1文が数十行になる)
このコードの " {.....} " の部分がブロック(クロージャ)だから、
これは構文糖に包まれた高階関数であると言えるんじゃないかな?
もちろんブロック内で副作用のあるコードは書かない!という規律(モラル)が前提だけどね
なんとかなるものだよ
たとえばRubyでは
target = source_array.select {.....}.sort_by {.....}.map {.....}.inject(...) {.....}
みたいなコードを書く (実際にはコードを折り曲げるから、1文が数十行になる)
このコードの " {.....} " の部分がブロック(クロージャ)だから、
これは構文糖に包まれた高階関数であると言えるんじゃないかな?
もちろんブロック内で副作用のあるコードは書かない!という規律(モラル)が前提だけどね
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を駆使すれば
異様にコードを圧縮する事も可能だが、保守は絶望的・・・
異様にコードを圧縮する事も可能だが、保守は絶望的・・・
638 :デフォルトの名無しさん2011/11/05(土) 15:11:48.69
>>617
そうでもないよ。マクロの使うセンスによるから。
そうでもないよ。マクロの使うセンスによるから。
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
ある規模を超えるとどっちにしろ殆どの人間にとって扱え切れない化け物になってしまうのは割と共通しているんじゃね?w
そういう意味では差が縮まると言っていいかも
そういう意味では差が縮まると言っていいかも
622 :デフォルトの名無しさん2011/11/05(土) 13:19:20.61
>>620
動的型付けの場合は殆どじゃなくて全ての人間でしょ
動的型付けの場合は殆どじゃなくて全ての人間でしょ
623 :デフォルトの名無しさん2011/11/05(土) 13:47:41.05
てか作るもので言語選べばいいだけだろ…
まさか一つの言語しか使えないワケでもあるまいし
でもjavaにクロージャはいらんよな
まさか一つの言語しか使えないワケでもあるまいし
でもjavaにクロージャはいらんよな
625 :デフォルトの名無しさん2011/11/05(土) 13:56:23.65
作るものによって換えざるを得ない状況を一つの言語でできるようにするってのも
Javaをはじめとする汎用プログラミング言語の目的だったはず
Javaをはじめとする汎用プログラミング言語の目的だったはず
626 :デフォルトの名無しさん2011/11/05(土) 13:57:13.13
ま、ドカタには複数の言語を覚える脳みそがないっつーことで
628 :デフォルトの名無しさん2011/11/05(土) 14:45:25.21
工具マニアじゃねーんだから
家建てられれば工具なんか何でもいい
家建てられれば工具なんか何でもいい
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
>>631
その組み合わせはもう古いだろ
今の純粋培養はPHP+C#だ
その組み合わせはもう古いだろ
今の純粋培養はPHP+C#だ
633 :デフォルトの名無しさん2011/11/05(土) 14:57:14.09
純粋培養PHPerは可哀想だから煽る気にもならん
強く生きてほしい
強く生きてほしい
634 :デフォルトの名無しさん2011/11/05(土) 14:59:13.52
「ドカタ」ってのはこのくらいが最低限。
C の読み書きに不自由しない
何か一つのアセンブリを読める
JavaでもC#でも、手続き型オブジェクト指向言語を何か一つ使いこなせる
スクリプト言語を何か一つ使いこなせる
このくらいの素養がない奴はドカタですらない。ただのガキ
C の読み書きに不自由しない
何か一つのアセンブリを読める
JavaでもC#でも、手続き型オブジェクト指向言語を何か一つ使いこなせる
スクリプト言語を何か一つ使いこなせる
このくらいの素養がない奴はドカタですらない。ただのガキ
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
高階関数を使い出すと型推論のある静的型付け言語じゃないと悲惨なことになると思うんだけどそうでもないのかな
651 :6452011/11/05(土) 15:53:06.43
アンカを間違えた
誤 >>614
正 >>641
誤 >>614
正 >>641
643 :デフォルトの名無しさん2011/11/05(土) 15:34:09.49
大規模ってどのくらいだろうね
もちろん言語によると思うけど、Cなら100万行超えたら大規模って言って大丈夫?
10万行オーダーは人によって意見がわかれそう。1万行は確実に小規模だよね?
もちろん言語によると思うけど、Cなら100万行超えたら大規模って言って大丈夫?
10万行オーダーは人によって意見がわかれそう。1万行は確実に小規模だよね?
646 :デフォルトの名無しさん2011/11/05(土) 15:42:12.38
読みやすいコードを書く人とそうでない人の差って、先のことを考えて
るかどうかだよ。
るかどうかだよ。
647 :デフォルトの名無しさん2011/11/05(土) 15:43:13.55
かいているときは気持ちいいだけど
かきおわったら萎える
かきおわったら萎える
649 :デフォルトの名無しさん2011/11/05(土) 15:47:13.64
認めたがらないときはくだらないとか難癖はつけるもの。
このスレならそれでいいのではないだろうか?所詮俺が正しいことを
押し付けるスレです。
このスレならそれでいいのではないだろうか?所詮俺が正しいことを
押し付けるスレです。
650 :デフォルトの名無しさん2011/11/05(土) 15:53:02.46
一万行超えたら全部把握するのは無理
大雑把にあの辺にあれがあるという程度になってるから
力押しでやるのは不可能だろ
だから可読性とテストを優先してる
このレベルからインターフェースやアブストラクトがものすごく便利になってくる
コードを短くするよりもわかりやすい名前の方が重要
大雑把にあの辺にあれがあるという程度になってるから
力押しでやるのは不可能だろ
だから可読性とテストを優先してる
このレベルからインターフェースやアブストラクトがものすごく便利になってくる
コードを短くするよりもわかりやすい名前の方が重要
652 :デフォルトの名無しさん2011/11/05(土) 15:56:59.79
>>641
カリー化が無ければ問題ないんじゃね?
>>650
俺ヘタレだからタグジャンプ無しでは他人のコードは読めんわ
カリー化が無ければ問題ないんじゃね?
>>650
俺ヘタレだからタグジャンプ無しでは他人のコードは読めんわ
654 :デフォルトの名無しさん2011/11/05(土) 17:31:23.73
こんなんおおいばりで書いてあるくらいだから
他も部分も大したことないのは
容易に想像がつくだろ
他も部分も大したことないのは
容易に想像がつくだろ
657 :デフォルトの名無しさん2011/11/05(土) 18:26:13.39
でもこれって使用するGUIライブラリが変更されてるから
c++とschemeの公平な比較になってないわ
c++とschemeの公平な比較になってないわ
658 :デフォルトの名無しさん2011/11/05(土) 18:34:35.79
静的言語に寄生している分際で
行数が1/10になるぞとかいばりちらして
頭おかしいのな
行数が1/10になるぞとかいばりちらして
頭おかしいのな
661 :デフォルトの名無しさん2011/11/05(土) 18:47:56.13
>>658
寄生してるって表現自体がキモいけど、
そういう意味ではVM言語は大体C/C++に寄生してるけどな
例えばJavaとか
寄生してるって表現自体がキモいけど、
そういう意味ではVM言語は大体C/C++に寄生してるけどな
例えばJavaとか
670 :デフォルトの名無しさん2011/11/05(土) 19:13:08.23
じゃあ>>658は何のつもりで書いたんだよバカが
本当に低能だな
本当に低能だな
659 :デフォルトの名無しさん2011/11/05(土) 18:42:35.21
なんか どうしても認められない人がいるのね。たしかに頭がおかしい。
おかしい人から正常な人を見たら頭がおかしく見えるというのもあなが
ち嘘ではないというのは658が示してる悲しい現実がある。
おかしい人から正常な人を見たら頭がおかしく見えるというのもあなが
ち嘘ではないというのは658が示してる悲しい現実がある。
660 :デフォルトの名無しさん2011/11/05(土) 18:45:05.86
637はいい加減自分の馬鹿さ加減を自覚しろよ
666 :デフォルトの名無しさん2011/11/05(土) 19:00:50.25
>>660
馬鹿だな。一人で戦ってシャドウボクシングをやってるように見てるのか。
馬鹿だな。一人で戦ってシャドウボクシングをやってるように見てるのか。
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チップで動かせばおけ
665 :デフォルトの名無しさん2011/11/05(土) 18:56:53.21
>>663
そしたらGroovyやClojureも動いちゃうだろ
そしたらGroovyやClojureも動いちゃうだろ
667 :デフォルトの名無しさん2011/11/05(土) 19:03:07.40
>>665
その2つはJavaに寄生してるだろ
その2つはJavaに寄生してるだろ
664 :デフォルトの名無しさん2011/11/05(土) 18:53:09.05
減りやすいのは、map,reduce(fold),filterなどを
多用しだすと、それだけでも全然違うよね。
考えなくてもC++より関数型のほうが行数が減るというのは必然的
だと思うんだがな。
コンパクトになることを認めたがらないってやっぱりオツムの問題だと思うよ。
多用しだすと、それだけでも全然違うよね。
考えなくてもC++より関数型のほうが行数が減るというのは必然的
だと思うんだがな。
コンパクトになることを認めたがらないってやっぱりオツムの問題だと思うよ。
668 :デフォルトの名無しさん2011/11/05(土) 19:10:02.34
Javaチップとかバカ過ぎ
つーかネイティブコンパイルできるか否かと
型付けは関係ねーだろアホか
つーかネイティブコンパイルできるか否かと
型付けは関係ねーだろアホか
671 :デフォルトの名無しさん2011/11/05(土) 19:18:07.64
658のどこに
ネイティブコンパイルと型付けの関係が書いてあるんだよw
脳内で誰かと会話でもしてるん?www
ネイティブコンパイルと型付けの関係が書いてあるんだよw
脳内で誰かと会話でもしてるん?www
676 :デフォルトの名無しさん2011/11/05(土) 19:23:43.83
>>671
じゃあ静的言語に寄生してるって言葉の意味を定義しろよ
それは型付けと関係あるんだよな?
じゃあ静的言語に寄生してるって言葉の意味を定義しろよ
それは型付けと関係あるんだよな?
672 :デフォルトの名無しさん2011/11/05(土) 19:18:46.45
結局、動的型付け言語で大規模開発やった方が効率が良いみたいだな
そもそもコード量が断然少なくなるからな
そもそもコード量が断然少なくなるからな
675 :デフォルトの名無しさん2011/11/05(土) 19:22:45.64
静的型言語と比較して少ないって意味だろ
頭おかしいレベルで馬鹿だな
頭おかしいレベルで馬鹿だな
677 :デフォルトの名無しさん2011/11/05(土) 19:24:50.48
コード量減ってもせいぜい2割くらいで
大規模に到達する前にメンテナンス不能のゴミになるのが関の山
大規模に到達する前にメンテナンス不能のゴミになるのが関の山
678 :デフォルトの名無しさん2011/11/05(土) 19:26:56.67
き‐せい【寄生】
2 他の働きなどに頼り、生きていくこと。「芸能界に―する」
馬鹿のために辞書引いてやったぞ
2 他の働きなどに頼り、生きていくこと。「芸能界に―する」
馬鹿のために辞書引いてやったぞ
679 :デフォルトの名無しさん2011/11/05(土) 19:28:54.86
ブートストラップできるネイティブコンパイラをもつLispは
一体何に寄生してるの?
一体何に寄生してるの?
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ライブラリが書けるじゃん
698 :デフォルトの名無しさん2011/11/05(土) 20:45:41.33
もし>>683が静的言語を静的型付け言語と区別して使ってたんなら、
コードが1/10に減るって話はどこから来たんだろうね?
C++とRacketの比較なら、ちょうど8万行が8千行に減ったという例があるわけだけど
コードが1/10に減るって話はどこから来たんだろうね?
C++とRacketの比較なら、ちょうど8万行が8千行に減ったという例があるわけだけど
700 :デフォルトの名無しさん2011/11/05(土) 21:02:06.89
>>698
コード見てみないとなんとも評価できないよね。
こういうのはベンチマークと同じで、
一方はひどいコード書いてることが多いからさ。
ループで出来るようなことを何十回もコピペしていたりしてなw
コード見てみないとなんとも評価できないよね。
こういうのはベンチマークと同じで、
一方はひどいコード書いてることが多いからさ。
ループで出来るようなことを何十回もコピペしていたりしてなw
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万行と書いてたからだね
692 :デフォルトの名無しさん2011/11/05(土) 20:30:38.96
>>689
それだとどう読んでも
C++で書かれてたとは思わないだろ
馬鹿以外は
それだとどう読んでも
C++で書かれてたとは思わないだろ
馬鹿以外は
691 :デフォルトの名無しさん2011/11/05(土) 20:30:31.76
静的言語換算で80万行・・・実際に静的言語で書いてみたら10万行でした。とかなw
694 :デフォルトの名無しさん2011/11/05(土) 20:32:12.07
いや、C++で8万行のコードが静的言語換算で80万行って意味分からんでしょう
Racketで8万行ならともかく
Racketで8万行ならともかく
696 :デフォルトの名無しさん2011/11/05(土) 20:35:39.46
>>694
いやC++は動的言語だよ。動的言語で静的型付け言語。
動的言語ってのは分かるよね?
インターフェースとか継承があって、実行時に呼び出すメソッドが決まる方式。
ちなみに型が静的に決まるのが静的型付け。
いやC++は動的言語だよ。動的言語で静的型付け言語。
動的言語ってのは分かるよね?
インターフェースとか継承があって、実行時に呼び出すメソッドが決まる方式。
ちなみに型が静的に決まるのが静的型付け。
695 :デフォルトの名無しさん2011/11/05(土) 20:33:49.48
静的言語と動的言語なら10倍ぐらい差が出てもおかしくはないが、
静的型付けと動的型付け言語じゃ、そうとう動的型付け言語に
有利な例題じゃない限り、そんなに差はでないだろう。
静的型付けと動的型付け言語じゃ、そうとう動的型付け言語に
有利な例題じゃない限り、そんなに差はでないだろう。
697 :デフォルトの名無しさん2011/11/05(土) 20:37:55.89
静的言語ってのはCOBOLやFortlanや古いBASICみたいなもの。
関数があって、それを呼び出すコードがあって、
この結合が実行前に全部決まってしまうもの。
関数があって、それを呼び出すコードがあって、
この結合が実行前に全部決まってしまうもの。
699 :デフォルトの名無しさん2011/11/05(土) 20:48:56.36
このスレで動的言語と言ったら動的型付け言語のこと
動的バインディングとは関係ない
動的バインディングとは関係ない