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

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

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

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

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

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

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

2 :デフォルトの名無しさん:2013/03/03(日) 18:27:44.07
ここが次スレか。でJava厨はこれのどの辺に問題があると思ってんの?
このやり方でDIとして不十分だと思ってるのはなんだい?
Martin fowlerの話を読む限り問題は無さそうだが?

"依存排除側"
object := DI type1 new.
object := DI type2 typeWithValue:0.

DI type3
subclass:#type
instanceVariable:''
classVariable:''
poolDictionary:''
category:'Independency'.

"依存注入側"
DI type1: Integer.
DI type2: TypeForIntegerFactory.
DI type3: Integer.

"或いは"
delegate := Factory new.
DI type1: delegate.

"別解としてClass辞書を直接書き換えてしまう"
OldType := Type1.
System classDictionary replaceClass: #Type1 ToClass: #Integer.

3 :デフォルトの名無しさん:2013/03/03(日) 18:30:09.11
あとこれもつけとくか
初期値を設定する例

943 デフォルトの名無しさん sage 2013/03/02(土) 22:07:33.46
"注入側"
DI type1: NewDelegate withBlock:[Integer integerWithInteger:0.].

"依存排除側"
DI type1 new."Integer integerWithInteger:0.の戻り値が返される"

ね。簡単でしょ。

4 :デフォルトの名無しさん:2013/03/03(日) 18:37:41.49
>>2
関係ないスレに出てくるな
キモいよお前

5 :デフォルトの名無しさん:2013/03/03(日) 18:41:06.37
主張してる内容は真逆なのに、何故か同じ奴が立てたような気がしてならない
そんな低レベルなスレ

http://toro.2ch.net/test/read.cgi/tech/1362301911/

6 :デフォルトの名無しさん:2013/03/03(日) 18:45:21.02
リファクタリングじゃ対抗できないから
スレタイ変えただけだろ

7 :デフォルトの名無しさん:2013/03/03(日) 18:47:01.43
いいよココが隔離スレで

8 :デフォルトの名無しさん:2013/03/03(日) 18:48:15.22
前スレ


リファクタリングがしやすいのは、静的型付け言語
http://toro.2ch.net/test/read.cgi/tech/1339324882/

9 :デフォルトの名無しさん:2013/03/03(日) 19:01:12.25
>>6
次スレすでにあるぞ? 何言ってるんだ?

リファクタリングがしやすいのは、静的型付け言語 2
http://kohada.2ch.net/test/read.cgi/prog/1362301684/

1 名前:仕様書無しさん[sage] 投稿日:2013/03/03(日) 18:08:04.99
Eclipse JDT のリファクタリング機能を探る
http://www.ibm.com/developerworks/jp/opensource/library/os-eclipse-refactoring/

まあ、まずこれを読みましょう。

Eclipseが凄いだけ? 半分間違っています。
静的型付け言語が凄いから、Eclipseもここまで便利な機能を搭載できるのです。

いくらEclipseでも、動的型付け言語に同レベルの機能は搭載できません。
実際されてません。


前スレ
http://toro.2ch.net/test/read.cgi/tech/1339324882/

10 :デフォルトの名無しさん:2013/03/03(日) 19:09:20.53
>>6
ム板じゃ対抗できないから、マ板に立てたらしいぞ(>>9)

11 :デフォルトの名無しさん:2013/03/03(日) 19:33:07.93
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

                  京都大学霊長類研究所

12 :デフォルトの名無しさん:2013/03/03(日) 20:30:04.87
>>10
ム版に立てて欲しいのか?
それなら俺が立てるけど?

13 :デフォルトの名無しさん:2013/03/03(日) 21:50:03.33
>>12
面倒くさいからこのスレ使えよ

14 :デフォルトの名無しさん:2013/03/04(月) 03:52:56.47
埋もれてる限り無価値に等しいのはお前等のチンコが証明してるだろ
潜在とか言葉遊びは止めるといいね

15 :デフォルトの名無しさん:2013/03/04(月) 11:03:43.44
効率上げたかったら型付けなんか計算機にやらせれば良いだろ。

16 :デフォルトの名無しさん:2013/03/04(月) 19:19:35.72
ふーんいつになったら潜在能力開花すんの?
おら邪眼の力だか見してみろよ

17 :デフォルトの名無しさん:2013/03/05(火) 13:31:49.84
静的型付け言語の潜在開発生産性は今の1000罪

18 :デフォルトの名無しさん:2013/03/05(火) 21:47:41.94
関数の中に処理が
 A1
 B1
 A2
 B2
 A3
 B3
と並んでいたとする。 これを
 A1
 A2
 A3
 B1
 B2
 B3

と並び替えられるだろうか?
並び替えることが可能であれば、
このよう書き換えることが可能になる。

funcA()
funcB()

funcA {
 A1
 A2
 A3
}
funcB {
 B1
 B2
 B3
}

19 :デフォルトの名無しさん:2013/03/05(火) 21:51:40.59
行の並び替えは、出来る場合と出来ない場合がある。
実はコンパイラの最適化ではこのような行の入れ替えが行われている。

だから行の並び替えが出来るかどうかをコンピュータが判定するのは不可能ではないはずだ。
(だが動的型付け言語では不可能だろう)

これは長いコードを短い関数に分割する場合に役に立つ。

20 :デフォルトの名無しさん:2013/03/06(水) 00:19:57.55
プロコン目指してる高校生か?
そんな初歩的な話するんだったらtwitterの方が楽しいだろ

21 :デフォルトの名無しさん:2013/03/06(水) 02:29:41.97
動的型割り当てなんてモダンな最適化の基礎だろ
人間様が指定してやる時代なんてもう終わるわ

22 :デフォルトの名無しさん:2013/03/06(水) 03:36:21.75
ん? 誰が最適化の話してるんだ?
知ってる用語並べてみた?

23 :デフォルトの名無しさん:2013/03/06(水) 16:54:29.20
むしろ言語のほうで人間様が指定しなきゃいけないことが増えてる

24 :デフォルトの名無しさん:2013/03/06(水) 19:14:01.69
ゴミムシなのに様なんて名乗れるの?

25 :デフォルトの名無しさん:2013/03/07(木) 08:48:36.37
動的言語の時代クル━━━━━━(゚∀゚)━━━━━━ !?
って展開は確かにあったけど、結局性的言語持ちこたえてんじゃん。
http://www.tiobe.com/content/paperinfo/tpci/images/history_paradigm_type%20system.png

最近のブログ界隈の議論でも性的言語サイドが明らかに優勢に見えるがどうよ?

思うんだが今の時代、流れが少し良くなったからと調子に乗ると
でっかい落とし穴が待ち構えてるね。任天堂、GREE、マクドナルド以下略
よくよく心しないといけないと思うんだ(´・ω・`)

26 :デフォルトの名無しさん:2013/03/07(木) 12:31:27.70
言っちゃ悪いけどPerl云々で始まった型についての記事なんて
最終的に自分の好みと自分の狭い世界での経験を話しをしてるばかりで
読み物としても大した参考にならんかったわ

プログラマーなら生産性のベンチマークとかして喋れよっていう

27 :デフォルトの名無しさん:2013/03/07(木) 12:34:26.57
あ、どちらの派閥もな。
動的型付け派も具体的にどういう測定方法で何倍の生産性が得られるか言わないよね
そんなの議論じゃなくて妄想乙だよ

処理速度の比較くらいだろ定量的なの

28 :デフォルトの名無しさん:2013/03/07(木) 18:42:33.27
あれな〜。
速攻で"Perl.*型"をフィードのフィルタにぶち込んだわ。
ナンセンスにも程があるし、ブクマ狙いすぎで実に草い。

29 :デフォルトの名無しさん:2013/03/07(木) 20:21:43.04
プログラムを書かない人のためのツールを書く言語がJavaやC#
プログラマ(自分自身を含む)のためのツールを書く言語がPerlやPython

30 :デフォルトの名無しさん:2013/03/10(日) 03:38:11.26
そんなずっと前から分かってることで、一人や少人数で小さ目のプログラム書くなら動的型付、多人数で大きなプログラム書くなら静的。この認識で間違いない。

31 :デフォルトの名無しさん:2013/03/10(日) 05:55:02.66
>>30
そうではなくて、
型に拘るなら静的型付け、拘らないなら動的型付け、です。

32 :デフォルトの名無しさん:2013/03/10(日) 06:30:25.98
型に拘るメリットが多いのが大規模で、
拘るメリットが少ないのが小規模ってことだよ。

なぜかというと、小規模だとコード全体が見渡せるから
型が書いていなくても、引数の型を調べるのが容易だから。
そして一人で作れるレベルだから、型やコード全体を覚えることだって可能。

33 :デフォルトの名無しさん:2013/03/10(日) 06:37:51.01
>>32
一般的には確かにそうだと思う。しかし、開発規模に関わりなく、
記号処理用の言語に見られるように、引数にリスト以外の構造体が
来ないことが普通の言語もある。この場合引数の型は意味解析に
全く役に立たない。したがってそういう読み方をしない。

34 :33:2013/03/10(日) 06:45:36.36
全く役に立たない。これは言い過ぎだった。変数名に意味を暗示させる
よりは、型で宣言して、変数のクラスを暗示する方がよいという考え方
もある。

35 :デフォルトの名無しさん:2013/03/10(日) 07:11:01.16
>>34で訂正している気がするがまあ無視するとしてw

>>33
> この場合引数の型は意味解析に 全く役に立たない。

お前、コンピュータなん? コンピュータならどんな汚いコードでも
変な名前でも、書いたとおりに正しく動作するよ。だからなんでもいいよ。
だがな、俺らは人間だ。汚いコードだと解析に時間がかかるし、
変な名前でもそうだ。型に関してもそう。
コンピュータが正しく意味解析できるかは問題ではない。

人間が、正しく意味解析できるかのほうが重要。プログラミングの7〜8割は
既存のコードのメンテナンス。新規に書くよりも、既存のコードを読むことのほうが多い。
読む時間を減らす=開発速度の向上。(文字数=読む時間ではないぞ。定型句は読み飛ばすから時間には含まれない)

コードを読んで修正するのは人間だ。その人間のためにコードを書くんだ。
型が省略されていれば、その変数に何が入っているかを別の方法で確信を得なければならない。
推測ではだめだ。推測なんかするから想定外のことが起こったなんて言い訳をすることになる。

型が近くに書いていれば、すぐに確信を得られる。遠くに書いてあれば時間がかかる。
生成する箇所すべてを見なければわからないなら時間がかかるのは当たり前。

小規模だと全体を見る必要があっても時間がかからない。
だが大規模では全体を見ていたらいくら時間があっても足りない。
だから大規模開発では小さい範囲を見るだけで確証を得る手段が必要になる。それも確実な方法で。

36 :デフォルトの名無しさん:2013/03/10(日) 07:27:22.87
小規模だと、書く(タイプする)速度が重要になるが、
大規模だと、読む(理解する)速度のほうが重要なんだよね。

文字数はタイプするときには重要なことだが、
読む速度の場合、文字数はほとんど影響がない。

例えばファイル冒頭のimport文とか
どうせ読まないから、いくらあっても
読むスピードには影響しない。

37 :デフォルトの名無しさん:2013/03/10(日) 08:42:47.07
こういうコードが読みやすいって?馬鹿なの?


Map<String, Integer> bag = new HashMap<String, Integer>();
BufferedReader br = new BufferedReader(new FileReader(new File("sample.txt")));
String line = br.readLine();
while(line != null){
    for (String str : line.split(" ")) {
        Integer n = bag.get(str);
        if (n != null) {
            bag.put(str, n + 1);
        } else {
            bag.put(str, 1);
        }
    }
    line = br.readLine();
}
br.close();
for(Map.Entry<String, Integer> entry : bag.entrySet()){
    System.out.printf("%s: %s\n", entry.getKey(), entry.getValue());
}

38 :デフォルトの名無しさん:2013/03/10(日) 09:11:07.14
ユーザーがプログラマで自分でコードを直せるなら動的型
ユーザーがエンドユーザーで自分でコードを直せないなら静的型

39 :デフォルトの名無しさん:2013/03/10(日) 09:28:13.54
Map<String, Integer> bag = DefaultedMap.defaultedMap(new HashMap<String, Integer>(), 0);
LineIterator i = FileUtils.lineIterator("sample.txt");
while(i.hasNext()){
    for (String str : i.next().trim().split(" ")) {
        bag.put(str, bag.get(str)+1);
    }
}
i.close();

Commons使えば多少は楽になるけれどもサクッと書けるクロージャの類が
無いのでファイルの開け閉めの辺りが格好悪いね。ただこの問題はJavaが
タコと言うだけであって静的型とはあまり関係がないと思う。

40 :デフォルトの名無しさん:2013/03/10(日) 12:54:22.31
>>37
それは書き方が汚いだけ。

41 :デフォルトの名無しさん:2013/03/10(日) 13:08:48.45
>>39
ファイルの開け閉めなら自動クローズさせればいいよ。
http://d.hatena.ne.jp/argius/20110908/1315486185

あとGooglGuavaも使ってみるといいかな。

com.google.common.io
■Files
http://d.hatena.ne.jp/mtoyoshi/20100725/1280040233

42 :デフォルトの名無しさん:2013/03/10(日) 16:49:39.03
Groovyで静的に型指定して書くとこうなるね。
new File("sample.txt").eachLine{ String line ->
 line.trim().split(" ").each{String str -> bag.put(str, bag.get(str)+1)}
}

要するに{ -> }みたいな簡便なクロージャ記法の有無の問題であって静的動的は
あまり関係無いと思う。

43 :デフォルトの名無しさん:2013/03/10(日) 17:14:30.02
勝手に>>42付け加えるなら、記述量と読みやすさはあまり関係がない。

確かにクロージャの簡単な書き方がなければ ”書くのは” 面倒になる。
だけどその面倒な部分ってのは、あまり読まなくてもいいところ。
コメントのようなものだと思えばいい。だから読むときにの影響は少ない。

そして書くのは面倒といったが、そういうのは自動生成できることが多い。

44 :デフォルトの名無しさん:2013/03/10(日) 17:15:42.47
静的動的は関係ないけど、読みやすさには関係あるよ

45 :デフォルトの名無しさん:2013/03/10(日) 17:20:01.54
それはGroovyの静的型がオマケみたいな扱いだからじゃね?
クロージャの型だとか。

46 :デフォルトの名無しさん:2013/03/10(日) 17:22:08.92
一般的に、処理コードは読むが、定義コードは読まない。
静的型付け言語で、冗長なのは定義コードの部分であって
処理コードの量は、大差ない。

47 :デフォルトの名無しさん:2013/03/10(日) 17:25:06.61
それ、「オレは型なんて読まないぜ、だから静的型でも読みやすいぜ、キリッ」ってこと?

48 :デフォルトの名無しさん:2013/03/10(日) 17:36:24.43
型を含めた定義部分は、じっくり読むようなところじゃないってこと。
ちらっと見て、脳の短期記憶領域にさっと入れれば終わり。

もしくは必要なとき見れればいいし、IDE使ってるなら
画面外に定義があっても、簡単に見れるだろう?

時間をかけて読むのは、処理部分ってこと。

49 :デフォルトの名無しさん:2013/03/10(日) 17:42:14.18
>>45
Grooby2.0からクラスやメソッド単位で静的な型チェックを強制できるようになった
ので、クロージャの引数や返り値も静的に検証させたり推測させたり出来るよ。

個人的には静的型や動的型のどちらかではなく中間のオプショナルな型付けが好き。
その場合は言語仕様だけではなくライブラリ環境も重要で、言語は静的動的どちらで
かけるにしても、言語の主要なライブラリは特殊なもの以外はバリバリに型情報付きで
提供されている、そんな言語。

ようするに、ActionScript3さいこ〜

50 :デフォルトの名無しさん:2013/03/10(日) 21:21:41.33
つかJava由来のinterfaceは糞。
gccのsignatureやgoのinterface法式が普及すれば、
動的型付の需要が減る。
あとAutomated delegationまで使えれば、
敢えて動的型付を使う理由はない。

51 :デフォルトの名無しさん:2013/03/10(日) 21:52:10.06
>>50
>敢えて動的型付を使う理由はない。

「おれの土方仕事の範囲内では」が抜けてるぞ。

52 :デフォルトの名無しさん:2013/03/10(日) 22:20:04.35
Squeak Smalltalk で書いてみた。

| bag |
bag := Bag new.
FileStream fileNamed: 'sample.txt' do: [:file |
  [file atEnd] whileFalse: [bag addAll: (file nextLine subStrings: ' ')]
].
^bag valuesAndCounts

53 :デフォルトの名無しさん:2013/03/10(日) 22:30:52.59
>>52
Bag使わんで書いたらどうなる?

54 :デフォルトの名無しさん:2013/03/10(日) 22:50:15.85
>>51
うん。だってGraphics処理やってたら別にDuckTyping以上の
動的型付のメリット無いもの。Message転送はたしかに便利だけど、
用途の殆んどが委譲だから自動委譲(Automated Delegation)が
有れば殆ど困んない。
ちなみにウチのソフトは1本3000万以上で売ってる。
受託と違って一本のソフトが巨大で、一本のソースが
長期間使い回されるから、依存関係を調べにくい言語は
使いづらい。
今はgoへの移行ですげぇ助かってる。

55 :デフォルトの名無しさん:2013/03/10(日) 22:54:31.22
Python3 で書いてみた

from collections import Counter
with open('sample.txt', 'r') as fp:
    bag = Counter(x for line in fp for x in line.split(' '))
    print(bag.items())

56 :デフォルトの名無しさん:2013/03/10(日) 23:17:57.78
>>52
Smalltalk最近よく見かけるようになったな。良いことだ。

57 :デフォルトの名無しさん:2013/03/10(日) 23:23:37.35
>>53
| bag |
bag := Dictionary new.
FileStream fileNamed: 'sample.txt' do: [:file |
 [file atEnd] whileFalse: [
  (file nextLine subStrings: ' ') do: [:str |
   bag at: str put: (bag at: str ifAbsent: [0]) + 1
  ]
 ]
].
bag associationsDo: [:assoc | Transcript showln: assoc]

58 :デフォルトの名無しさん:2013/03/10(日) 23:25:10.63
>>55
import しないで書いてみたらどうなるの?

59 :デフォルトの名無しさん:2013/03/10(日) 23:28:44.50
突然の Python3 vs Squeak Smalltalk !

60 :デフォルトの名無しさん:2013/03/10(日) 23:29:10.36
>>58
with open('sample.txt', 'r') as fp:
    bag = {}
    for line in fp:
        for x in line.split():
            bag[x] = bag.get(x, 0) + 1
    print(bag.items())

61 :デフォルトの名無しさん:2013/03/10(日) 23:30:13.75
カウンターやBagの類のユーティリティクラスを使ってループを一つ隠さないと結局
どれも複雑になるなぁ。

62 :デフォルトの名無しさん:2013/03/10(日) 23:41:20.07
標準添付のライブラリすら使わないという制約下で書かれた>>57>>60と、
標準で付いてこないライブラリを使って書かれた>>39を比べてるのかい?

63 :デフォルトの名無しさん:2013/03/10(日) 23:50:59.76
そもそもBagなんざSmalltalkにはプレリリース版(-80 v1)から
組み込みになっているごく基本的なクラスなんだから
後続言語はせめて標準添付ライブラリくらいにはいれておけと

64 :デフォルトの名無しさん:2013/03/11(月) 00:24:00.19
>>62
>>39はマップのデフォルト値とファイル読み込みの行イテレーターという他の言語の
標準クラスにはあってjava.langには無いものを最低限Commonsで補ったもの。
標準ライブラリの機能比較ならともかく、ライブラリの機能を揃えた上で静的動的の
書き方の比較するなら>>39との比較で良いと思うよ。

65 :デフォルトの名無しさん:2013/03/11(月) 00:25:01.70
>>63
だったらSmalltalkもfileNamed:do:とか最初から入れておけと

fileNamed: fileName do: aBlock
"Avi Bryant says, ''This idiom is quite common in other languages
that make heavy use of closures (i.e. Lisp (with-file 'foo' (f) ...) and
Ruby (File.open('foo'){|f|...})). It's time Squeak had it, too.''

66 :デフォルトの名無しさん:2013/03/11(月) 00:41:30.53
だって、Smalltalk環境にFileなんてもともと無いし

67 :デフォルトの名無しさん:2013/03/11(月) 00:44:46.44
JDK標準だけだとこんな感じか。

Map<String, Integer> bag = new HashMap<String, Integer>();
BufferedReader br = new BufferedReader(new FileReader("sample.txt"));
for(String line; (line = br.readLine()) != null;){
 for(String str: line.trim().split(" ")){
  bag.put(str, bag.containsKey(str) ? bag.get(str) + 1: 1);
 }
}
br.close();

68 :デフォルトの名無しさん:2013/03/11(月) 00:52:26.80
Groovy+Guavaで静的型に書くとこんな感じ。
Multiset<String> bag = new HashMultiset<String>()
new File("sample.txt").eachLine{String line -> bag.addAll(line.trim().tokenize(" "))}

69 :デフォルトの名無しさん:2013/03/11(月) 01:08:18.73
>>66
おいおい、どこのバカに教わったか知らんが勝手に無くすなよ!w
ファイルの扱いなんざSmalltalk-80の前身のそのまた前身のSmalltalk-72から普通にあるぞ。

http://squab.no-ip.com:8080/collab/uploads/61/smalltalk-72-1977.jpg

70 :デフォルトの名無しさん:2013/03/11(月) 01:11:36.15
単にJava叩きたいだけならメッセージ転送による自動委譲が一番手っ取り早いぞ
SmalltalkやPython、 Ruby、Goなんかだと簡単なのにJavaはかったるいからな

Example >> something: aThinDevice
| thinProtocol fatProtocol |
thinProtocol := aThinDevice thinProtocol.
thinProtocol selectorA.
thinProtocol selectorB.
thinProtocol selectorC.

fatProtocol := ( FatProtocolAdapter new ) withThinProtocol: thinProtocol.
fatPrococol selectorA. "thinProtocol selectorAへ委譲"
fatPrococol selectorB. "thinProtocol selectorBへ委譲"
fatPrococol selectorC. "thinProtocol selectorCへ委譲"
fatPrococol selectorD. "FatProtocolAdapterで新たに実装"

"FatProtocolAdapterが行ってる自動委譲"
FatProtocolAdapter >> doesNotUnderstand: aMessage
 aMessage sendTo: thinProtocol.

"あとは、初期化と差分のselectorDを追加するだけ"
FatProtocolAdapter >> withThinProtocol: aThinProtocol
 thinProtocol := aThinProtocol.

FatProtocolAdapter >> selectorD
 "固有処理"

71 :デフォルトの名無しさん:2013/03/11(月) 01:12:54.53
>>69
今と同じファイルだっけ?全部シリアライズしたオブジェクトだろ?

72 :デフォルトの名無しさん:2013/03/11(月) 01:43:33.68
>.70
Javaで委譲ってかったるい?

こんなに簡単にできるんだけど。
http://blogs.wankuma.com/kazuki/archive/2008/03/23/129171.aspx

73 :デフォルトの名無しさん:2013/03/11(月) 01:50:35.72
Eclipseの機能で言語機能じゃねぇし
それに、移譲先が変化しても勝手に委譲されるわけじゃない
かったるすぎる

74 :デフォルトの名無しさん:2013/03/11(月) 01:52:28.19
統合開発環境で1000行でも2000行でもスニペットを貼り付けるのは簡単だろうよw
だったら、そのスニペットを自動生成する言語でも使えばいいんじゃね

75 :デフォルトの名無しさん:2013/03/11(月) 01:55:18.87
>>72
100種類クラスがあったら100回それするんだろ
コピペファストとか言ってたアレはどうなるんだろうなぁ

76 :デフォルトの名無しさん:2013/03/11(月) 01:59:44.37
なんかCOBOLerさんを思い出すわ

77 :デフォルトの名無しさん:2013/03/11(月) 02:09:33.75
JavaBeanswww

78 :デフォルトの名無しさん:2013/03/11(月) 02:13:03.54
コピペで簡単に出来るっつうなら言語は何でもいいっつうの

79 :デフォルトの名無しさん:2013/03/11(月) 03:22:27.56
コピペ最強さんは
プログラムを読む事など
一切想定してないんだろうな

80 :デフォルトの名無しさん:2013/03/11(月) 03:37:13.53
う〜ん、アノテーション使ったこういう委譲の方法が、無いわけでもない。

public interface Thin {
 String a();
 String b();
}

public class ThinImpl1 implements Thin {
 public String a() {return "a";}
 public String b() {return "b";}
}

public class ThinImpl1 implements Thin {
 public String a() {return "A";}
 public String b() {return "B";}
}

import lombok.Delegate;
public class Fat implements Thin{

 @Delegate private Thin thin;

 public Fat(Thin thin) {super(); this.thin = thin;}
 public String c(){ return this.a() + this.b() + "c";}
}

new Fat(new ThinImpl1()).c(); // <- "abc"
new Fat(new ThinImpl2()).c(); // <- "ABc"

表向きの見た目としてはそれなりにシンプルだと思うのだけれども、どうだろう。
(裏で何が起こっているかは突っ込んではいけない)。

81 :デフォルトの名無しさん:2013/03/11(月) 04:56:10.55
やっぱS/N比が低すぎねえか?w

82 :デフォルトの名無しさん:2013/03/11(月) 04:57:10.40
ただの慣れだろw

83 :デフォルトの名無しさん:2013/03/11(月) 04:57:54.94
ソースコードは静的なのに、
型定義を動的にやっても意味は無い。

84 :デフォルトの名無しさん:2013/03/11(月) 05:53:12.61
速度が全てじゃないとはいえ、速度も含めたトータルで比較したい
実際の開発だと、パフォーマンスチューニングで工数取られることもあるから


てわけで、某スレのパクリだけど、次の内容で検証して下さい

・モンテカルロ法で円周率計算して値を出力
・実行できる完全なソースコード(他者がベンチマークを検証できるように)
・サンプル数10000000のときの実行時間(実行環境も併記)



実行速度と可読性で優れた言語が優勝

85 :デフォルトの名無しさん:2013/03/11(月) 05:54:57.90
ちなみに、ライブラリの使用はありです。
可読性を上げるために、ライブラリをでっち上げるのもありです。
”ライブラリを除いた部分の” 可読性で勝負をします。

86 :デフォルトの名無しさん:2013/03/11(月) 06:00:05.97
>>80
@Delegateってなんぞ
自作の注釈なら実装貼れ
実装不可能なら意味がない

87 :デフォルトの名無しさん:2013/03/11(月) 06:01:33.19
実行速度も計るので、架空のライブラリはダメです

88 :デフォルトの名無しさん:2013/03/11(月) 06:02:05.47
>>81
どの辺が具体的にノイズだろう? 委譲自体は基本的に次の一行で簡潔していて、Thinという
インターフェイスに定義されたJavaで言うところのメソッドの扱いがthinに委譲されている。

@Delegate private Thin thin;

残りの2行はthinの値の初期化と差分の実装で、>>70の例と一緒。

何を委譲するかはThinというインターフェイスとして静的に定義しているけれども、これは
静的型だから仕方が無いねぇ。これがノイズかと問われると、インターフェイスを定義する
ことで注入する委譲先の型も静的に検証出来るし、FatがThinを実装しているというのも静的
に解るなど、静的型付けなりのメリットが出てくる。

>>83
一応>>80は型定義も静的。

89 :デフォルトの名無しさん:2013/03/11(月) 06:03:56.58
>>80
Fat自体がinterfaceなんだからFatが実装になったらいかんぞ

90 :デフォルトの名無しさん:2013/03/11(月) 06:19:53.95
>>80
そのFat classを元にして新しいclassを自動生成ってのは
おそらく可能だろうただFat自体にMember関数追加すんのは無理。
机上の空論にもならん。

91 :デフォルトの名無しさん:2013/03/11(月) 06:27:34.29
精々JNA的なトコまで実装すんのが精いっぱいだろうな
単に委譲するだけで、新しい処理を追加すんのは無理じゃね

92 :デフォルトの名無しさん:2013/03/11(月) 06:30:15.95
>>86
そういう話も出るなと思ってimport文も貼ったんだけれども。これはlombokというライブラリ。
書いたコードもちゃんとコンパイルして動くコードだよ。

http://projectlombok.org/features/index.html

裏側では委譲のためのJavaコードをアノテーションプロセッサで生成している。なので裏側は
>>74の言うところの「スニペットを自動生成」そのものなのであまり見て欲しくはないw

JavaだとDecoratorの類を書きにくいのはその通りで、言語仕様的には>>72のいう大量の
ラッパーコードを使うのがどう考えても素直で静的型検証もきっちり動く。ただこの辺りを
表面的には綺麗に取り繕うことも出来なくはないひとつの例として見てもらえると。

>>89
Fatは委譲のやり方の一例であって、インターフェイスであることは初めから意図していない。
この例だとa()とb()の実装はthinに委譲していて、Fatはc()の実装だけ持っている。

93 :デフォルトの名無しさん:2013/03/11(月) 06:41:03.58
>>92
プリプロセス的でも自動で出来るなら別にいいよ
手作業でミスするよりはるかにマシだ
変更の度に他に手が入るのは最悪だから

94 :デフォルトの名無しさん:2013/03/11(月) 06:56:35.08
移譲先と移譲元に変更があった場合も再コンパイルせにゃならんの
相変わらずメンドイな

95 :デフォルトの名無しさん:2013/03/11(月) 07:01:56.53
>>92
オーバーライドの干渉制御は手作業か。夢はあるけど不便だな。

96 :デフォルトの名無しさん:2013/03/11(月) 07:12:59.82
>>84
Python3.2.3 (1.6GHz Core i5)
実行時間: 0.80s user 0.26s system 99% cpu 1.071 total


import numpy as np

n = 10000000
x = np.random.rand(n, 2)
print(4/n * np.sum(np.sqrt(x[:,0]**2+x[:,1]**2) < 1).astype(int))

97 :デフォルトの名無しさん:2013/03/11(月) 07:13:57.99
委譲先に変更があってもインターフェイスが変わらない限り変更があった委譲先だけの
再コンパイルだし、委譲する側に変更があっても委譲先の再コンパイルは必要ないよ。

インターフェイスに変更があった場合は、そのインターフェイスを利用しているクラス
全てに影響が波及する、これは委譲しようがしまいが一緒だね。コンパイルに関しては
Javaでの既存の委譲方法に比べあまり不利はないように思う。

>>95
それはそう思う。今は干渉は静的にチェックされてコンパイル時にエラーで蹴られるので、
委譲するメソッドを列挙したインターフェイス定義を調整する必要がある。
安全と言えば安全だけど、手間はでかい。

98 :デフォルトの名無しさん:2013/03/11(月) 07:22:44.46
大規模開発向け(キリッ)

99 :デフォルトの名無しさん:2013/03/11(月) 07:55:19.21
>>97
これgenerics対応出来ないよな。
動的型付なら、委譲先のメンバー全て使える。
Javaのやり方だと委譲先のinterfaceに束縛されて、
今のinterface以外は委譲できないだろう。
新しいinterface間同士の委譲が必要になったら、
その都度class作ってSelectorDを書かなきゃならんのか?

100 :デフォルトの名無しさん:2013/03/11(月) 07:57:47.03
>>84
Java

http://ideone.com/yEqYUC

101 :デフォルトの名無しさん:2013/03/11(月) 08:13:15.63
普通にJavaが最強の件

102 :デフォルトの名無しさん:2013/03/11(月) 08:53:20.04
>>99
>新しいinterface間同士の委譲が必要になったら、
>その都度class作ってSelectorDを書かなきゃならんのか?

SelectorDの実装を色々な委譲先に対して共有したいのであれば、実装を共有する定石に従って
SelectorDはabstract classに実装すればOKだと思う。仮にSelectorDの実装が「今まだ知れぬ」
委譲先に依存する部分があれば、それはabstractメソッドとして列挙しておく。

public abstract class AbstractFat {
 public abstract String a();
 public abstract String b();

 public String c(){
  return this.a() + this.b() + "c";
 }
}

で、具象クラスでは単に継承して委譲先を注入するだけ。委譲先のインターフェイス(この
場合はThin)がSelectorDの実装に必要な依存性を十分に提供していない場合(a()が無いとか)は
コンパイルで蹴られるので多い日も安心。

public class Fat extends AbstractFat implements Thin{
 @Delegate private Thin thin;
 public Fat(Thin thin) {super(); this.thin = thin;}
}

103 :デフォルトの名無しさん:2013/03/11(月) 13:01:01.87
>>102
ん?やっぱりThin以外に対応できないんだよね

104 :デフォルトの名無しさん:2013/03/11(月) 13:03:46.85
重要なの忘れてた。
やっぱり新しいクラス作らないとThin以外に対応できないんだよね

105 :デフォルトの名無しさん:2013/03/11(月) 14:18:12.86
>>86
Common Lisp (SBCL)
Intel(R) Celeron(R) CPU 867 @ 1.30GHz

(declaim (optimize (compilation-speed 0)
(debug 0)
(safety 0)
(space 0)
(speed 3)))

(defun main ()
(loop with n = 10000000
repeat n
count (< (+ (expt (random 1.0) 2) (expt (random 1.0) 2)) 1) into s
finally (format t "~f~%" (/ (* 4 s) n))))

#+ sbcl
(sb-ext:save-lisp-and-die "pi" :toplevel #'main :executable t)

$ time ./pi
3.1412177

real 0m1.348s
user 0m1.332s
sys 0m0.008s

106 :デフォルトの名無しさん:2013/03/11(月) 15:53:26.37
>>104
そうだね。本当はFat<T>とか定義してnew Fat<Thin>(new Thin())とかやりたいところ
なのだけれども、これは出来ないしあまり意味もない。これは動的型云々よりもJavaの
総称型の実装の問題かな。Javaの総称型はタイプイレイジャで実現されているから、
Fat<T>と定義した時点でTの型に関わらずFat<...>が持つメソッドは固定されてしまう。
でも実用上はFat<T>はTに含まれるメソッドも持っていないとあまり嬉しくはない。

なので委譲先のインターフェイス毎にクラスは作る必要はあるね。ただそれって。

public interface AnotherThin{
 String foo();
 String baa();
}

てのがあったら、

public class FatForAnotherThin extends AbstractFat implements AnotherThin{
 @Delegate private AnotherThin anotherThin;
 public FatForAnotherThin(AnotherThin anotherThin) {super(); this.anotherThin = anotherThin;}
}

だけ。委譲して初期化だけ。c()の再実装は不要だし、ちゃんとインターフェイスを
静的に定義しているから初期化の引数もコンパイル時にチェックされる。
というかそもそも上記の委譲は成り立たないと言うことがコンパイル時に検出されて
上記のコードは蹴られるなど、静的に検証できるメリットは出てくる。

107 :デフォルトの名無しさん:2013/03/11(月) 22:07:18.91
>>99
それってさ、重要なところは

Javaの場合は、コンパイル時に委譲コードを生成するから委譲は楽にかける。
ただし、インターフェースにないメソッドの追加はできないってことだよね?

前から思ってるんだけど、インターフェースにないメソッドを追加したいってことあるの?
ダックタイピングの例で言えば、「アヒルのように歩き、アヒルのように鳴くのならアヒル」
つまりアヒル は アヒル歩き と アヒル鳴きインターフェースを持っている。
そこにアヒル食いを追加したいってことでしょ?

だったら最初っからインターフェースにアヒル食いを追加しておけばいいと思うんだけど?

108 :デフォルトの名無しさん:2013/03/11(月) 22:36:20.93
>>84
VisualWorks Smalltalk, 3.95s, 2.4GHz Core i7
(同環境での>>100のJavaは 1.53s)

| N rand count |
N := 10000000.
rand := Random new.
count := 0.
N timesRepeat: [
  | x y |
  x := rand next.
  y := rand next.
  ((x * x) + (y * y)) sqrt < 1 ifTrue: [count := count + 1]
].
^(4 * count / N) asDouble

109 :デフォルトの名無しさん:2013/03/12(火) 08:27:53.86
>>107
今一言ってることが判らないからJava方式のinterfaceに
追加できないって問題だけに答えてみる。
JavaやってるならJTextFieldとJFrameって知ってるよね
あれのsetTextって動作同じなのにinterface共有してないから
JTextFieldとJFrameをおなじ関数で処理できないんだ。かと言ってJTextFieldとJFrameに別のinterface追加したり、
既に実装しているinterfaceに関数追加できないのは解るでしょ。
Beansでも使うか新たにinterfacesを実装した派生classを作るとか
面倒なことしなきゃいけない。

gccのsignatureやMLのsignature、HaskellのType class、
goのinterfacesみたいな方式なら問題ないんだけどね。

110 :デフォルトの名無しさん:2013/03/12(火) 08:37:34.53
静的型付け言語の潜在開発生産性はJavaの100倍

111 :デフォルトの名無しさん:2013/03/12(火) 08:48:45.98
JFrameにsetTextなんてあったっけ。

112 :デフォルトの名無しさん:2013/03/12(火) 12:42:09.28
>>110
それ結論でいいよ

113 :デフォルトの名無しさん:2013/03/12(火) 12:57:05.69
>>111
setText付いてんのJFrameじゃなくJLabelだったっけ
まぁ、どっちでも良いよ

114 :デフォルトの名無しさん:2013/03/12(火) 22:03:55.39
>>109
> あれのsetTextって動作同じなのにinterface共有してないから
> JTextFieldとJFrameをおなじ関数で処理できないんだ。

それは一長一短でしょ?

今回はたまたま、setTextの動作が同じだったから
そういう結論だけど、setTextの動作が違ったら
別の関数で処理したいはず。

115 :デフォルトの名無しさん:2013/03/12(火) 22:09:55.37
>>109
> あれのsetTextって動作同じなのにinterface共有してないから
> JTextFieldとJFrameをおなじ関数で処理できないんだ。かと言ってJTextFieldとJFrameに別のinterface追加したり、

1.オーバーロードを使う。
2.Object型を使う。
3.GenericsでJTextFieldまたはJFrame用の関数を生成する
4.Adapter パターンを使う

116 :デフォルトの名無しさん:2013/03/12(火) 22:15:41.57
同じsetTextだからって同じ動作をするとは限らないからねぇ。

例えばインプットフィールドがあったとして、
setTextは、入力文字列の変更でしょ?

で、ラベルがあったとして、
setTextは、表示文字列の変更でしょ?


じゃあ、ラベル付きインプットフォールドがあったとして
setTextはどこになるのか?

117 :デフォルトの名無しさん:2013/03/12(火) 22:20:49.19
実はVB6がこの問題をうまく解決している。
(継承はできないという問題はあるけれど)

setTextをもったインプットフィールド、setTextをもったラベル。
その両方をインターフェース継承した
ラベル付きインプットフィールドを作ることが可能になっている。

この時、ラベル付きインプットフィールドが持っているのは、
setTextという関数ではなく、
inputfield_setText と label_setText という別の名前を持った
二つの(プライベート)関数。

このラベル付きインプットフィールドを
インプットフィールドにキャストして、setTextを呼び出せば
inputfield_setTextが呼び出され、ラベルにキャストしてsetTextを呼び出せば
label_setTextが呼び出されるという仕組み。

118 :デフォルトの名無しさん:2013/03/12(火) 22:36:30.87
DuckTypeが使えるRhinoつかうとすげぇ楽だった

function modelDependencyAdapter( textView, model )
{
 var dependency = {};
 dependency.update = function() { textView.setText( model.getText() ); };
 return dependency;
}

text = new JTextField();
model.addDependency( modelDependencyAdapter( text, model ) );
label = new JLabel();
model.addDependency( modelDependencyAdapter( label, model ) );

>>116だからどうした。それは使う側が決めることだろ。
>>115他の言語ならせずに済むそんな事をせにゃならんのがめんどくせぇ。

119 :デフォルトの名無しさん:2013/03/12(火) 22:38:11.07
>>115他の言語ならせずに済むそんな事をせにゃならんのがめんどくせぇ。

だから、他の言語だったら、
setTextで動作が違う場合に面倒になるんだよ。

120 :デフォルトの名無しさん:2013/03/12(火) 22:39:11.20
ぜんぜんめんどくさくないのに、
なんで面倒くさいって思ってるんだろう?

121 :デフォルトの名無しさん:2013/03/12(火) 22:49:22.50
>>119
意味がわかんない。動作が違って困るなら分けて使うだろうし。
多少動作が違おうと構わない場合もいくらでもある。
大体、そこの判断はコンパイラーがするわけじゃなく、
人間が決められることだ。

122 :デフォルトの名無しさん:2013/03/12(火) 22:53:10.58
>大体、そこの判断はコンパイラーがするわけじゃなく、
ここは言い方が変か。要するに、誰かに強制されるわけじゃなく
使用者の器量で判断できるってことだ

123 :デフォルトの名無しさん:2013/03/12(火) 22:56:07.88
>>120
他の言語ならしなくて済むことを態々書いてんだから
面倒以外の何物でもないぞ
C++ですら回避できる話なのに

124 :デフォルトの名無しさん:2013/03/12(火) 22:56:57.74
やっぱり>>110でFA

125 :33:2013/03/12(火) 23:09:20.08
>>124
ALGOLのことだね。

126 :デフォルトの名無しさん:2013/03/13(水) 00:28:38.48
>>117
下策じゃん。

text = complexText.TextField
text = complexText.Label
text.Text

こんな風に、PropertyでそれぞれText I/Fにアクセス
出来るようにした方がマシだったろ。

因みにcomplexText.xとcomplexText.TextField.x、
complexText.Label.xの実体は同じ。
Smalltalk的な解決手段。

127 :デフォルトの名無しさん:2013/03/13(水) 06:04:18.45
Structual typeはあっても良いけどオマケだなぁ。欲しくなるケースがイマイチ少ない。
とりあえずJLabelとJTextFieldの例では具体例として説得力が弱いのではないかと。

128 :デフォルトの名無しさん:2013/03/13(水) 08:53:09.78
>>126
マシじゃないよ。

インターフェース名ってのはsetTextじゃない。
これはインターフェースのフルネームじゃない。
名前空間みたいなものと考えればいいよ。
foo.hoge
bar.hoge

両方共hogeだけど、この二つは同じものじゃないだろう?

foo.setText
bar.setText

これも同じものと考えてはいけない。

129 :デフォルトの名無しさん:2013/03/13(水) 09:10:14.38
VB6だと
TextWithLabel text = ラベル付きテキスト

Text t1 = text;
t1.setText(); テキストのsetText()が呼ばれる

Label t2 = text; ラベルのsetText()が呼ばれる
t2.setText()

実にスッキリ

130 :デフォルトの名無しさん:2013/03/13(水) 13:46:38.13
単純な話、数の型をしていしてやらなきゃならない高級言語なんてものはカタワだ。
ただしCは除く。Cは高級言語ではないからあれで良い。

131 :デフォルトの名無しさん:2013/03/13(水) 15:11:36.55
Duck typingとStructual typeは区別するべきだと思うのね。

どちらも簡単には使えないJavaの場合でも、まとめて扱いたいクラスは大抵ライブラリ側で同じ
クラスなりインターフェイスを継承していることが多いから、気配りの効いたライブラリを使って
いる限りは実用上はあまり不便は無いかな。

132 :デフォルトの名無しさん:2013/03/13(水) 21:05:36.43
>>130
本当にどんな型でも扱えるクラスってのは他のオブジェクトを
格納するだけのコンテナぐらいしかない。たいていは特定の型でしか動かないコードになってる。
人間が型を意識しているのに型を書かないなんてただの手抜きだよ。

例えば valueは何型でしょうか?
function foo(value) {
}

valueには複数の(クラスまたは値)型が入ってくる可能性があるから、
fooを呼び出している所すべてを見ないと型がわからない。
もしくはコードの中身を見て推測(完璧ではない)するしかない。

該当行の遠くを見ないと型がわからなくても、
小規模開発なら遠くといってもたいしたことないので問題無いだろう。
でも大規模だと ”時間がかかる” んだよね。わかる分からないの話じゃない。
テスト通せばいいとかいう話でもない。”時間がかかる” という大きな問題。

valueには何が入るってわざわざコメント書くのなら、型を書いたほうがいいじゃないか。

133 :デフォルトの名無しさん:2013/03/13(水) 22:33:43.25
fooを呼び出す側を見に行ってvalueの型を調べる?アホか
お前OOPに向いてないよ

134 :デフォルトの名無しさん:2013/03/13(水) 23:05:30.37
で? お前の意見がなにもないのがいい証拠だな。

135 :デフォルトの名無しさん:2013/03/13(水) 23:13:53.93
そうとも言えない。
コンパイラ判断で、文脈から推論して静的型付けできるケースは多い。
つまり、文脈から自明なら、型指定は省略しても構わないと思う。
C++11 の auto や C# の var は秀逸。

136 :デフォルトの名無しさん:2013/03/13(水) 23:21:21.23
>>135
autoやvarは関数の引数には使えないでしょ?

あくまでローカル変数。そしてローカルスコープの中には
最低1つは型が書いてある。

つまり方が省略されていても、ローカルスコープだけを
ざっと見れば型がしっかり書いてある状態になるから
それは問題ないんだよ。

問題はスコープが広い所からどう使っているかわからないとか
ローカルスコープであっても、コードの使われ方(呼び出してるメソッドは何か?)を
全部調べなきゃわからないような状態だと
時間がかかる わけさ。

137 :デフォルトの名無しさん:2013/03/13(水) 23:24:03.30
function foo(value) {
 value.hoge();
 bar(value);
 value.hage();
}

もしこんなコードがあれば、barの中まで探らなきゃいけない。
さらにbarの中で他の(ry

138 :デフォルトの名無しさん:2013/03/13(水) 23:26:37.73
>>136
ライブラリ側の事を言ってるの?
実装にジェネリクスが使えるなら、使わない理由はないし、
使う方も、ジェネリクスなら型を明示する必要はあまりないと思うよ。
また、できる限りそうあるべきだと、俺は思う。

君の言っているケースでのみも議論するなら、確かにその通りだと思うよ。
型を前提した関数なら、型を明示するべき。
そこに異論は全くない。

139 :デフォルトの名無しさん:2013/03/13(水) 23:51:08.23
メソッド名が被るとか、見ても分からないとかナンセンスすぎ
他と被りようがない一意な名前を付ければ良いじゃない
例えば

IterativeDeepeningAlphaBetaSearchUsingKillerMoveOrderingAndTranpositionTableSimpleMaterialAndPositionalEvaluationChooseRandomlyBetweenBestMovesStrategy

みたいなメソッド名や変数名に付ければ、絶対に他と被らないし、型なんて書かなくても一発で分かる

140 :デフォルトの名無しさん:2013/03/14(木) 00:07:28.79
>>139
賛成。

141 :デフォルトの名無しさん:2013/03/14(木) 00:31:11.75
>>139
満足した?

142 :デフォルトの名無しさん:2013/03/14(木) 06:47:24.14
Javaってウンコだね

143 :デフォルトの名無しさん:2013/03/14(木) 06:57:30.13
いまさら言うまでもない

144 :デフォルトの名無しさん:2013/03/14(木) 07:32:26.38
>>139
で、どんな型なんだよ?
全くわかんねーよw

145 :デフォルトの名無しさん:2013/03/14(木) 07:52:31.90
ググったらJavaのコードだったから
Java使いなら分かるんだろう

アホ的に冗長なコードを好むJavaらしい命名だね

146 :デフォルトの名無しさん:2013/03/14(木) 08:49:49.31
>>128
setTextの描画先が違う、setTextの結果がバッファリングされる。
それぐらいなら、多態性の一種でしかないけど?
例えば、入力する文字列が、正規表現じゃないといけないとか、
JSON形式じゃないとダメってなら、仕様は異なる。
そういう特異な場合でなければ一緒にしたって問題はない。
それがダメだと思うならJavaに毒されてるし、OOにゃ向いてない。

147 :デフォルトの名無しさん:2013/03/14(木) 09:17:01.64
なんだここでも「向いてない」論議か。
もういい加減、OOなんて止めたら。

148 :デフォルトの名無しさん:2013/03/14(木) 09:20:03.70
>>146
でもさ、polymorphismが使いこなせなきゃ
関数型言語なんてもっと無理だよ

149 :33:2013/03/14(木) 11:41:07.51
多態性なんて、全く没交渉にOOPは使えるでしょ。同様にそれに相当する
思考なしに、関数型言語も問題なく使えるのではないかな。

150 :33:2013/03/14(木) 11:49:42.53
私は「LISPに帰ろう」。その意は、記号処理の立場から出直そう。
だから、このスレでは最初から外れてますから、無視して結構です。

151 :デフォルトの名無しさん:2013/03/14(木) 18:08:29.45
>>131
気配り効いてないライブラリー使ってる限りは不便極まりないじゃん。
Swing然り、Collection Framework然り。
SortedSetとかアレなんなんだよ。Setに無かった制約が、SortedSetになって追加されとる。
無理にSetとSortedSetでaddを共有せず別々にしとけばよかったのに、
一度addがついてるSetを公開してしまったせいで、SortedSetのaddと、Setのadd分離できなくなってる。
signatureなんかのDuck Type方式なら、Setに対し、addを呼ばない関数ならいくらでも再利用できて、
SetとSortedSetのaddをごちゃまぜにする必要なかった。

152 :デフォルトの名無しさん:2013/03/14(木) 21:31:29.44
それでも型があるから大規模開発に耐えられる。

153 :デフォルトの名無しさん:2013/03/14(木) 21:52:23.81
Javaは耐えきれずに頻繁にデスマってますがな

154 :デフォルトの名無しさん:2013/03/14(木) 21:53:32.66
同じぐらいの人数でやったら
型がない言語のほうがもっとデスマになるね。

所詮人数が少ない時にだけどうにかなる言語。

155 :デフォルトの名無しさん:2013/03/14(木) 21:58:40.61
signature方式は静的型チェックが働くぞ
Javaは糞だがな

156 :デフォルトの名無しさん:2013/03/14(木) 22:03:15.09
静的型付けだったら何でも良いってわけじゃないんだよ
Javaは糞

157 :デフォルトの名無しさん:2013/03/14(木) 22:36:18.27
interfaceがクラスにへばりついてるってやり方が最早古い。
C++や.Net系言語でもtemplateやDynamicその他の拡張で
徐々に分離可能になってきてるがJavaは未だ改善の兆候がない。
尤もVMに縛られてるから不可能なんだろうがな。

158 :デフォルトの名無しさん:2013/03/14(木) 22:45:59.80
Java厨はコードに密結合を生むのが好きなんだよ

159 :デフォルトの名無しさん:2013/03/14(木) 22:59:30.76
動的型付け言語にインターフェースが
ないと思ってるの?

コンパイラが認識できないだけで、
人間はインターフェースを認識してるんだよ。
メソッドが必要というインターフェースをね。

160 :デフォルトの名無しさん:2013/03/14(木) 23:24:58.98
動的型付け言語だって処理系は型を認識してるだろ
型チェックが走るのが実行時ってだけの話だ
一度もテストで実行しないコードをリリースしちゃうような
お粗末な現場でもなければ問題にならん

161 :デフォルトの名無しさん:2013/03/14(木) 23:59:16.06
>>160
実行時に型チェックするぐらいなら
実行前に型チェックすればいいじゃないか。

実行時だと全パターンチェックしないとわからないんだぞ。
2の何十乗パターンが有ると思ってるんだ?

162 :デフォルトの名無しさん:2013/03/15(金) 04:50:08.65
>>161


163 :デフォルトの名無しさん:2013/03/15(金) 04:53:18.10
>>161みたいなのが、xUnitも通らない、ビルドで警告たっぷり吐き出される、ただコンパイラが通っただけのバグまみれのコードをコミットするんだな。

164 :デフォルトの名無しさん:2013/03/15(金) 07:41:31.39
オプショナルな型付けとか型アノテーションってどうなの。
動的型付け言語を使っている人にとっては融通さをスポイルするので邪道なのかな。

165 :デフォルトの名無しさん:2013/03/15(金) 08:33:43.67
別にいいんじゃね?
でも、Strongtalkでもう決着ついたことだと思ってるけど。

166 :デフォルトの名無しさん:2013/03/15(金) 16:07:41.54
dartやhaxeみたいなベターJavaScriptの中にもオプショナルな型付けの言語があるよね。

167 :デフォルトの名無しさん:2013/03/15(金) 22:21:00.97
型とかあんま難しく考えなくていいんだよ。
あんなのコメントと一緒。

この変数や引数には○○なオブジェクトが
入りますっていうコメント。

数学的計算をするのなら、数値型が入るって書くだろうし、
日数計算するなら、日付型が入るって書くだろうし、
showとhideメソッドを呼び出しているのなら、
showとhideインターフェース型が入るって書くだろう。

型っていうのは、コメントを書く代わりに
コンピュータが解釈して、簡単なミスを検出してくれる
便利なものって考えればいいよ。

コンピュータがなくても小さなものなら
人力でもなんとかなる。その程度のものだよ。

168 :デフォルトの名無しさん:2013/03/16(土) 04:30:42.77
Java使いらしい意見だな
頭悪そう

169 :デフォルトの名無しさん:2013/03/16(土) 05:22:17.54
型付けの静的/動的なんて難しく考えなくていいんだよ
静的だろうが動的だろうが、いずれにしろ処理系による型チェックは走る

むしろ型の強さの方が重要

170 :デフォルトの名無しさん:2013/03/16(土) 12:26:45.35
>>169
型チェックが走るかどうかが問題なのではなくて、
それがいつ走るかが問題なのでは?

いずれ走るのであれば、型チェックはやっぱり
必要ということだろう?

171 :デフォルトの名無しさん:2013/03/16(土) 14:15:58.49
>>168
何か内容に問題がある?

172 :デフォルトの名無しさん:2013/03/16(土) 15:48:35.32
>>170
型チェックはそれだけではテストとして不十分なので
自動テストを走らせる必要がある

どうせ自動テストは走らせるんだから、
型チェックが行われるのがコンパイル時でも
自動テストのときでも変わらん

173 :デフォルトの名無しさん:2013/03/16(土) 15:58:28.46
テスト走らせるまで書き損じに気づけないというのも不便な話ですね。
型に厳格な言語と賢いIDEであれば書いている最中に凡ミスは随時指摘されるのに。
テストするにしてもオールグリーンになるまでの手戻りの手間は違ってくる。

174 :デフォルトの名無しさん:2013/03/16(土) 16:04:44.21
>>172
自動テストって自分で書かないといけないものってわかってないのかな?
自分で書く以上、ミスは生じるものだよね。

自動テストは不完全なものなわけで、
実行すれば、型チェックが終わるってなんで思うの?

175 :デフォルトの名無しさん:2013/03/16(土) 16:05:27.92
動的型でもタイポくらいは気付けるよ、最近のIDEをなめちゃいかん

176 :デフォルトの名無しさん:2013/03/16(土) 16:07:24.91
>>174
型チェックは不完全なものなので、型だけ厳密でも意味ないんだわ
まあ、RDBからデータ引っ張って来てHTMLに流し込む程度の
ドカタシステムなら別だけど

177 :デフォルトの名無しさん:2013/03/16(土) 16:08:04.43
テストってのは仕様とあっているかを調べるもの。
だから仕様と違っていたとしても、プログラムは動く。
動くから、人間がテストを書かないといけない。

でも、型チェックというのは、仕様とは無関係。
コーディングミスなので、間違っていれば動かない。

仕様と合っているかを調べるテストと
書き損じを調べるチェックは本質的に違うもの。
書き損じのチェックのためにテストを流すのは
間違ったやり方。

178 :デフォルトの名無しさん:2013/03/16(土) 16:08:42.11
>>175
見つけられるタイポがあるだけ。

メソッドやプロパティのタイポは見つけられない。

179 :デフォルトの名無しさん:2013/03/16(土) 16:10:29.31
>>176
> 型チェックは不完全なものなので、型だけ厳密でも意味ないんだわ

いや、当たり前だろ。

そもそも、書き損じのチェックは
仕様確認のテストではない。

コンパイルチェックと、テストは
本質的にやってることが違う。

お前が言ってるのは、統合テストがあれば
単体テストは不要と言ってるのと同じ事だよ。

180 :デフォルトの名無しさん:2013/03/16(土) 16:11:03.80
>>175
IDEであっても動的言語相手だと補完や修正の打率が全然違う。

181 :デフォルトの名無しさん:2013/03/16(土) 16:12:05.41
>>180
どんなIDEを使ったことあるの?Smalltalkは?

182 :デフォルトの名無しさん:2013/03/16(土) 16:14:03.28
コンパイルチェックをテストだと思うからダメなんだわ。

C言語でプログラミングしていた時代の人なら、
コンパイルに通ってからが、テスト開始だってわかってるはず。

「コンパイルに通ったのでバグはない」という
勘違い超初心者はいたらしいけど。

183 :デフォルトの名無しさん:2013/03/16(土) 16:15:16.77
テスト工程の前段階が存在するということに気づけば、
前段階であるコンパイルチェックを
テスト工程に持ち越す愚かさが理解できるだろう。

184 :デフォルトの名無しさん:2013/03/16(土) 16:15:46.91
>>181
今となってはろくに使われない言語の特定実装の話をしてもらっても理屈倒れでクソほどの役にも
立たないので、今日広く使われている動的言語での話をしてくれないかな。

185 :デフォルトの名無しさん:2013/03/16(土) 16:17:51.11
>>183
REPLで実行しながらコード書いてるから、
型チェックどころか振舞いまで
その場で確認しがららコーディングしてるよ

え?テストまで振舞いも確認できないの?遅れてるー

186 :デフォルトの名無しさん:2013/03/16(土) 16:18:08.39
前段階工程 → 単体テスト工程 →統合テスト工程


簡単に図式化してみた。

前段階工程でやれることを単体テスト工程に持ち越すことは
単体テスト工程でやれることを統合テスト工程に持ち越すのと同じ事。

統合テスト工程があれば単体テストは不要ですよ?理屈上はね。
本当にそう思いますか?

187 :デフォルトの名無しさん:2013/03/16(土) 16:19:45.54
うん。やっぱり静的型で厳密に型チェックすべきだよな。
だから静的型付け関数型言語の時代だよ。

188 :デフォルトの名無しさん:2013/03/16(土) 16:20:37.15
>>184
は?Smalltalkが現在使われてないとでも?

189 :デフォルトの名無しさん:2013/03/16(土) 16:21:06.99
使われてないとは言っていないが、
殆ど使われてないというのはあってるな。

190 :デフォルトの名無しさん:2013/03/16(土) 16:22:09.79
>>185
それ実際にやればわかるけど、面倒くさすぎ。
いちいち止めて再実行しないといけない。
テスト以前に開発に時間がかかる。
動かさないでさっさと書いたほうが速い。

191 :デフォルトの名無しさん:2013/03/16(土) 16:23:51.48
>>190
いちいち止めて再実行www
REPL使った事ないの?

192 :デフォルトの名無しさん:2013/03/16(土) 16:26:35.52
>>191
間違ってコードを実行してしまった時、
どうしますか?

止まらくていいブレークポイントで停止、実行
止まらくていいブレークポイントで停止、実行
止まらくていいブレークポイントで停止、実行
やっとさっきの場面に戻ってきたw

193 :デフォルトの名無しさん:2013/03/16(土) 16:27:33.78
>>192
ほんとに知らなかったwww
ブレークポイントwww

194 :デフォルトの名無しさん:2013/03/16(土) 16:30:34.06
使った事無いから
いま必死にREPLを調べてます

195 :デフォルトの名無しさん:2013/03/16(土) 16:35:48.15
>>187
中身は関数型でも動的型でも何でも良い。ただライブラリを書く人間は外面のAPIはちゃんと
型付きで厳格な形で提供して欲しい。

そうすれば自分は型付きのメリットを享受しつつ手を抜きたいところや融通を効かせたいところ
は型無しで書くから。オプショナルな静的型付き動的型言語さいこ〜。

つまるところ、静的言語・動的言語・オプショナルな静的型付き動的型言語・関数型言語が
一通り揃っていてまぜこぜで使えるJVMファミリーは便利。

196 :デフォルトの名無しさん:2013/03/16(土) 16:39:34.93
ユニットテストっていうのは、間違いを見つけるのは簡単だけど、
その間違いを修正するデバッグ行為は楽ではないんだよ。

不具合の原因を追求するってことだからね。

ただの書き損じのために、わざわざデバッグ作業を始めるなんて
馬鹿だと思わないかね?時間の無駄だとは思わないかね?

書き損じはテストを書かなくても、コンパイラが知らせてくれるような
いいような簡単なミスなのに。

197 :デフォルトの名無しさん:2013/03/16(土) 16:40:12.87
>>193
どう? 反論する方法は思いついた?

198 :デフォルトの名無しさん:2013/03/16(土) 16:42:42.26
>>194
http://shirusu-ni-tarazu.hatenablog.jp/entry/2012/06/24/051114
pry-nav
pry-navというgemを使うと、
デバッグ実行するための以下のコマンドが使えるようになります。

199 :デフォルトの名無しさん:2013/03/16(土) 16:43:22.01
>>197
え?ブレークポイントの話題を引っ張ってほしいの?
Java厨はREPL使った事無くて、
デバッガで実行するのとREPLの区別付かないんだなーってだけでしょ?

200 :デフォルトの名無しさん:2013/03/16(土) 16:45:17.79
http://nodejs.jp/nodejs.org_ja/docs/v0.4/api/repl.html

REPL
Read-Eval-Print-Loop (REPL) は単独のプログラムとしても他のプログラムに
手軽に取り込む形でも利用することができます。 REPL は対話的に
JavaScript を実行して結果を確認する手段を提供します。
デバッグやテストやその他の様々なことを試す用途で利用されます。

201 :デフォルトの名無しさん:2013/03/16(土) 16:47:02.86
http://labs.timedia.co.jp/2011/12/rubyist-should-use-pry.html

簡易デバッガとして使う

Rubyのコードを書いていてある程度の量になってくると、個々のモジュール
はRSpecによるユニットテストにがっちり守られていても、やはり、
ソフトウェアを開発する以上デバッガの恩恵を受けたいものです。
往々にして、個々のモジュールを結合したときに、予想できなかった問題が発生するものだからです。
原因をすばやく追及するために、デバッガはプログラマにとって必要不可欠なツールでしょう。

実は、Pryの真の機能はREPLではなく、この先ほどのオブジェクトの調査機能にあるようにデバッガとしての機能によるものが多いです。

202 :デフォルトの名無しさん:2013/03/16(土) 16:53:14.96
>>195
ここ最近はずっと、個々の言語が生産性で競うというより、
Javaを筆頭とするJVMファミリーと
C#を筆頭とする.netファミリーと
C/C++を基盤とするUNIXファミリーの戦いになっている

203 :デフォルトの名無しさん:2013/03/16(土) 16:56:02.10
どうでもいいけど、ソフトウェアの開発っていうのは
0から作ることはほとんどなくて、
既存の何かの修正なんだよね。

それを本能で理解しているかどうかで、あぁこいつ
ちゃんとした開発やったこと無いな。
サンプル程度のやつを0から書いてみただけだなってことがわかる。

204 :デフォルトの名無しさん:2013/03/16(土) 17:03:08.09
どうでもいいけど、Javaドカタの言う「ちゃんとした開発」ってのは
ネットからサンプルコードをコピってきて
フレームワークの穴埋めするだけなんだよね

普通の開発者とは議論が噛み合ないから、あぁこいつ
Javaドカタだなってことがわかる。

205 :デフォルトの名無しさん:2013/03/16(土) 17:03:42.76
>>202
そうだね。

RubyやPythonといった言語はUnixファミリーに含めて良いのかな。
Cで書かれたライブラリを使うのにSWIGを使うとは言え言語ごとにラッパー書くのは
未だに面倒だし、言語Aから言語Bのライブラリを使うブリッジの類は幾つか存在して
いても、JVMや.netファミリーのようにファミリー内の言語全員がすぐに使える形で
ライブラリを書くのはUnixファミリーではなかなか難しい。

そしてSmalltalkはどこのファミリーに入れてあげれば良いのだ?

206 :デフォルトの名無しさん:2013/03/16(土) 17:08:12.75
>>204
って思いたいんでしょ?w

207 :デフォルトの名無しさん:2013/03/16(土) 17:13:19.10
テストは誤りを見つけるもので
誤りがないことを示すものじゃないってのは常識


テストは型誤りを見つけるもので
型誤りがないことを示すものじゃないってのは常識

静的型付け言語のコンパイルチェックは、型誤りがないことを示すもの。

208 :デフォルトの名無しさん:2013/03/16(土) 18:11:45.68
>>205
> Cで書かれたライブラリを使うのにSWIGを使うとは言え言語ごとにラッパー書くのは
> 未だに面倒だし、

最近はCで書かれたライブラリを使う目的でSWIG使わなくなった
大抵ラッパーが容易されてるってのもあるけど、直接呼び出すのも簡単になったから
下の例はPython

from ctypes import *
libm = cdll.LoadLibrary('/usr/lib/libm.so')
libm.sin.argtypes, libm.sin.restype = [c_double], c_double
print(libm.sin(0.5))



> JVMや.netファミリーのようにファミリー内の言語全員がすぐに使える形で
> ライブラリを書くのはUnixファミリーではなかなか難しい。

こっちは同意。全員が使える形のライブラリを書こうと思ったら
現実的にはC/C++しか無い
もっとも、JVM向けにライブラリ書く場合でも俺ならJavaを選ぶ
枯れてない言語で基盤ライブラリ書くなんて時間の無駄。開発工数の問題じゃない

209 :デフォルトの名無しさん:2013/03/16(土) 18:16:15.02
>>205
> そしてSmalltalkはどこのファミリーに入れてあげれば良いのだ?

どこにも入らないから、しばしば議論に入ってきてるけど場違い感がハンパない

210 :デフォルトの名無しさん:2013/03/16(土) 19:41:54.38
>>178
え?今時メソッドのタイポも見つけられないIDEがあるの?

具体的に挙げてみてよ

211 :デフォルトの名無しさん:2013/03/16(土) 19:44:08.15
>>209
ドカタ言語じゃないから、>>202にあるようなファミリーには分類しにくいねw

212 :デフォルトの名無しさん:2013/03/16(土) 19:51:49.41
Smalltalkはドカタ言語じゃないけど、それが理由で>>195に分類できないんじゃない
jvmや.netやunixと並ぶ環境だから

213 :デフォルトの名無しさん:2013/03/16(土) 19:52:46.93
間違えた>>202だった

214 :デフォルトの名無しさん:2013/03/16(土) 20:22:05.66
SmalltalkはJVMや.NET、UNIX等の
エコシステムから取り残された箱庭言語

後発の言語が「あえて」環境を抱え込まず
エコシステムの一部になる方針を取っているのに、
Smalltalk使いはSmalltalkが特別な言語だから環境とセットになっていると思ってる

そりゃマイナー言語ですわ

215 :デフォルトの名無しさん:2013/03/16(土) 21:10:32.97
>>210
引数のオブジェクトが持つメソッドのタイポとかも見つけてくれるの?

216 :デフォルトの名無しさん:2013/03/16(土) 21:11:53.33
具体的なIDEの名前が聞きたいだけだろ?
動的型付け言語でIDEなんてないから
でてこないと踏んでIDEの名前を聞いたってところだろう。

217 :デフォルトの名無しさん:2013/03/16(土) 21:15:48.25
>>208
ただ最近は意識しないで使っていたライブラリもソース引っ張ってきて開けてみればscala
でしたってパターンも多い。

使う分には何で書かれているのか全然気にしなくて良いのは楽。mavenのおかげで多言語混在
のプロジェクトも気兼ねなく配布出来るし。

218 :デフォルトの名無しさん:2013/03/16(土) 21:33:41.32
社内のサイドワークでJavaとPython、それとErlangで共有する実装をCで書く部分を
担当しているのでEclipseにPDTを入れているけど、頑張っているとはいえやはりJDTには
届かないなぁ。

219 :デフォルトの名無しさん:2013/03/16(土) 21:38:12.10
>>218
PythonでEclipse + PDTってどういうこと?

220 :デフォルトの名無しさん:2013/03/16(土) 21:46:06.33
>>219
ん、ごめん。PyDevだっけ。Python用のプラグインとしか認識していなかったので名前ど忘れ
していた。PDTはPHPか。

221 :デフォルトの名無しさん:2013/03/16(土) 22:07:51.46
>>220
PyDevってJDTと比較しようかと思うくらいには頑張ってるんだ。
ちょっと興味出てきた。どの辺が頑張ってた?

222 :デフォルトの名無しさん:2013/03/16(土) 22:20:21.94
ないよりはマシぐらい程度は頑張ってたな。

223 :デフォルトの名無しさん:2013/03/16(土) 22:35:12.88
なんだ。使った事がないから、具体的なことには答えられません、ってか。
せっかく話のネタになりそうだったのに。

224 :デフォルトの名無しさん:2013/03/16(土) 22:59:09.63
>>223
う〜んとね。何に驚いたかというと言語混在モジュールので(あとメインの担当は
Javaなので)Eclipse上にプロジェクト作ってJava、C、Pythonと全部突っ込んで
開発したのだけれども(Erlangは他の人の担当)、言い方は悪いけれども普通に
使えたのに驚いた。

Eclipse上のJavaの開発と同様に補完もビシバシ効くし、代入時の行を見て型もある
程度推測してくれる。名前変更程度のリファクタリングも小さいプロジェクト内で
あれば実用的な範囲で出来る。
あとデバッガもJava他のその他の言語と全く同じUIで出来るのは何気に助かったな。

このPython開発はあくまでサイドワークなので他にPython向けの良い開発環境が
あるのかは知らないけれども、Eclipse使いで多言語を同時に扱うのであれば凄く
便利だと思った > PyDev

225 :デフォルトの名無しさん:2013/03/16(土) 23:01:12.30
> 代入時の行を見て型もある
> 程度推測してくれる。名前変更程度のリファクタリングも小さいプロジェクト内で
> あれば実用的な範囲で出来る。

それってローカルスコープ限定の機能でしょ?

226 :デフォルトの名無しさん:2013/03/16(土) 23:09:12.65
>>225
当然レキシカルに特定できる範囲に限られるけれどもローカルスコープに限らないよ。

227 :デフォルトの名無しさん:2013/03/16(土) 23:17:31.31
まあ、それにPythonってあんまりOO全開じゃなくて
総称関数ベースの手続き型(ちょっと関数型風味もあり)な言語なので
importの補完とモジュール名.関数名の補完が効くだけで十分だったりもする
もちろんレキシカルに特定できるならメソッドも補完できるが

228 :デフォルトの名無しさん:2013/03/16(土) 23:45:00.92
>>226
ローカルでもレキシカルでもいいけど、
範囲が狭いなら、それは人力でもなんとかなるんだよね。

問題は広い範囲。

コードを見るだけじゃ、影響範囲が把握できない。って状態が
一番大変で、そこを一番にコンピュータ化したいんだよ。

229 :デフォルトの名無しさん:2013/03/17(日) 00:24:21.46
>>228
ローカルでもレキシカルでもどっちでもいいって、ホントにプログラマの発言かよ。
広い範囲ってのは、具体的に何を指してる?

230 :デフォルトの名無しさん:2013/03/17(日) 00:34:55.85
>>229
普通にローカル・レキシカルよりも広いスコープでしょ?
分かりやすく言うのなら、修正対象のファイル以外。

修正対象のファイルだけ見ればいいのなら、修正は楽だけど、
修正対象のファイル外に、影響を及ぼすものは修正が大変だよ。
例えばパブリックメソッド名を変えたら、そのファイル外に影響をおよぼすでしょ?
だからそれをコンピュータの力で楽をしたいと思うわけ。

人力でもできることは、人力でもいい。
人力じゃ大変な所を、コンピュータにやらせなきゃ。

そういう発想。大事だよ。

231 :デフォルトの名無しさん:2013/03/17(日) 00:40:27.30
>>230
レキシカルスコープの対比がファイルスコープかよ。
馬鹿すぎて卒倒しそうだわ。

で、ファイルが違ってもレキシカルに特定できるなら問題ないけど、何か?

232 :デフォルトの名無しさん:2013/03/17(日) 00:41:34.20
>>229
> ローカルでもレキシカルでもどっちでもいいって、ホントにプログラマの発言かよ。

お前日本語がわからないんじゃね?

この場合は、ローカルとレキシカルの区別は付けなくてもいいとかいう話じゃなくて、
スコープが広い方が影響範囲が大変という話において、
ローカルとレキシカルはどっちも影響範囲は狭いから、
どっちでも大した違いがないって意味だろ。

233 :デフォルトの名無しさん:2013/03/17(日) 00:42:33.90
>>231
> で、ファイルが違ってもレキシカルに特定できるなら問題ないけど、何か?

ファイルが違っていてレキシカルに特定できる場合って?
具体的なコードでお願い。どの言語でもいいよ。

234 :デフォルトの名無しさん:2013/03/17(日) 00:48:22.88
>>232>>233
ヒントあげるよ
レキシカルスコープ/ダイナミックスコープ
スコープの広さはぜーんぜん関係ありませーん

235 :デフォルトの名無しさん:2013/03/17(日) 01:01:18.58
>>234
そんなこと知ってる。
その上で、お前がちゃんと答えを出せるか聞いてる。

236 :デフォルトの名無しさん:2013/03/17(日) 01:25:42.35
> ローカルでもレキシカルでもいいけど、
> 範囲が狭いなら、それは人力でもなんとかなるんだよね。

> 普通にローカル・レキシカルよりも広いスコープでしょ?
> 分かりやすく言うのなら、修正対象のファイル以外。

> ローカルとレキシカルはどっちも影響範囲は狭いから、


こんだけ馬鹿さらしておきながら

>> スコープの広さはぜーんぜん関係ありませーん
> そんなこと知ってる。

いやー、そりゃ無理すぎでしょ。3アウトですよ。

237 :デフォルトの名無しさん:2013/03/17(日) 01:56:38.77
Pythonの補完の話になんでいきなりダイナミックスコープが出てくるんだよ。
始末に負えない馬鹿だなこりゃ。

238 :デフォルトの名無しさん:2013/03/17(日) 02:30:58.24
バカというか単にレキシカルの意味がわかっていないだけでしょ。
228あたりでそんな雰囲気は漂っているが230で確定、以降は単に弄って遊ばれている。

239 :デフォルトの名無しさん:2013/03/17(日) 02:33:07.85
で、さっさと違うファイルでも
レキシカルに特定できる
言語いったら?w

240 :デフォルトの名無しさん:2013/03/17(日) 02:50:57.96
むしろ出来ない言語を挙げてくれ。

241 :デフォルトの名無しさん:2013/03/17(日) 02:55:33.37
Ruby、PHP、Perlあたりだな。

242 :デフォルトの名無しさん:2013/03/17(日) 06:46:01.54
レキシカルスコープすら理解せずに型付けの議論をしてたのか、このアホは…

243 :デフォルトの名無しさん:2013/03/17(日) 08:05:36.52
ファイルが違うとレキシカルに特定できないってことは、
クロージャの中で別ファイルの変数/関数を参照したり、
生成したクロージャを別ファイルの中で利用したり出来ないってことか。
すげーな。そんな言語見た事ねぇ。

244 :デフォルトの名無しさん:2013/03/17(日) 13:07:35.32
静的有効範囲( Lexical scope, also Static scope )
http://whatis.techtarget.com/definition/lexical-scoping-static-scoping

要約:
静的有効範囲とは、変数の有効範囲を
翻訳前にCode block内部だけに制限する管理方式。
対となる変数の管理方式として、動的有効範囲( Dynamic Scope )が存在する。
こちらは、Code blockの外部からでも変数を操作することが出来る。

注:
静的有効範囲は、一般に言うタダのScope
動的有効範囲はEmacs lispなどでも使われている方式。関数の呼び出し元によって
見える変数が変化する。このため動的という言葉が名前が付く。

で、ここで言ってるLexical scopeってなんぞえ?

245 :デフォルトの名無しさん:2013/03/17(日) 13:13:03.09
ちなみに、LexicalのLexとはLexerのLexと同じ。
構文を意味する。つまり構文に基づく有効範囲という意味になる。

246 :デフォルトの名無しさん:2013/03/17(日) 13:21:07.42
動的な局所変数なんて概念存在すんだろうか

247 :デフォルトの名無しさん:2013/03/17(日) 13:22:15.64
>>225
で、君が主張するレキシカルには分析できないような、静的型付けでしか不可能な補間機能というのを説明してくれたまい。

248 :デフォルトの名無しさん:2013/03/17(日) 13:26:29.26
>>247
そもそもなんで、ローカルスコープの話に
レキシカルが出てくるの?

249 :デフォルトの名無しさん:2013/03/17(日) 13:27:33.07
>>248
>>225へのレスが>>226だから

250 :デフォルトの名無しさん:2013/03/17(日) 13:28:26.15
>>247

void foo(KURASU kurasu) {
 kurasu.hoge(); ← KURASU型だとわかってるから補完できる。
}

void foo(kurasu) {
 kurasu.hoge(); ← 何型かわからないから補完できない。
}

251 :デフォルトの名無しさん:2013/03/17(日) 13:29:18.48
いやー、たぶん>>230
静的型付けならファイルを超えてレキシカルな構造を特定できるが
動的型付けだと無理だ、と言いたかったんだと思うよ

なんでそんな発想に至ったのか理解不能だけどwww

252 :デフォルトの名無しさん:2013/03/17(日) 13:30:36.04
>>250
普通にできるけど?あほ?
動的型のマトモな環境使ったことないの?

253 :デフォルトの名無しさん:2013/03/17(日) 13:31:39.73
ファイル超えたって
普通にモジュール化とimport機能がある言語なら
普通に補完もタイポ検出も可能だよなー

254 :デフォルトの名無しさん:2013/03/17(日) 13:31:49.24
>>252

foo(KURASU1)
foo(KURASU2)

KURASU1にはhogeがあるが
KURASU2にはhogeがない

void foo(kurasu) {
 kurasu.hoge(); ← 何型かわからないから補完できない。
}

255 :デフォルトの名無しさん:2013/03/17(日) 13:33:03.40
foo(KURASU1)
foo(KURASU2)

KURASU1にはhogeがあるが
KURASU2にはhogeがない

void foo(kurasu) {
 kurasu.hoge(); ← この部分でブレークしてもKURASU2が入っている時に、KURASU1が入った場合のhogeは補完されない。
}

256 :デフォルトの名無しさん:2013/03/17(日) 13:33:59.41
つまり、動的型付け言語の、コード補完には
信頼性がない。

257 :デフォルトの名無しさん:2013/03/17(日) 13:35:20.67
動的言語の場合、補完というより候補だしてるだけだからね。
その候補以外でもコンパイルに通ってしまう。
実行時じゃないと本当にエラーにすべきかどうかわからない。

258 :デフォルトの名無しさん:2013/03/17(日) 13:35:28.91
>>214
環境と独立したSmalltalk言語なんていくらでもあるんですがね。
GNU Smalltalk然り、Dolphin然り、VistaSmalltalk(#Smalltalk)然り、Redline Smalltalk然り。

259 :デフォルトの名無しさん:2013/03/17(日) 13:36:09.88
>>254
普通にできるけど?あほ?
動的型のマトモな環境使ったことないの?

260 :デフォルトの名無しさん:2013/03/17(日) 13:37:48.45
>>259
じゃあやってみせてよw

ちなみに、fooの呼び出しは
fooの定義のレキシカルスコープ外に
あるものとします

261 :デフォルトの名無しさん:2013/03/17(日) 13:38:59.48
>>256
ばか?
コード補完に信頼性がないんじゃなくて
実際言語仕様的にそういうコードがvalidであり得るのだが?

これから君のことはKURASU君と読んであげよう。よかったね。

262 :デフォルトの名無しさん:2013/03/17(日) 13:39:16.35
template<class Type> void Example( const Type &value )
{
   value.Function(); //補完できない
}

263 :デフォルトの名無しさん:2013/03/17(日) 13:39:20.96
くっそ何も反論できない。
こうなったら!

動的型のマトモな環境使ったことないの?

(そんなの無いけどねw)

264 :デフォルトの名無しさん:2013/03/17(日) 13:40:10.14
>>260の神聖あほっぷりに世界が沸いたw

265 :デフォルトの名無しさん:2013/03/17(日) 13:40:33.86
>>262
それテンプレートじゃんw

マクロのようなものと考えればいい。
マクロがコード補完とか意味わからん。

マクロを使った時にコード補完されるから問題ないんだよ。

266 :デフォルトの名無しさん:2013/03/17(日) 13:40:43.65
>>263
くやしいねえ、KURASUくんww

267 :デフォルトの名無しさん:2013/03/17(日) 13:41:06.17
まさに>>263が正解って感じがしてきたなw

268 :デフォルトの名無しさん:2013/03/17(日) 13:42:21.04
やってみせられないことが
全てを物語っているよな。

269 :デフォルトの名無しさん:2013/03/17(日) 13:43:51.89
やってみせられないって…どうやって見せるの?
KURASU君みたいにアホ丸出しのコードをここに書き込んで
何かの証明になるとでも思ってるの?ばかなの?あほなの?

270 :デフォルトの名無しさん:2013/03/17(日) 13:43:55.41
ていうか、ここのKURASU君(良い名前だw)に
動的型言語でinvalidなコードを書いてみて貰ったら良いんじゃないか?

なお、invalidってのは処理系にとって未定義な振舞いで、例えばseg faultするようなヤツな

271 :デフォルトの名無しさん:2013/03/17(日) 13:43:58.40
> 動的型のマトモな環境使ったことないの?
ふいたw

動的型にまともな環境無いじゃん。
いつもテキストエディタで書いてるじゃん

Smalltalkだけは例外でいいよ。
あれはIDEと実行環境が一体化した変な世界だから。

それ以外の動的型言語にまともな環境はない。
あるなら知りたいくらいだ。
いい加減テキストエディタの開発やめたいんだよね。

272 :デフォルトの名無しさん:2013/03/17(日) 13:44:17.44
-(void)withString:(*NSString) value // 動的型付
{
  puts( [value UTF8String] );//補完できる
}

template<class Type> void Example( const Type &value ) // 静的型付
{
   value.Function(); //補完できない
}

273 :デフォルトの名無しさん:2013/03/17(日) 13:44:35.91
>>270
> なお、invalidってのは処理系にとって未定義な振舞いで、例えばseg faultするようなヤツな

それは違う。

274 :デフォルトの名無しさん:2013/03/17(日) 13:45:14.50
>>273
じゃあ、お前の定義は?

275 :デフォルトの名無しさん:2013/03/17(日) 13:45:21.42
>>265
詭弁だねぇ

276 :デフォルトの名無しさん:2013/03/17(日) 13:46:15.83
PyDev も Python tools for Visual Studio も vim (+ipython) も
環境込みで動いてる

277 :デフォルトの名無しさん:2013/03/17(日) 13:46:36.03
>>265
>マクロを使った時にコード補完されるから問題ないんだよ。
意味がさっぱり判らん。もっと人間に優しく説明しておくれ

278 :デフォルトの名無しさん:2013/03/17(日) 13:47:02.82
俺にとってinvalidというのは、実行時に必ず
想定外の動作をするコードだな。

279 :デフォルトの名無しさん:2013/03/17(日) 13:47:54.76
>>271
で、Smalltalk環境でできることが他の動的言語ではできない理由は?

ちなみにKURASU君が大好きそうなEclipseもSmalltalk由来だから
Smalltalkで作った環境がノーカウントだとするとEclipseもノーカウントだぞw

280 :デフォルトの名無しさん:2013/03/17(日) 13:48:13.56
>>273
違うというなら無効(invalid)以外の言葉で条件を定義したら?
異常終了とか。

281 :デフォルトの名無しさん:2013/03/17(日) 13:48:22.20
>>277
テンプレートってのは雛形。
コードそのものではなく、
コード生成機

コード生成器 → コード生成 → コンパイル

こういう流れだから、コード生成した時に
検出できるので問題ないという話。

282 :デフォルトの名無しさん:2013/03/17(日) 13:48:34.10
>>278
それって言語仕様や処理系にとって想定外ってことだよね
まさか言語がエスパーして人間の想定を考慮するはずないもんね

283 :デフォルトの名無しさん:2013/03/17(日) 13:48:43.16
>>278
「想定外」なんていう脳内仕様を要求する基準を持ち出す時点でアウトだなw

284 :デフォルトの名無しさん:2013/03/17(日) 13:49:10.42
>>281
補完の話してたろ都合よくすり替えるなよ

285 :デフォルトの名無しさん:2013/03/17(日) 13:49:29.24
>>279
それは悪魔の証明だな。

君が出来るという証拠を示せばそれで話は終わりだよ。
Smalltalk以外で。
できないなら、そういうことだ。

286 :デフォルトの名無しさん:2013/03/17(日) 13:50:06.86
かぶったw
まあ健康な脳を持つプログラマなら普通に気付く間違いだがw

287 :デフォルトの名無しさん:2013/03/17(日) 13:51:41.78
じゃあinvalidの定義「バグ、コードを修正することでしか、直せない問題。」でどうだ?

288 :デフォルトの名無しさん:2013/03/17(日) 13:51:43.72
>>279
Objective-CとXcodeなら出来るぞ。

289 :デフォルトの名無しさん:2013/03/17(日) 13:51:59.28
>>285
つまりKURASU君の主張を裏付けるためには悪魔の証明が必要だと。
なんていい加減な主張をするんだろうね、KURASU君はw
「まともな環境はない」と断言したからには、ちゃんと理由を示せよww

290 :デフォルトの名無しさん:2013/03/17(日) 13:52:15.05
ほう、できるというのなら、
その証拠を出すんだ。
今なら勝てるぞ!

291 :デフォルトの名無しさん:2013/03/17(日) 13:52:59.35
悪魔の証明どころか、れっきとした反例が出ちゃったね、KURASU君w

292 :デフォルトの名無しさん:2013/03/17(日) 13:53:08.05
>>289
いや、無いの証明をするのは難しいっていうのが
悪魔の証明ってやつだから。

そんなのを要求するほうが頭が悪いで話は終わるんだよ。

293 :デフォルトの名無しさん:2013/03/17(日) 13:53:12.70
>>287
いい加減Engrishみたいに横文字に執着すんのやめたら気持ち悪い

294 :デフォルトの名無しさん:2013/03/17(日) 13:54:59.83
>>290
Objective-CとXcodeなら[NSString s]と打ち込んだ所で、NStringの
selector一覧が出る。

295 :デフォルトの名無しさん:2013/03/17(日) 13:55:42.28
なんか勘違いして勝ったつもりの奴がいるが、
http://ja.wikipedia.org/wiki/Objective-C
弱い静的型付け
^^^^^^^^^^^^^^^^^

だぞ?

296 :デフォルトの名無しさん:2013/03/17(日) 13:57:15.07
>>295
落ちにワロタw

297 :デフォルトの名無しさん:2013/03/17(日) 13:59:10.26
Pythonならこんなモノがある。

Python Omni Completion
http://www.vim.org/scripts/script.php?script_id=1542

Features:
Dynamic type deduction (without actually evaluating statements) #動的に型を特定
Local visibility handling (will complete from all parent scopes). #親の可視範囲から型を特定
completeopt=preview support, displaying python docstrings # 略
Function argument completion (whenever possible) # 引数補完

298 :デフォルトの名無しさん:2013/03/17(日) 13:59:22.13
>>295
バラすなよ。
せっかくいい感じで
釣れたのにw

299 :デフォルトの名無しさん:2013/03/17(日) 13:59:23.98
>>295
Objective-CのCの部分は弱い静的型付けだが、
OO部分は完全にSmalltalk由来の動的型付けだ

300 :デフォルトの名無しさん:2013/03/17(日) 14:01:31.95
>>299
だからこういうことになるわけですね

http://ponpoko1968.hatenablog.com/entry/20101030/1288395400

> 実は、どうやら最新のバージョン2.8においても、objective-cの
> クラスやメソッドを認識する機能が実装されていないようで、
> C言語の関数しか補完候補に現れません。

301 :デフォルトの名無しさん:2013/03/17(日) 14:01:49.61
>>295
うんにゃそれはWikipediaの定義でしかないし、
Cの側面からみた定義でしかない。
あんたらの問題視している範囲から言えば動的型付言語だ。
じゃなにかい?Objective-Cも静的型付言語だから、
静的型付言語も実行時に型異常を起こすから危険って事でいいのかい?

302 :デフォルトの名無しさん:2013/03/17(日) 14:02:41.59
Objective-Cは静的型付け言語です。

303 :デフォルトの名無しさん:2013/03/17(日) 14:03:01.84
>>301
その下読んだ?

> 2010/11/1補記:
> どうやらobjective-Cクラス/メソッドも認識しているようです。

304 :デフォルトの名無しさん:2013/03/17(日) 14:03:09.92
>>300
もうXcodeは4.x時代ですが、時空の間に取り残された人ですか?

305 :デフォルトの名無しさん:2013/03/17(日) 14:04:23.09
つーか、型定義がある時点で静的型付けでしょ?

いや、正確にはNSStringみたいな型定義がないと
補完できないわけでしょ?

306 :デフォルトの名無しさん:2013/03/17(日) 14:04:26.25
KURASU君が必死にググって対抗しようとしてるのが笑える

307 :デフォルトの名無しさん:2013/03/17(日) 14:05:25.16
これってつまり、動的型付け言語で補完したいなら
静的型付けと同じような、型定義が必要って話になってるんじゃね?

308 :デフォルトの名無しさん:2013/03/17(日) 14:05:48.31
http://en.wikipedia.org/wiki/Objective-C#Dynamic_typing

309 :デフォルトの名無しさん:2013/03/17(日) 14:05:49.92
>>305
> つーか、型定義がある時点で静的型付けでしょ?

馬鹿すぎ

310 :デフォルトの名無しさん:2013/03/17(日) 14:08:25.16
>>307
>>297

>>305
翻訳時に型解決してないので、どうあがいても動的型付けです。
それがわからないなら入門書で動的と静的の違いをもう一回お勉強したら?

311 :デフォルトの名無しさん:2013/03/17(日) 14:10:21.78
で、Java厨は>>297をかたくなに無視してんのはなんでだ?

312 :デフォルトの名無しさん:2013/03/17(日) 14:11:34.76
-(void)withString:(*NSString) value // 動的型付
{
  puts( [value UTF8String] );//補完できる
}

template<class Type> void Example( const Type &value ) // 静的型付
{
   value.Function(); //補完できない
}

313 :デフォルトの名無しさん:2013/03/17(日) 14:12:42.95
>>311
Java厨が忌み嫌うエディタで出来るなんて我慢できないから

314 :デフォルトの名無しさん:2013/03/17(日) 14:15:38.65
そもそも、動的型付ならMethodが存在しなくても正常に実行できるんだけどな。
そういう事が出来ない時点で、静的型付というか(というと失礼なので)Javaは糞だよ。

315 :デフォルトの名無しさん:2013/03/17(日) 14:20:02.04
動的型付け言語でも型定義があれば補完できる。

型定義の重要性を再認識することになった。

316 :デフォルトの名無しさん:2013/03/17(日) 14:20:41.39
そうだね。でもそれは、静的、動的の問題じゃないね。スレ違いだね。

317 :デフォルトの名無しさん:2013/03/17(日) 14:20:58.35
>>314
それは仕様通りに動くという意味じゃないだろう?

バグが有っても、バグと認識できずに動いてしまうという話だよね?

318 :デフォルトの名無しさん:2013/03/17(日) 14:21:54.35
>>316
別スレってことは
別のスレを立てろって言ってるのかい?

319 :デフォルトの名無しさん:2013/03/17(日) 14:23:07.37
>>318
建てたければ立てればいいんじゃないの?

320 :デフォルトの名無しさん:2013/03/17(日) 14:23:37.00
ActiveRecordすら知らないと来た
いや、名前は聞いたことあるけど仕組みは理解できてない、か

321 :デフォルトの名無しさん:2013/03/17(日) 14:24:15.99
>>317
NULL objectとかListener objectとかProxy objectとか仕様通りですけど。

322 :デフォルトの名無しさん:2013/03/17(日) 14:24:48.30
>>318
スレタイは「レキシカルスコープも型付けも分かりません、助けて!」に決定

323 :デフォルトの名無しさん:2013/03/17(日) 14:25:11.89
>>320
Active Recordというよりメッセージ転送の話だよ

324 :デフォルトの名無しさん:2013/03/17(日) 14:26:09.03
こんなかんじでどうだ?

「型定義の重要性 〜 コーディングミス解決,補完,etc」

本質的ではないバグに翻弄される人々
タイプミスにどんだけ時間奪われたか計算してみ?

動的型付け言語であっても、型定義があることで
さまざまな問題を解決出来ます。

Objective-Cは定義が存在する動的型付け言語の一つです。

325 :デフォルトの名無しさん:2013/03/17(日) 14:27:19.38
>>321
NULL objectとかListener objectとかProxy object 以外では
仕様通りじゃないということですか?

326 :デフォルトの名無しさん:2013/03/17(日) 14:27:54.86
>>324
いいねそれw
それでいこう。

327 :デフォルトの名無しさん:2013/03/17(日) 14:28:07.01
>>323
そんなの実用的じゃないって返されないように有名な適用例をあげてみた

328 :デフォルトの名無しさん:2013/03/17(日) 14:28:16.63
型定義が存在しない言語となると、
javascriptとself、shell scriptぐらいか。
はようたててこい

329 :デフォルトの名無しさん:2013/03/17(日) 14:29:04.99
>>325
鳥でなければ空は飛べないのですか?

330 :デフォルトの名無しさん:2013/03/17(日) 14:29:33.25
Active Recordは設計がおかしい。

ModelとActive Recordはis-a関係でないのに
Active Recordを継承してModelを作っている。

実用されているが、間違った例だ。

331 :デフォルトの名無しさん:2013/03/17(日) 14:30:05.95
>>328
LazyKも入れよう

332 :デフォルトの名無しさん:2013/03/17(日) 14:30:47.90
型定義というのは
変数にって意味だろ?

333 :デフォルトの名無しさん:2013/03/17(日) 14:31:28.15
>>330

Smalltalk時代から似たようなもんはあるし、( doesNotUnderstand )
そういう設計にこだわってておかしいのはJava厨だけだけどな。

334 :デフォルトの名無しさん:2013/03/17(日) 14:31:51.06
変数に型定義がないっていうのは

Class1 a; みたいなのはなくて全て
var a; みたいになっているもののことか?

それなら結構有りそうだな。
PHP、Perlあたりとか。

335 :デフォルトの名無しさん:2013/03/17(日) 14:32:37.66
>>332
お前だけなんか色々言葉の定義がおかしいわ。
学生もしくは発達障害か?

336 :デフォルトの名無しさん:2013/03/17(日) 14:33:06.40
>>333
Active Record設計者も
設計がおかしいことに気づいて
直そうとしているみたいだけど?

337 :デフォルトの名無しさん:2013/03/17(日) 14:33:24.68
そういうのは型注釈という

338 :デフォルトの名無しさん:2013/03/17(日) 14:33:43.44
>>336
Active Record知らんけど、ソースくれ。

339 :デフォルトの名無しさん:2013/03/17(日) 14:33:46.27
おまんこ

340 :デフォルトの名無しさん:2013/03/17(日) 14:35:12.08
>>334
template<class Type> void Example( const Type &value ) // 静的型付
{
   value.Function(); //補完できない
}
これどうなるんだろうな

341 :デフォルトの名無しさん:2013/03/17(日) 14:35:53.76
>>340
それテンプレートだから関係ない話じゃない?

342 :デフォルトの名無しさん:2013/03/17(日) 14:36:16.41
>>336
メッセージ転送を使うところは一緒
Ruby的には継承よりmixinのほうが良いよねーってだけ

343 :デフォルトの名無しさん:2013/03/17(日) 14:37:16.49
>>330
確かに、ModelとActive Recordの関係はおかしいかもな。
Smalltalkなんか、Objectの派生は全てModelとして動作するし。
まぁ、Active Recordが悪いって話にはならんわ。
Model設計のもんだいだ。

344 :デフォルトの名無しさん:2013/03/17(日) 14:39:50.43
>>338
http://blog.remarkablelabs.com/2012/12/activemodel-model-rails-4-countdown-to-2013
> ActiveModel::Model is a module mixin that allows Ruby objects to work with Action Pack.
> What this means is you can now include ActiveModel::Model in a plain old Ruby class,


plain old Ruby class

いや楽しいねw

Plain Old Java Object 通称POJO に
やっとたどり着いたって感じだ。

345 :デフォルトの名無しさん:2013/03/17(日) 14:41:07.19
>>341
あえてtemplateが除外される理由はない。
奴らにとって問題の焦点は補完出来るかどうかが全てだからな。

346 :デフォルトの名無しさん:2013/03/17(日) 14:42:44.16
テンプレートも具体的な型を使えば
補完されると思うけど?

347 :デフォルトの名無しさん:2013/03/17(日) 14:44:29.54
>>344
結局Modelの問題で、Active Recordの問題じゃないんだろ。
>>330 をよく読まず突っついたのが悪かったが、
別にメッセージ転送云々の問題じゃないから、>>330 の話は
無視しときゃよかったんだよな。

348 :デフォルトの名無しさん:2013/03/17(日) 14:44:33.80
>>338
これまでこう書いてたのを

class Foo < ActiveRecord::Base
end

こう書こうってだけ(こうすれば単一継承のRubyでもFooがActiveRecord以外を継承できる)

class Foo
  include ActiveRecord::Model
end


全然メッセージ転送と関係無い

349 :デフォルトの名無しさん:2013/03/17(日) 14:44:36.79
>>340
JavaのGenericsなら、そのvalueはただのTypeじゃなくて
「Functionメソッドを持ったクラスを継承したType」って
書くんだけど、C++ではそういうこと出来ないの?

350 :デフォルトの名無しさん:2013/03/17(日) 14:45:44.23
>>349
継承している必要がないからな

351 :デフォルトの名無しさん:2013/03/17(日) 14:46:27.86
>>346
具体的な型を指定しない場合の話してるんだろ

352 :デフォルトの名無しさん:2013/03/17(日) 14:49:08.98
>>350
でもvalueはFunctionを持っている必要が有ることは
コードをみれば明らかじゃん?

ならvalueはFunctionメソッドを持ったインターフェースを
継承している必要があるじゃん。

353 :デフォルトの名無しさん:2013/03/17(日) 14:50:20.82
>>352
> ならvalueはFunctionメソッドを持ったインターフェースを
> 継承している必要があるじゃん。

これがJava脳か……

354 :デフォルトの名無しさん:2013/03/17(日) 14:51:17.73
>>348
こう書こうってだけで終わらないことを祈るよ。

include ActiveRecord::Modelで追加されたメソッドは
原則としてプライベートメソッドとして扱うべき。
継承じゃないんだから。

そこにみんな気づくといいんだがね。

355 :デフォルトの名無しさん:2013/03/17(日) 14:52:36.10
>>353
Java脳が嫌いなら、valueはFunctionメソッドを
持っている必要があるって言い換えてもいいけど?

356 :デフォルトの名無しさん:2013/03/17(日) 14:56:53.29
valueがFunction関数を必要とするかは、
value.Function()と書いたか、書かなかったかで決まる。
必要かどうか決めるのは、Example関数自身なんだよ。

357 :デフォルトの名無しさん:2013/03/17(日) 14:58:01.10
>>354
気づけばいいね。Rubyスレに殴りこんで議論してきたら?
歓迎してくれるよ。きっと。

358 :デフォルトの名無しさん:2013/03/17(日) 14:59:42.59
いい話よのう。まるでJavaの歴史をなぞっているかのようだ。

「サブクラス化するのは、スーパークラスの実装をよく知っているときに限るべきだ」
http://d.hatena.ne.jp/k-sato_at_oiax/20100722/1279803193

Rubyでは、サブクラスで親クラスのprivateメソッドやインスタンス変数を上書きしてしまい、見付けづらいバグを出すことがあります。
このことについて、オライリーの『プログラミング言語Ruby』P248では、次のように述べています(P250も参照)。

「Rubyでサブクラス化するのは、スーパークラスの実装をよく知っているときに限るべきだ。
クラスのパブリックAPIだけが必要で、その実装は不要なら、クラスを継承するのではなく、
カプセル化と委譲によってクラスの機能を拡張すべきだ。」

えー。RailsではActiveRecord::BaseやActionController::Baseを継承しないと何もできないのに。

== コメント ==

ActiveRecord の後継と目される DataMapper では、継承を使わずに Mix-in を採用していますね。
継承を使いすぎたという反省が、Rails 業界にあるんじゃないかと思います。

359 :デフォルトの名無しさん:2013/03/17(日) 15:00:55.43
スレ違いだからRubyスレでやってこい

360 :デフォルトの名無しさん:2013/03/17(日) 15:02:59.66
俺は、private関数なんて使ったことないわ。
privateなMethodなんて存在意義を感じないし。
大半の言語じゃ存在しないから必要性も全然感じない。

361 :デフォルトの名無しさん:2013/03/17(日) 15:03:55.00
ほら、>>360を見て、馬鹿か釣りですよ?

362 :デフォルトの名無しさん:2013/03/17(日) 15:06:03.54
Member関数方式じゃなくMessage&Method方式で敢えて、
privateな処理が欲しけりゃBlockやLambda使えばいいしなぁ。

363 :デフォルトの名無しさん:2013/03/17(日) 15:06:55.72
Java厨が早速反応している

364 :デフォルトの名無しさん:2013/03/17(日) 15:12:51.06
お前が反応したw

365 :デフォルトの名無しさん:2013/03/17(日) 15:27:38.38
結局、Javaと同じ言語仕様が正解で
Javaと違うのは間違い、と言いたいんだろう?

だって静的型・動的型に関わらず、Javaと違う仕様には
全部噛み付いてるからね

366 :デフォルトの名無しさん:2013/03/17(日) 15:34:13.33
そもそもこのスレってずっとJava厨vs他だろ

367 :デフォルトの名無しさん:2013/03/17(日) 15:38:45.53
>>358
Javaは素の状態で委譲が簡単にできないから、
継承多様しまくりだよな。
Message方式の言語ならMessage転送で済むから、
ある種の委譲目的以外では継承する必要が無い。

368 :デフォルトの名無しさん:2013/03/17(日) 15:42:03.85
まぁなんだAutometed Delegationや、Duck Type、Message Forward。
これらが出来ない所でJavaの生産性は糞低い。ここは覆しようがない。

369 :デフォルトの名無しさん:2013/03/17(日) 15:53:55.07
>>292
証明できないような主張をするほうが馬鹿w

370 :デフォルトの名無しさん:2013/03/17(日) 15:59:49.60
>>368
それらができることと、
生産性が結びつかないんだけど?

371 :デフォルトの名無しさん:2013/03/17(日) 16:05:51.65
不要なものを書かなければ生産性は上がるのは当然。
そんな事もわからないの?

372 :デフォルトの名無しさん:2013/03/17(日) 16:07:19.22
interfaceを10分考えている間に他の作業が出来る。
それだけで十分生産性が上がる。

373 :デフォルトの名無しさん:2013/03/17(日) 16:34:44.29
>>371
> 不要なものを書かなければ生産性は上がるのは当然。

言い換えると、必要な物を書けば生産性は上がるってことになるんだけど。

374 :デフォルトの名無しさん:2013/03/17(日) 16:36:35.24
プログラミングって、書く時よりも、
コードを読む時のほうが
時間が多くかかるって知ってる?

http://gihyo.jp/dev/clip/01/orangenews/vol41/0009
> 海外で有名な技術者向けブログ「Coding Horror」の記事の翻訳です。
>
> 開発者は「コードを書く」ことに多くの時間を費やしていると答えますが,
> 実際に観察すると「コードの理解」に7割以上,「コードの修正」に2割,
> コードを書くのはたった数パーセントしか費やしていないことが明らかになったようです。

375 :デフォルトの名無しさん:2013/03/17(日) 16:42:00.06
コードを書く時間よりも理解する時間のほうが
大幅にかかるのであれば、
このメソッドを呼び出しているのはどこだー?と
ソースコード全体をくまなく調べあげるよりも
さくっと一覧表示させたほうが開発効率は良くなる。

376 :デフォルトの名無しさん:2013/03/17(日) 16:52:01.90
>>373
言い換えになってない

不要なものを書かなければ→元は不要なものがあった
必要なものを書けば→足りないものを足した

国語から学び直せ

377 :デフォルトの名無しさん:2013/03/17(日) 16:55:45.67
>>376
まず「不要」の定義をしろよ。

378 :デフォルトの名無しさん:2013/03/17(日) 16:57:33.57
面倒なんで先読みしてレスするわw

それは、なくても出来るというだけで、
ないほうが生産性上がるの根拠になってないだろ。

例えば、自転車はなくてもたどり着ける。
だが、自転車があったほうが速くたどり着ける。
足のほうが柔軟性はあるがね。

379 :デフォルトの名無しさん:2013/03/17(日) 17:00:55.66
>>374
Graphviz使うような場面だから、静的型動的型関係ねぇなぁ

逆に大量のinterfaceや、AdapterやProxyのためだけに大量に生成したコードは
Graphivizなんか使った時の可読性を下げる。

380 :デフォルトの名無しさん:2013/03/17(日) 17:05:55.35
>>377
その他の言語なら書かなくて済んだコード。

381 :デフォルトの名無しさん:2013/03/17(日) 17:15:04.03
>>118がいい例だよな

382 :デフォルトの名無しさん:2013/03/17(日) 17:57:54.33
JLabelとJTextFieldのメソッドが名寄せできる程度で生産性云々を誇られても。
JLabelとJTextFieldに関してはそもそも名寄せが必要な場面って殆ど無いし。

こんなことが出来るぜと誇る割には出てくる具体例にあまり有り難みがない。
必要も無い例をネタに言語機能を誇ったところで空しいだけだよね。

383 :デフォルトの名無しさん:2013/03/17(日) 18:20:16.62
ああ、KURASU君、きみはOO での多態の意味がまるでわかってないんだね

384 :デフォルトの名無しさん:2013/03/17(日) 18:55:29.48
敵は皆同一人物病発病か。

385 :デフォルトの名無しさん:2013/03/17(日) 18:57:01.45
え、あんな馬鹿が何人もいるの?

そらすげえな()

386 :デフォルトの名無しさん:2013/03/17(日) 19:17:10.72
>>385
お前もその馬鹿だろ
見え見えだって

387 :デフォルトの名無しさん:2013/03/17(日) 19:19:24.30
>>382
JavaでMVCやりたくなったらそれしか無いだろw
Javaならな。

388 :デフォルトの名無しさん:2013/03/17(日) 19:19:33.58
gdgd化作戦成功してよかったねKURASU君

389 :デフォルトの名無しさん:2013/03/17(日) 19:22:17.63
>>387
なんで、その他の方法ができないと思った?
お前がやろうとしていることは、全てできると思って間違いないよ。

390 :デフォルトの名無しさん:2013/03/17(日) 19:23:23.39
MVCと多態に何の関係があるんだ?
最低限メッセージ送る仕組みさえ作れば出来るんだが。

391 :デフォルトの名無しさん:2013/03/17(日) 19:24:04.05
>>388
よくわからんが、成功組と
失敗組がはっきりしたのか?

392 :デフォルトの名無しさん:2013/03/17(日) 19:36:24.11
>>389
じゃやり方示してみな。できるもんならなlol

393 :デフォルトの名無しさん:2013/03/17(日) 19:37:56.88
>>390
関係ないよ。単にMVCを簡潔に書けるかどうかっつう話しだし。

394 :デフォルトの名無しさん:2013/03/17(日) 19:55:48.80
コードジェネレーター作ればいいだけなので
Javaでも簡潔に書ける。

395 :デフォルトの名無しさん:2013/03/17(日) 19:57:39.64
JLabelとかJTextFieldはViewの実装の詳細であってMCとの通信とは何の関係もないわな。
MVC持ち出す時点でなんか勘違いしているか時代遅れの筋の悪い作法しか知らないのでは。

396 :デフォルトの名無しさん:2013/03/17(日) 20:01:18.86
MVCは継承しないと出来ないって
Rubyの神様が言ってたんだとさ

397 :デフォルトの名無しさん:2013/03/17(日) 20:01:57.24
古かろうがなんだろうが作る作れるよな。(最新はMorphicだが)
古いものすら作れないの?
結局Duck Typeが使える言語なら簡単にできる古典的様式が
Java単体じゃ簡単にできない事が判明したわけだ。

398 :デフォルトの名無しさん:2013/03/17(日) 20:17:31.17
>>394
Javaなど人間が読み書きするに値しない
機械的にコードを生成するレベルの低級言語ってことですね、わかります

399 :デフォルトの名無しさん:2013/03/17(日) 20:26:55.88
>>394
アセンブリ言語でもいいんじゃね

400 :デフォルトの名無しさん:2013/03/17(日) 20:30:19.91
>>397
作れるし実際に広く使われているよ。
MVCするのにJLabelとJTextFieldを名寄せしたりDuckTypingが必要なケースがそもそも謎。
VとMCの通信はVの実装の詳細とは独立に定義するものだが普通。

401 :デフォルトの名無しさん:2013/03/17(日) 20:42:45.87
>>400
御託はいいから早くやれよ

402 :デフォルトの名無しさん:2013/03/17(日) 20:50:01.34
         ,-、            ,.-、
        ./:::::\          /::::::ヽ
       /::::::::::::;ゝ--──-- 、._/::::::::::::::|
       /,.-‐''"´          \:::::::::::|
     /                ヽ、::::|
    /                   ヽ|
     l                         l
    .|    ●                |    んーとね・・
     l  , , ,           ●     l
    ` 、      (_人__丿    、、、   /
      `ー 、__               /
         /`'''ー‐‐──‐‐‐┬'''""´

         ,-、             ,.-、
        ./:::::\          /::::::ヽ
       /::::::::::::;ゝ--──-- 、._/::::::::::::::|
       /,.-‐''"´          \:::::::::::|   つ
     /                ヽ、::::|   っ
    /     ノ             ヽ|
     l              ヽ         l
    .|    ●             u  |    んーっとね・・・・・・・・・
     l  , , ,           ●     l    やればできるもんっ!!
    ` 、 u    (_人__丿    、、、   /    
      `ー 、__               /
         /`'''ー‐‐──‐‐‐┬'''""´

403 :デフォルトの名無しさん:2013/03/17(日) 21:14:09.95
>>401
ご託は良いからMVCにGUIコンポーネントの名寄せやDuckTypingが必要なケースを(ry

JavaでMVCやるときのViewの設計のパターンの一つはViewのインターフェイスをViewの
実装とは無関係に定義する方法。これを実装したViewをControllerなりFacadeに差し込む。

public interface FruitListView{
 void showFruitItems(List<Fruit> fruitList);
 ...
}

次にある瞬間Viewの画面に表示するデータを保持するコンテナ、大抵はViewModelと
呼ばれるものを定義してインスタンスを注入する方法。もちろんViewModelもViewの
実装の詳細とは無関係。DIコンテナを使うWeb系のフレームワークにはこれが多い。

public class FruitListViewModel{
 List<Fruit> fruitList;
}

public interface FruitListView{
 void setViewModel(FruitListViewModel viewModel);
}

MC間とより複雑なインタラクションが必要となるGUIの場合、ViewModelではなくクラス
階層を持ったNotificationとして、Notificationとして受けておいてViewの中でRTTIで
Notificationの型を見て必要なデータと処理内容を得るのがPureMVCなんかのパターン。

最後にこれはフレームワークの支援が必要だけれども、テンプレート言語を使って書かれた
viewにViewModelをバインディングする方法。

何れにしても今日的なMVCフレームワークではViewの外面にJLabelとかいったViewの詳細
が立ち現れることはまず無い。

404 :デフォルトの名無しさん:2013/03/17(日) 21:16:18.13
「名寄せ」だってw

405 :デフォルトの名無しさん:2013/03/17(日) 21:44:19.13
>>403
JLabelとJTextFieldってさ、setTextは共有してるのに
インターフェースを共有してないから、setTextを呼び出すコードを
JLabelとJTextFieldで別々に容易しなきゃダメって話じゃないの?

そもそも実装の話なんて誰もしてなくて、structual subtypingの観点で同じコードを
重複して実装する非効率さを問題にしてたと思うんだけど、
そういうインターフェースの設計ミスが無い前提で話をしてない?

406 :デフォルトの名無しさん:2013/03/17(日) 21:57:01.88
>>405
さあ?
>>387がJavaでMVCするにはそれ(メソッド名の名寄せ)をするしかないと書いているから
んなわけね〜と書いたまでだけど。

あとさ、JLabelとJTextFieldでメソッドを分けなければいけないって、当然それらのクラスの
インスタンスを引数として受けるメソッドの事だと思うけど、具体的にどんなケースにそんな
メソッドが必要になるだろう?具体的に。

407 :デフォルトの名無しさん:2013/03/17(日) 22:00:21.14
>>403
だれもViewModelのなんてやれっつってねぇよ。
純粋なMVCやれ、別にPluggableMVCでもいいぞ。

てか、ViewModel型のMVCやるだけでもそんだけ面倒くさくなるんだな。
しかもJLabelとJTextFieldの2通りも必要とは。
そんな事してる間にDuck Typeが使える言語ならModel内部の作成に入っとるわ。

408 :デフォルトの名無しさん:2013/03/17(日) 22:15:57.59
>>407
は? 純粋なMVCだが。どこが不純か詳しく。

Viewのインターフェース定義もViewModelの導入も、VへのメッセージをVの実装とは
独立して定義する実装パターンのひとつにすぎないが。

> てか、ViewModel型のMVCやるだけでもそんだけ面倒くさくなるんだな。
>しかもJLabelとJTextFieldの2通りも必要とは。

何のためのViewModelか全く理解していないのがまるわかり。

409 :デフォルトの名無しさん:2013/03/17(日) 22:17:32.31
現実的にRhinoで実装すっとこんな感じか。
Javaより格段無駄がなくてすっきりするな。

var TextModel = function()
{
  this = new java.beans.PropertyChangeSupport( this );
  var text = "";

  this.getText = function(){ retrun text; }
  this.setText = function( value )
  {
    var old = text;
    text = value;
    this.firePropertyChange( "text", old, text );
  }
}

var modelDependencyAdapter = function( textView, model )
{
 var dependency = {};
 dependency.propertyChange = function( event ) { textView.setText( model.getText() ); };
 return dependency;
}

var model = new TextModel();
text = new JTextField();
model.addPropertyChangeListener( "text", modelDependencyAdapter( text, model ) );
label = new JLabel();
model.addPropertyChangeListener( "text", modelDependencyAdapter( label, model ) );

410 :デフォルトの名無しさん:2013/03/17(日) 22:19:51.01
>>407
あとMVCにJLabelなどのメソッド名の名寄せが必要なパターンはよ。
どうせMやCにViewのロジックが食い込んだ汚い例しか出てこないと思うが。

411 :デフォルトの名無しさん:2013/03/17(日) 22:26:29.98
>>408
http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html
この辺りを見てお勉強しなおしたらいいんじゃないかなぁ?
MVCっつうのは、複数のViewで1つのModelを映し出し、
かつそこからControllerを分離した方式の事だよ。
Modelを複数のViewで投影できないなら意味がない。

412 :デフォルトの名無しさん:2013/03/17(日) 22:29:32.34
>>410
FruitListViewが、JLabelとJTextFieldに対応するにはどうしたらいいんですかねぇ〜

413 :デフォルトの名無しさん:2013/03/17(日) 22:30:49.29
>>409
テキストをポリゴン表示するど派手なラベル部品を使いたいんだが、テキスト表示するメソッド名
がrenderTextだったらど〜する。

adapterがViewの実装に依存している点で30点。

414 :デフォルトの名無しさん:2013/03/17(日) 22:36:39.17
>>411
出来るが。これは典型的なViewがModelへの参照を持たないパターンだが何を見ているの?
ViewModelについても何か勘違いしてない?
>>412
それはViewの実装の詳細。心配せんでもJLabelとJTextFieldで別メソッドを用意せんと
いけないような場面はViewの実装では殆どないよ。あるなら>>406にレスしてくれ。

415 :デフォルトの名無しさん:2013/03/17(日) 22:45:25.91
Contoroller忘れてたのと重要なとこ忘れてたんで修正
var TextModel = function()
{
  this = new java.beans.PropertyChangeSupport( this );
  var text = "";

  this.getText = function(){ retrun text; }
  this.setText = function( value )
  {
    var old = text;
    text = value;
    this.firePropertyChange( "text", old, text );
  }
}

var modelDependencyAdapter = function( textView, model, key ) // keyはSmalltalkならSymbol、C++ならtemplateで対応する
{
 var dependency = {};
 dependency.propertyChange = function( event ) { textView[key]( model.getText() ); };
 return dependency;
}

var model = new TextModel();
text = new JTextField();
model.addPropertyChangeListener( "text", modelDependencyAdapter( text, model, "text" ) );
label = new JLabel();
model.addPropertyChangeListener( "text", modelDependencyAdapter( label, model, "text" ) );
JButton button = new JButton();
button.addActionListener( function() { model.setText( "hello"); } );

>>413
adapterはViewの一部に決まってんじゃん。Javaじゃなかったら要らねぇし。なに初歩的な事言ってんの?

416 :デフォルトの名無しさん:2013/03/17(日) 22:48:22.31
>>414
具体的にどう書くか聞いてんだよ。
JLabelとJTextが問題になってたんだから、
JLabelとJText無しで出来ますじゃ意味ないだろ。

417 :デフォルトの名無しさん:2013/03/17(日) 22:51:03.06
間違えたんで細部修正
var TextModel = function()
{
  this = new java.beans.PropertyChangeSupport( this );
  var text = "";

  this.getText = function(){ retrun text; }
  this.setText = function( value )
  {
    var old = text;
    text = value;
    this.firePropertyChange( "text", old, text );
  }
}

var modelDependencyAdapter = function( textView, model, key ) // keyはSmalltalkならSymbol、C++ならtemplateで対応する
{
 var dependency = {};
 dependency.propertyChange = function( event ) { textView.setText( model[key]() ); };
 return dependency;
}

var model = new TextModel();
text = new JTextField();
model.addPropertyChangeListener( "text", modelDependencyAdapter( text, model, "getText" ) );
label = new JLabel();
model.addPropertyChangeListener( "text", modelDependencyAdapter( label, model, "getText" ) );
JButton button = new JButton();
button.addActionListener( function() { model.setText( "hello"); } );

418 :デフォルトの名無しさん:2013/03/17(日) 23:01:55.51
ところで、標準ライブラリのOutputStreamとDataOutputの関係はどうなの?
こんな感じのコードを別々に書くことに合理性はあるの?

void example1(OutputStream out, List<byte[]> data) throws IOException {
    for (byte[] b : data) {
        out.write(b);
    }
}
void example2(DataOutput out, List<byte[]> data) throws IOException {
    for (byte[] b : data) {
        out.write(b);
    }
}

419 :デフォルトの名無しさん:2013/03/17(日) 23:25:34.95
>>414
>出来るが。これは典型的なViewがModelへの参照を持たないパターンだが何を見ているの?
出来るなら具体的にそのコードを書いてくれ

420 :デフォルトの名無しさん:2013/03/17(日) 23:46:27.06
>>419
View定義
public interface FruitView{
 void displayFruit(Fruit fruit);
}

本当はイベント配送はフレームワークに管理させるべきところだけど>>409もリスナーとして
直接ViewをModelに貼り付けているのでコードの簡略のためmodelにViewの参照を持たせる。

public model FruitModel{
 List<FruitView> views;
 public void addView(FruitView view){this.views.add(view);}
 public Fruit getFruit(){...}
 public void setFruit(Fruit fruit){this.fruit = fruit; for(FruitView view: views) view.displayFruit(fruit);}
}

Viewの実装例
public class FruitViewImpl1 extends JPanel implements FruitView{
 JLabel name; JTextField quantity;
 public FruitViewImpl1(){ /* 子コンポーネントの生成とレイアウト */ }
 void displayFruit(Fruit fruit){
  this.name.setText(fruit.getText());
  this.quantity.setText(fruit.getQuantity());
 }
}

FruitModel model = new FruitModel();
FruitView view = new FruitViewImpl1();
model.addView(view);
model.setFruit(aFruit);

名寄せ? DuckTyping? 要らないよ。ちゃんとViewが実装の詳細と独立に抽象化されていれば。

421 :デフォルトの名無しさん:2013/03/18(月) 00:01:23.38
全然本題と関係ないコード貼って何がしたいんだ……これがアスペか

422 :デフォルトの名無しさん:2013/03/18(月) 00:14:29.92
>>421
modelを複数のviewに投影することが出来る例だが、本題って何だっけ。

423 :デフォルトの名無しさん:2013/03/18(月) 02:24:53.23
事の始まりはDuckTypingできないJavaってゴミだねって話から

424 :デフォルトの名無しさん:2013/03/18(月) 02:29:23.18
どのJavaにこてんぱんにされてるw

型がきっちりしてる分、
抽象化能力が鍛えられてるんだよな。

型がないととりあえず作って
問題があったら、型調べて適当にディスパッチで
対応とかしてるから、何と何が共通の機能であるとかが適当になってる。

425 :デフォルトの名無しさん:2013/03/18(月) 02:31:20.52
>>424
>>418に答えてあげなよ。Javaだよ

426 :デフォルトの名無しさん:2013/03/18(月) 02:37:08.62
>>418
> ところで、標準ライブラリのOutputStreamとDataOutputの関係はどうなの?
別に問題ない。抽象化することで拡張性が得られている。

> こんな感じのコードを別々に書くことに合理性はあるの?
”書くこと” ではなく ”書けること” に合理性はある。

面倒であれば、別々に書かなくていいライブラリを使うか
自分で作れば良い

427 :デフォルトの名無しさん:2013/03/18(月) 02:43:45.32
>>423
とりあえずMVCに関してはDuckTyping別に必須じゃないねと言うことでFAだな。
静的型でも全然普通に出来る。

428 :デフォルトの名無しさん:2013/03/18(月) 02:46:41.70
>>426
つまり、標準ライブラリの設計が失敗してゴミで
共通の処理をまとめたくてもまとめられないウンコだから
別のライブラリ探すか自作するかしろ(標準ライブラリ使ったコードとは混ぜられないけどな)ってことですね。
分かりました!ありがとうJavaの人!

429 :デフォルトの名無しさん:2013/03/18(月) 02:48:40.03
>>428
自分に力がないのを言語のせいにするな
初心者の頃に習わなかったか?

430 :デフォルトの名無しさん:2013/03/18(月) 02:52:59.27
>>428
実際のところ>>418のようなのを両方書く必要があるケースって殆ど無いから。

431 :デフォルトの名無しさん:2013/03/18(月) 07:13:08.74
>>420
Javaになってないんですけどー
あと、あんたがしきりに言ってるフレームワークって具体的に何。

432 :デフォルトの名無しさん:2013/03/18(月) 07:16:48.58
>>420
JLabelだけを実行時に取り外せんぞ
なんつってMVCじゃねぇか。
Smalltalkなんかは、実行時にModelとViewの関係を
組み直せるメリットからMVC開発が進んだのに退化してるじゃねぇか。

433 :デフォルトの名無しさん:2013/03/18(月) 07:23:07.75
>>420
ViewをJLabelからJTextFieldに差し替えるコードを書いてくれ

434 :デフォルトの名無しさん:2013/03/18(月) 08:09:46.09
>>431
フレームワークが扱うべきなのはこの例の範囲で言うならMV間のオブザーバーパターンの実装。
これは全てのModelで共有すべき実装であって具象Modelの実装に立ち現れるのは良くない。
抽象クラスで実装するなり別のオブジェクトに委譲すべきだし、それはJavaでも簡単。

>>432
FruitViewの取り外しや追加、別実装への差し替えは常に可能だが。
Viewって何のこと言っている? JLabelやJTextFieldといった個別のGUI部品がViewだとでも?
そういう扱いも可能かもしれんが現実問題として個別のGUI部品をModelのオブザーバーとして
実装する例なんてそうそう見ないしそんなことをした日にはViewのロジックはどこに噛ますの?
沢山のGUI部品を含むViewを丸ごとごそっと差し替えるのはどうやるの?
普通はViewのロジックも含めた交換可能な単位としてViewは部品化するもんでないかい?

Modelに直接GUI部品を関連づける>>417で正直ゲゲッと思ったけれども、GUI開発でこんな
不作法がまかりとおる業界は一体どちら様方面なのか参考までに教えてくれ。

>>433
以下同文。FruitViewを継承したViewをJTextField使って実装して差し替えれば?

435 :デフォルトの名無しさん:2013/03/18(月) 08:37:13.31
>>430
OutputStreamWriterとRandomAccessFile(のサブクラス)両対応の出力コードを書くとき

436 :デフォルトの名無しさん:2013/03/18(月) 08:48:48.78
>>435
何を出力するコードさ?

437 :デフォルトの名無しさん:2013/03/18(月) 17:50:24.43
言葉よりもコードが雄弁に語ってるね
Javaが冗長でオワコンだと

こんな言語で書いてたら、そりゃIDEの補完機能に異常に拘るわけだよ
まあ、補完できようが可読性は最悪だし、
なにより動的言語でも補完できちゃうんだけどねw

438 :デフォルトの名無しさん:2013/03/18(月) 18:54:10.72
潜在的に100倍の冗長さがあり、それを生産性と勘違いした。
というところか。

439 :デフォルトの名無しさん:2013/03/18(月) 21:02:54.47
>>434
具体的にフレームワークの名前を挙げろと言ったんですけど。
ああ、結局自作しないと無いんですね。生産効率わるぅ

440 :デフォルトの名無しさん:2013/03/18(月) 21:05:47.92
>以下同文。FruitViewを継承したViewをJTextField使って実装して差し替えれば?
結局JLabel用のViewとJTextField用のViewを作るのか

441 :デフォルトの名無しさん:2013/03/18(月) 22:06:47.75
お前らいつまで書く時の話ばっかり見てるんだ?
コードは書くより読むほうが何倍も多いんだぞ。

だから生産性が高い言語使ってるはずなのに
開発期間が短くならないんだよ。

442 :デフォルトの名無しさん:2013/03/18(月) 22:11:51.17
なんかMVCパターンわかってない奴がいるみたいだね。

基本パターンは、Modelに対してViewが自分自身を登録し、
Viewがイベントを受け取るんだよ。

Modelが直接ViewのsetTextとかを呼んだりしない。
ModelはViewが持っているメソッドを意識しない。

ここまでわかっているなら、JLabelとJTextFieldの
継承関係がどうなっていようと関係ないってわかるはずだが。

繰り返すがMVCパターンの話な。MVCパターンが
面倒くさいという話ならそれは言語関係ない。

443 :デフォルトの名無しさん:2013/03/18(月) 22:14:58.38
なんかもうそろそろなんで
MVCパターンなんか使うの?
面倒くさいだけじゃんって
言う奴が出てきそうだなw

444 :デフォルトの名無しさん:2013/03/18(月) 22:16:39.55
それよりもWeb系の偽MVCと
GUI系の本物のMVCをごっちゃにしている奴がいそうだ。

偽MVCはオブザーバーパターンがでてこない

445 :デフォルトの名無しさん:2013/03/18(月) 22:27:16.72
>>442
>>440

446 :デフォルトの名無しさん:2013/03/18(月) 22:31:59.97
>>445
JavaScriptのMVCフレームワークを考えればいい。

JTextFieldというのは、<input type="text> のことだ。

Viewを作るか作らないかって?
inputタグがViewになってるフレームワークあるか?
初心者も甚だしい。

447 :デフォルトの名無しさん:2013/03/18(月) 22:41:24.90
View内部で使っているUIコンポーネントをシグニチャ的に互換性のある別コンポーネントに
(動的に)差し替えられるか?って話をしてるのに、全く話が通じてなくてワロス
都合が悪いから曲解してるのか、アスペなのか、馬鹿なのか……

448 :デフォルトの名無しさん:2013/03/18(月) 22:50:29.38
シグニチャ的に互換性があっても
機能的に互換性がないのだから
入れ替えることないだろ?
変なことを言うやつだな。
ボタンがいきなりテキストボックスなって嬉しいのか?

449 :デフォルトの名無しさん:2013/03/18(月) 22:55:11.04
ラベルとテキストフィールドに
機能的互換性があるかというと
ないよな。

テキストフィールドならsetFocusで
きるだろうけどラベルだとできないし。

450 :デフォルトの名無しさん:2013/03/18(月) 22:59:20.20
>>446
Smalltalk系の正当なMVCや、
Self, Pharoとかで使われてるMVCの最終型Morphicなんかがそうだ。
今まで、MVC、PluggableMVC、Morphicと経てきたMVCの進化の中で、
描画部分とModel入力部分が分離された事なんて一度もない。
それは、マウス操作でModelとViewを結合する必要があったからだ。
身近なところでは、ExcelのChartとSpreadsheet、それとExcelのCell同士の参照、
あれを実現するために進化してきたのが今日のMorphicでありMVCだ。

451 :デフォルトの名無しさん:2013/03/18(月) 23:02:12.31
>>449
setTextには文字を表示するという互換があるな。
interfaceでつながってないのは、設計ミスとjava.beansで
できるからっつうコトだろうけど。ちなみに、java.beansを使う環境だと、
JLabelも、JTextFieldも、setText、getTextは、xxx.textってな感じになって
共有できますね。

452 :デフォルトの名無しさん:2013/03/19(火) 04:51:09.39
なんでSmalltalkって廃れたんだろうね。

453 :デフォルトの名無しさん:2013/03/19(火) 06:59:37.44
RubyやPython用のMorphicが登場したり、.NetにSmalltalk移植されたり、
Smalltalkを例にした話題が増えたり徐々にSmalltalkが
復調してる気配があるね。

454 :デフォルトの名無しさん:2013/03/19(火) 07:16:04.12
Morphicは、Objective-C版とjavascript版も出てるぞ
Javaだけ取り残されていくな

455 :デフォルトの名無しさん:2013/03/19(火) 07:16:03.82
>>453
全体に、実務向き言語が退潮気味で、理論指向の言語が地歩を確保したり、
復権傾向にある。Smalltalk,LISP系,Prolog,関数型など。

456 :デフォルトの名無しさん:2013/03/19(火) 07:25:08.39
結論。Javaは糞。

457 :デフォルトの名無しさん:2013/03/19(火) 10:17:46.80
>>452
UNIXライクOSとそれ向けCPU(つまりCマシン)の異常な繁栄が
あるけど、
それ以前にゼロックスが売り方を二重の意味で(アラン・ケイの
考えるパソコンOSでもなく、IDEとしても価格設定やライセンスの
しかたで)間違えたから

458 :デフォルトの名無しさん:2013/03/19(火) 16:07:24.58
http://www.google.co.jp/trends/explore#q=Smalltalk
もりあがっとるもりあがっとる

http://www.google.co.jp/trends/explore#q=Java
http://www.google.co.jp/trends/explore#q=C%23
http://www.google.co.jp/trends/explore#q=Python
http://www.google.co.jp/trends/explore#q=Ruby
http://www.google.co.jp/trends/explore#q=Objective-C
http://www.google.co.jp/trends/explore#q=Scala
http://www.google.co.jp/trends/explore#q=Prolog
http://www.google.co.jp/trends/explore#q=LISP
http://www.google.co.jp/trends/explore#q=JavaScript

459 :デフォルトの名無しさん:2013/03/19(火) 18:57:55.49
>>458
http://www.google.co.jp/trends/explore#q=Squeak&cmpt=q
http://www.google.co.jp/trends/explore#q=Scratch&cmpt=q

460 :デフォルトの名無しさん:2013/03/19(火) 21:23:52.56
右下のRelated termsを見る限り別なもののトレンドなのではないか。

461 :デフォルトの名無しさん:2013/03/20(水) 00:36:54.25
Scratchみたい一般的な単語のトレンドとか何の参考にもならんだろwww
なんだ、SmalltalkerにとってはScratchと検索したら何でもSmalltalk関連かい

462 :デフォルトの名無しさん:2013/03/20(水) 01:15:45.31
DB接続、ファイル入出力、外部API使用、
何をやるにもJavaは冗長で可読性最悪。
言い訳は「そんなの書かなくてもフレームワークがやってくれるし!」

463 :デフォルトの名無しさん:2013/03/20(水) 06:38:58.11
まあフレームワークやライブラリといったソフトウェアスタック無しでJavaを使う意味は無いわな。

464 :デフォルトの名無しさん:2013/03/20(水) 12:29:35.00
一体どの言語ならフレームワークが不要になるのだろうか?

465 :デフォルトの名無しさん:2013/03/20(水) 12:33:36.40
Smalltalk系とかググらんでもだいたいわかるけど、
Javaはググらにゃ判らん事が多すぎる。
APIなんかググること前提だろ。

ちなみに、今はJavaのuninstall方法をググるのが大人気
http://www.google.co.jp/trends/explore#q=java%20uninstall&cmpt=q

466 :デフォルトの名無しさん:2013/03/20(水) 12:35:46.74
>>464
そもそもFrameworkとは何だ?Library全てがFrameworkだと思ってんの?

467 :デフォルトの名無しさん:2013/03/20(水) 12:38:36.35
>>466
フレームワークとは何だ?

Railsとかがフレームワークらしいよ。

468 :デフォルトの名無しさん:2013/03/20(水) 12:38:56.94
List of buzzwords
http://en.wikipedia.org/wiki/List_of_buzzwords

・Enterprise Service Bus[55] – also known as ESB.
・Framework[7]
・Folksonomy[42]
・Fuzzy logic[56]

469 :デフォルトの名無しさん:2013/03/20(水) 12:40:10.31
>>467
FortranにもTesting FrameworkってのがあったねFrameworkとしての共通点はなんだい?

470 :デフォルトの名無しさん:2013/03/20(水) 12:41:12.69
>>468
なにそれ? このリストに入っている奴ってなんなの?
Buzzwordとかもリストに入ってるけど?

471 :デフォルトの名無しさん:2013/03/20(水) 12:43:52.31
>>469
話ずれてるよ。

どの言語でもフレームワークがあるって話だよ。

472 :デフォルトの名無しさん:2013/03/20(水) 12:43:56.10
まぁWeb2.0やCloudと同じ薄ら寒い用語ですしおすし

473 :デフォルトの名無しさん:2013/03/20(水) 12:44:56.69
>>471
そのFrameworkとは具体的に何を指してるのか言ってくれバズワードで言われても判らん

474 :デフォルトの名無しさん:2013/03/20(水) 12:44:58.70
Web servicesもバズワードなんかいw

475 :デフォルトの名無しさん:2013/03/20(水) 12:45:32.62
>>462よ。
フレームワークとはなにか聞いてるぞw

476 :デフォルトの名無しさん:2013/03/20(水) 12:46:53.27
>>474
出典がついてんだから出典読めよ

477 :デフォルトの名無しさん:2013/03/20(水) 12:47:02.17
フレームワークの説明なんてwikipediaに任せればいいじゃん。はい終了。
http://ja.wikipedia.org/wiki/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%83%95%E3%83%AC%E3%83%BC%E3%83%A0%E3%83%AF%E3%83%BC%E3%82%AF

478 :デフォルトの名無しさん:2013/03/20(水) 12:48:03.98
日本語のクソペディアを出典にしないでもらえないでしょうか
卒論ですら禁止されてることを大の大人がやって恥ずかしくないの?

479 :デフォルトの名無しさん:2013/03/20(水) 12:48:35.62
>>476
出典ってこれかい?お前こそ読んだ?

http://knowledgemanagement.ittoolbox.com/lp/
Toolbox for IT

We're sorry, but the page you requested was not found.
You will be automatically redirected to the homepage.
If your browser does not support redirects, please click here.
Thank you for visiting Toolbox for IT.

480 :デフォルトの名無しさん:2013/03/20(水) 12:50:00.85
日本語はダメらしいねw
http://en.wikipedia.org/wiki/Software_framework

481 :デフォルトの名無しさん:2013/03/20(水) 12:56:28.02
>>480
>This article needs additional citations for verification. Please help improve this article by adding
>citations to reliable sources. Unsourced material may be challenged and removed. (April 2011)

Wikipedia以外で

482 :デフォルトの名無しさん:2013/03/20(水) 13:03:11.43
>>468
おい、英語のWikipediaもダメらしいぞw

クソペディアを出典にしないでもらえないでしょうか
卒論ですら禁止されてることを大の大人がやって恥ずかしくないの?

483 :デフォルトの名無しさん:2013/03/20(水) 13:05:17.16
オレオレ定義はいらない。
フレームワークの用語の意味を
用語サイトから引用してください。

484 :デフォルトの名無しさん:2013/03/20(水) 13:07:09.95
知りたいならGoogleで「フレームワーク 定義」で検索すればいいじゃないの?

485 :デフォルトの名無しさん:2013/03/20(水) 13:08:07.48
>>484
俺もそう思う。なんで俺に聞くのかわからない。

486 :デフォルトの名無しさん:2013/03/20(水) 13:17:05.97
>>482
じゃもっとマシな出典だしてくれ。お前に任せる。

487 :デフォルトの名無しさん:2013/03/20(水) 13:18:02.88
>>485
自分で説明できない言葉を使うなよ。ルー大柴かよ。

488 :デフォルトの名無しさん:2013/03/20(水) 13:18:26.50
>>486
出典は見つかりませんでした。俺達の負けだ。

489 :デフォルトの名無しさん:2013/03/20(水) 13:19:14.47
>>487
じゃあお前、ルー大柴って言葉を説明してみ?

490 :デフォルトの名無しさん:2013/03/20(水) 13:20:55.19
もう意味がよく判らんしTogetherでもいいんじゃね
多分それでも十分通じると思う。

462 名前:デフォルトの名無しさん [sage]: 2013/03/20(水) 01:15:45.31
DB接続、ファイル入出力、外部API使用、
何をやるにもJavaは冗長で可読性最悪。
言い訳は「そんなの書かなくてもトゥゲダーがやってくれるし!」


463 名前:デフォルトの名無しさん [sage]: 2013/03/20(水) 06:38:58.11
まあトゥゲダーやライブラリといったソフトウェアスタック無しでJavaを使う意味は無いわな。


464 名前:デフォルトの名無しさん [sage]: 2013/03/20(水) 12:29:35.00
一体どの言語ならトゥゲダーが不要になるのだろうか?

491 :デフォルトの名無しさん:2013/03/20(水) 13:22:00.01
>>490
全くわからんw

492 :デフォルトの名無しさん:2013/03/20(水) 13:24:22.54
>>489
東京都新宿区市谷冨久町出身1954年1月14日生まれの大柴 亨事だよ。
地名については地図に乗ってるから一意に解るよ。
同じ地域に1954年1月14日生まれの大柴 亨は1人しかいないから、
戸籍謄本で一意に特定できるよ。

493 :デフォルトの名無しさん:2013/03/20(水) 13:27:28.35
フレームワークの出典が見つからない
=> これまでの議論の前提が崩れる
=> Javaが完全敗北した事実も無効

494 :デフォルトの名無しさん:2013/03/20(水) 13:28:09.31
>>490
マクドナルド的にはチキンタツタの方がいい

462 名前:デフォルトの名無しさん [sage]: 2013/03/20(水) 01:15:45.31
チキンタツタ接続、チキンタツタ入出力、外部チキンタツタ使用、
何をやるにもチキンタツタは冗長で可読性最悪。
言い訳は「そんなの書かなくてもチキンタツタがやってくれるし!」


463 名前:デフォルトの名無しさん [sage]: 2013/03/20(水) 06:38:58.11
まあチキンタツタやチキンタツタといったチキンタツタチキンタツタ無しでチキンタツタを使う意味は無いわな。


464 名前:デフォルトの名無しさん [sage]: 2013/03/20(水) 12:29:35.00
一体どの言語ならチキンタツタが不要になるのだろうか?

495 :デフォルトの名無しさん:2013/03/20(水) 13:29:08.25
>>492
そんな調べてわかるような説明はいらん。
お前の定義をかけ

496 :デフォルトの名無しさん:2013/03/20(水) 13:30:05.51
>一体どの言語ならチキンタツタが不要になるのだろうか?
何かこの一文のおかげで文章が成立してる気がする

497 :デフォルトの名無しさん:2013/03/20(水) 13:30:19.24
http://e-words.jp/w/E38395E383ACE383BCE383A0E383AFE383BCE382AF.html

フレームワーク【framework】


▼ 分野
▼ 文中の用語
枠組み、下部構造、構造、組織という意味の英単語。

ソフトウェアの世界では、アプリケーションソフトを開発する際に頻繁に必要とされる
汎用的な機能をまとめて提供し、アプリケーションの土台として機能するソフトウェアのこと。
アプリケーションの雛型。開発にフレームワークを利用すると、独自に必要とされる部分だけを
開発すれば済むため開発効率の向上が見込める。具体的なソフトウェアだけでなく、
汎用的に適用できるプログラムの設計モデルや典型的な処理パターンなどを含めてフレームワークと呼ぶ場合もある。

498 :デフォルトの名無しさん:2013/03/20(水) 13:31:51.39
もしかしてフレームワークってJavaの特権だと思っていたのか?


Ruby、PHP、Perl、JavaScript
ほとんどの言語にフレームワークがあるんだけど?


はい論破

499 :デフォルトの名無しさん:2013/03/20(水) 13:32:57.24
>>495
他で調べて検証できることを、自分で書いてくれればいいんですが。
だれもオレオレ定義を書いてくれとは言ってないし、
オレオレ定義を書くなと言ってるじゃないですか。

500 :デフォルトの名無しさん:2013/03/20(水) 13:37:35.23
コンパイラ言語
http://e-words.jp/w/E382B3E383B3E38391E382A4E383A9E8A880E8AA9E.html
>同じプログラミング言語にコンパイラとインタプリタの両方が用意され、必要に応じて使い分けられるようになっている言語も多い。

支離滅裂な辞典だな
「コンパイラ言語」なんてくくりの言語存在しないだろ

501 :デフォルトの名無しさん:2013/03/20(水) 13:39:38.66
>>497
かつて存在したFoundation(基礎/土台)とは違うのですか?
Foundationじゃだめなんですか?
「Foundationはつかってません」って柴崎コウ気取りなんですか?

502 :デフォルトの名無しさん:2013/03/20(水) 13:58:24.01
>>471
話を少し戻すけれど、どの言語にもフレームワークがあるというのは、
無理があると思う。

503 :デフォルトの名無しさん:2013/03/20(水) 14:04:08.99
フレームワークが無い言語って、Brainf*ckとか?
もっともBrainf*ckですら誰かが冗談でフレームワークを作ってそうだが

504 :デフォルトの名無しさん:2013/03/20(水) 14:13:25.88
>>503
新しい言葉だから、古い言語では使わないよ。

505 :デフォルトの名無しさん:2013/03/20(水) 14:15:07.12
>>502
たしかにそのとおりだ。
だからフレームワークがある言語を言おう

Java、JavaScript、Ruby、PHP、Perl、Python

506 :デフォルトの名無しさん:2013/03/20(水) 14:16:30.87
Smalltalk (Seaside)

507 :デフォルトの名無しさん:2013/03/20(水) 14:17:39.29
>>505
サーバ・クライアント時代の言語?

508 :デフォルトの名無しさん:2013/03/20(水) 14:21:18.86
サーバー・クライアント時代ではない言語ってなんだろう?

509 :デフォルトの名無しさん:2013/03/20(水) 14:23:00.27
>>508
FORTRAN とか

510 :デフォルトの名無しさん:2013/03/20(水) 14:23:02.58
C#の場合ASP.NETがウェブフレームワークになるだろうか

511 :デフォルトの名無しさん:2013/03/20(水) 14:25:22.37
>>510
フレームワークと呼びたくないというようなことはあるだろう。

512 :デフォルトの名無しさん:2013/03/20(水) 14:27:30.19
>>511
そういう頭悪そうなレスはやめたほうがいいと思う。

513 :デフォルトの名無しさん:2013/03/20(水) 14:42:48.13
LISP,Prolog,関数型言語などでは、ライブラリを使うことでさえ、
恥ずかしいという感覚があって、フレームワークなんて拒否される。

514 :デフォルトの名無しさん:2013/03/20(水) 14:44:39.68
んなわけねーだろw

515 :デフォルトの名無しさん:2013/03/20(水) 14:48:25.54
>>513がLispやPrologにはあるのか?って質問に見えたので

http://clacklisp.org/tutorial/01-introduction.html
Clack is a web aplication environment for Common Lisp,


http://prospear.sourceforge.net/
Welcome to the home page of Prosper, a framework for developing Prolog web applications.

516 :デフォルトの名無しさん:2013/03/20(水) 15:35:20.32
Frameworkと名の付くものならCOBOLにだってあるよな
Frameworkと名が付くものが無いのはBrain Fuckとか
White spaceとかマイナー言語ぐらいになるじゃないか?

>>506
定義のらんFrameworkとやらと同列に語ってほしくない

517 :デフォルトの名無しさん:2013/03/20(水) 15:36:05.69
×定義のらんFrameworkとやらと同列に語ってほしくない
○定義の解からんFrameworkとやらと同列に語ってほしくない

518 :デフォルトの名無しさん:2013/03/20(水) 15:38:04.67
JavaにはCollection Frameworkというのがあるが、
STLはFrameworkになるのだろうか。C++側でFrameworkと
言われてるのを聞いたこと無いが。

519 :デフォルトの名無しさん:2013/03/20(水) 15:38:12.86
おまえらはバカだな
自分が書いたコードから呼び出すのがライブラリ、
自分が書いたコードを呼び出すのがフレームワークだよ

PHP、Ruby、Pythonのフレームワークは
総じて軽いから問題にならない
Javaのは…、まあおまえらが知っての通りだw

520 :デフォルトの名無しさん:2013/03/20(水) 15:39:22.66
>>519
Fotran Testing FrameworkはLibraryから呼び出されないんですけど・・・

521 :デフォルトの名無しさん:2013/03/20(水) 15:41:35.86
>>519
Task Parallelism in a High Performance Fortran Framework
これもライブラリーから呼び出されんぞ

522 :デフォルトの名無しさん:2013/03/20(水) 15:47:15.90
High Performance Fortran Frameworkな
書くの面倒だったから余計な分コピペしてもうた

523 :デフォルトの名無しさん:2013/03/20(水) 15:54:23.13
英語圏におけるLightweight programming language

英語版Wikipediaによれば、Lightweight programming languageは計算機
リソースを多くは消費しないという意味で軽量(Lightweight)であり、
C言語などが例としてあげられている。つまり、プログラマ負担の軽い言語を意味しない。
また、1997年に書かれたLightweight Languages as Software Engineering Toolsでは、
プログラミング言語内で補助的に使われる、正規表現やSQL、GLSLを、Lightweight Languagesと呼んでいる。
よって、日本における軽量プログラミング言語と欧米におけるLightweight programming languageは、
その「軽量」の意味においてまったく異なるものであるため注意が必要である。
英語でPerlやJavaScript、PHPを指し示す場合は、Scripting languageと表現するのが妥当である。

524 :デフォルトの名無しさん:2013/03/20(水) 15:55:48.37
所詮Fotran世代ってことでしょうな。
あの頃の用語は間違っていると。

525 :デフォルトの名無しさん:2013/03/20(水) 16:03:39.79
>>523
Scriptを技術的な用語として検索すると、
アプリケーション制御用の意味合いで使われる事が多いぞ。

526 :デフォルトの名無しさん:2013/03/20(水) 16:05:27.32
>>524
日本海じゃない東海ニダ

527 :デフォルトの名無しさん:2013/03/20(水) 16:05:30.41
自分が書いたコードを呼び出すのがフレームワークならイベントドリブンなAPIはことごとく
フレームワークになっちゃうな。SAX系のXMLパーサもフレームワーク。

528 :デフォルトの名無しさん:2013/03/20(水) 16:06:02.35
>>515
使っている人がいるなら別だが、使われることがないものに
フレームワークと名付けられても。

529 :デフォルトの名無しさん:2013/03/20(水) 16:08:31.54
MFCなんて当初だれもFrameworkなんて呼んでなかったのにな
今でもFrameworkなんて言われると違和感がある

530 :デフォルトの名無しさん:2013/03/20(水) 16:09:55.97
>>520-521
>>519をもう一回読んでくれ
ライブラリがフレームワークを呼び出すなんてまったく書いてない

531 :デフォルトの名無しさん:2013/03/20(水) 16:12:23.93
>>530
じゃ何が呼び出すんですかねぇ?
High Performance Fortran Frameworkなんて呼び出される要素が全然見当たらないんですが

532 :デフォルトの名無しさん:2013/03/20(水) 16:19:26.79
>>531
High Performance Fortran Frameworkを呼び出す貴方がフレームワークなんですよw

所詮制御の反転なんて関心の分離を実現する一手法にすぎないのに。
「自分が書いたコードを呼び出すのがフレームワーク」なんて良くある特徴と定義をごっちゃにしただけ。

533 :デフォルトの名無しさん:2013/03/20(水) 16:24:23.27
となるとHigh Performance Fortran Frameworkは自分で書いたコードという事になるのですか?トム

534 :デフォルトの名無しさん:2013/03/20(水) 16:28:44.75
>>533
High Performance Fortran Frameworkの気持ちになれば解る。
High Performance Fortran Frameworkというワタクシを優しく呼び出す貴方は
High Performance Fortran Frameworkにとって間違いなくフレームワーク。

535 :デフォルトの名無しさん:2013/03/20(水) 16:32:27.93
ソフトウェアフレームワーク - Wikipedia
ソフトウェアフレームワークとは、プログラミングにおいて一般的な機能をもつ共通コードをユーザーが選択的に上書きしたり特化させたりすることで、ある特定の機能をもたせようとする抽象概念のことである。
ソフトウェアフレームワークは、はっきり定義されたAPIを持ち、コードを再利用可能な形で隠蔽しているという点でライブラリとよく似ている。
しかし、ライブラリでは呼び出し側がプログラム全体の制御構造を指定できないが、フレームワークでは可能である。

Preeによれば、ソフトウェアフレームワークには「凍った部分 (frozen spot)」と「熱い部分 (hot spot)」がある。
「凍った部分」はソフトウェアシステム全体のアーキテクチャ(基本コンポーネント群とそれらの相互関係)を定義する。
それらはそのフレームワークを使って何を実装した場合でも常に変化しない。
一方、「熱い部分」はプログラマがプロジェクト固有の機能に対応したコードを追加できる部分である。
ソフトウェアフレームワークには、ソフトウェアアーキテクチャ内でアプリケーションプログラマが特定の機能に対応したコードを置ける場所(すなわち「熱い部分」)が定義してある。

536 :デフォルトの名無しさん:2013/03/20(水) 16:35:57.80
>>535

>>477-481

537 :デフォルトの名無しさん:2013/03/20(水) 17:15:32.33
単純に新しく用語が定義されたってだけじゃん。
それまでの間は定義が確定されずフラフラしていただけ。

今の定義で語れば良い。

538 :デフォルトの名無しさん:2013/03/20(水) 17:24:51.29
今の定義って何?

539 :デフォルトの名無しさん:2013/03/20(水) 17:29:05.21
Railsとかがフレームワークってことだよ。

540 :デフォルトの名無しさん:2013/03/20(水) 17:32:57.39
レスポンシブデザイン・フレームワークの「Foundation」に新版が登場。「モバイルファースト」を強化してZeptoを採用
http://jp.techcrunch.com/2013/03/02/20130228responsive-design-framework-foundation-4-launches/
FoundationなのかFrameworkなのかもうワケワカメ
そのうちFrameworkの次はFoundationとか原点回帰していくんだろうな
Application Service ProviderとSaaSみたいなもんか

541 :デフォルトの名無しさん:2013/03/20(水) 17:33:33.08
>>539
.Net FrameworkはFrameworkだけどFrameworkじゃないとか?

542 :デフォルトの名無しさん:2013/03/20(水) 17:35:32.66
Java Collection Frameworkも多分オワコンで、Java Collection Frameworkという
Frameworkじゃ何かになるんだな。

543 :デフォルトの名無しさん:2013/03/20(水) 17:35:49.97
そのFoundationは特定のフレームワーク名では?
Ruby on RailsとかSeasideのような

544 :デフォルトの名無しさん:2013/03/20(水) 17:38:25.13
Seasideって実行環境だけど、あれもFrameworkなんか。

545 :デフォルトの名無しさん:2013/03/20(水) 17:39:19.54
なんつうかアレだろ、宇宙の起源はフレームワークだとかそんな感じだろ

546 :デフォルトの名無しさん:2013/03/20(水) 17:46:02.12
いやDXとかの方が近いだろ
マツコDXと桃鉄DXみたいに、
DXとついてるものには共通点がない
ただDXがついてるためになんとなく
一体感がある

547 :デフォルトの名無しさん:2013/03/20(水) 17:49:50.95
>>472 がすべてを語ってる気がする。

548 :デフォルトの名無しさん:2013/03/20(水) 17:50:38.81
>>544
厳密な定義が無い用語だからね

http://en.wikipedia.org/wiki/Seaside_(software)
> Seaside is a free and open source web application framework for developing web applications in Smalltalk.

http://sourceforge.jp/magazine/10/09/14/0429222
> Smalltalk向けWebフレームワークの最新版「Seaside 3.0」リリース

549 :デフォルトの名無しさん:2013/03/20(水) 18:43:10.39
ぶっちゃけFrameworkには枠組み(骨組み)以外の意味はないから、
これは、Frameworkだなんて成り立たないんだよ。厳格な用語じゃない。

550 :デフォルトの名無しさん:2013/03/20(水) 21:20:26.05
フレームワークの意味について話し合うスレッドになってるな。
静的型付けも動的型付けもどっちもどっちという一定の結論がでたということでいいんだろ。
ちゃんとテストすることが前提ならどっちでもいんだけど、テストする時間が惜しいときがある。
そういうときはコンパイル段階でタイプミスを除去できるから静的型付けの方がいい。
じゃあ静的型付けが現時点で最強ということでいいな。

551 :デフォルトの名無しさん:2013/03/20(水) 21:34:44.10
フレームワークの意味について話し合うスレッドになってるな。
静的型付けも動的型付けもどっちもどっちという一定の結論がでたということでいいんだろ。
ちゃんとテストすることが前提ならどっちでもいんだけど、全体が完成するまで待つ時間が惜しいときがある。
そういうときは部分的実装の段階で実行できるから動的型付けの方がいい。
じゃあ動的型付けが現時点で最強ということでいいな。

552 :デフォルトの名無しさん:2013/03/20(水) 21:41:27.03
コンパイルエラーをテストで見つけるという考え方が
そもそもおかしいんだと思う。

コードの動きが正しいかどうかはテストがないと判定できないけど
コンパイルエラーは明らかに間違いってわかるもの。

そのためにテストを使うっていうのは
単体テストで不具合を見つけるべきものを
統合テストで見つけているようなものだと思う。

553 :デフォルトの名無しさん:2013/03/20(水) 21:56:44.21
構文の間違いを翻訳時に見つけられる動的型付言語はあるでがな。
Objecitve-Cとか。

554 :デフォルトの名無しさん:2013/03/20(水) 21:58:14.16
Objecitve-Cで見つけられる場合はあるけど
静的に決められるところだけであって
そもそも静的な範囲がすごく狭い。
つまり見つけられる場合が少ない。

555 :デフォルトの名無しさん:2013/03/20(水) 22:02:32.93
ちなみに、Objective-CでMessageに対応するMethodが見つからないのは、
実行時の例外であって翻訳時に出来る構文の間違いじゃない。
なんせMessageの宛先は別Processかもしれないし、Socketの
向こうに居るかもしれない。もしかしたらShared objectかもしれないからね(実はこれが本命)

556 :デフォルトの名無しさん:2013/03/20(水) 22:05:05.21
>>552
そうなんだよね。設計が先にあってその通りに組み上げるってんなら
あるていど許容できないでもないんだけど、プログラム書きながら
こういうやり方でいけるんじゃないかみたいにしてプロトタイプを作るときなんか
設計上の落ち度に起因するようなエラーとタイプミスとが同じレベルで通達されてくるって
いうのがどうにも嫌だ。

557 :デフォルトの名無しさん:2013/03/20(水) 22:06:06.55
>>554
静的じゃないのはMethodが存在するかしないかだけだよ。
それ以外は全て翻訳時に確認される。

558 :デフォルトの名無しさん:2013/03/20(水) 22:12:49.81
Objective-Cで実行時にMethodが見つからず例外が発生した時って、
WinAPIでSendMessage使いまくって異常が発生してる時よりDebugがマシだよ。

559 :デフォルトの名無しさん:2013/03/20(水) 22:31:54.45
そもそもコンパイルエラー全てを単体テストで
見つけられるのか?という問題がある。

実は単体テストに通ってもプロダクションコードは
正しく動かない場合が存在する。

560 :デフォルトの名無しさん:2013/03/20(水) 22:36:59.44
そんなん静的型付でも同じじゃん。Type *concrete = dynamic_cast<Type*>( abstract );を
網羅しきれるかってのと同じだろ。

561 :デフォルトの名無しさん:2013/03/20(水) 22:40:52.52
>>559
HWND window = CreateWindowEx(・・・);
SendMessage( window, UM_XXXX, yyy, zzz );
SendMessage( window, UM_XXXX, yyy, zzz );
SendMessage( window, UM_XXXX, yyy, zzz );
SendMessage( window, UM_XXXX, yyy, zzz );
SendMessage( window, UM_XXXX, yyy, zzz );
SendMessage( window, UM_XXXX, yyy, zzz );

WinAPIつかってた時代はバグだらけでマトモなプログラムは書けなかったと?

562 :デフォルトの名無しさん:2013/03/20(水) 22:41:51.92
>>560
テストを流せば、静的型付け言語のコンパイルチェックで
見つけられるエラーは全てわかると言ってる人がいるだろ?

それが間違いということ。

あとdynamic_castは危険だからあまり使わないようにするという風潮がある

563 :デフォルトの名無しさん:2013/03/20(水) 22:42:57.74
見つけられるバグの数

(静的型付け言語+コンパイルチェック+テスト) > (動的型付け言語+テスト)

564 :デフォルトの名無しさん:2013/03/20(水) 22:43:49.19
>>562
Javaはdynamic_castだらけじゃん。Objectで返すMember関数多すぎ。

565 :デフォルトの名無しさん:2013/03/20(水) 22:43:55.88
>>560 >>561
それテスト書いてないじゃんw

テスト書いても不具合が見つからない事がある
でも静的型付け言語なら見つけられる。

って話をしてるのにw

566 :デフォルトの名無しさん:2013/03/20(水) 22:45:23.08
>>565
>WinAPIつかってた時代はバグだらけでマトモなプログラムは書けなかったと?
この意味分かってる?

567 :デフォルトの名無しさん:2013/03/20(水) 22:46:49.13
>>566
開発コストがかかるって事でしょう?
そりゃそうですよ。テストがなくても人力テストが完璧なら
バグはありませんよ。

でもね。今はより早くバグを検出することが求められています。
昔の開発効率が悪い時代の例を持ってこられても困りますねぇw

568 :デフォルトの名無しさん:2013/03/20(水) 22:47:03.92
>>565
どんな不具合がみつかんの?

569 :デフォルトの名無しさん:2013/03/20(水) 22:51:00.11
>>568
型チェックエラー

動的型付け言語なら型がないから、型チェックエラーにはならず、
プロダクションコードは間違った答えを返すが一応動作し
単体テストコードは問題なく書かれている。

単体テストコードがあれば型チェックは不要というのが
間違いである例が存在する。しかも別に特殊な例ではない。

570 :デフォルトの名無しさん:2013/03/20(水) 22:55:24.46
>>567
全体の開発コストで言えば、Android向けにJavaで作るより、
iOS向けにObjective-Cで作ったほうが安くすんでるな。
期間もJavaで作った時の概ね2/3ぐらいで済む。
Emulatorが糞なのもあるが、Methodが見つかるからない事が
原因で問題が発生した事がまず無い。
自分たちでiPhone使ってて異常終了しやすいAppとか
殆ど見ないだろ。作ってる側としても実際そこが見つけにくい
問題になる事が無いんだ。

571 :デフォルトの名無しさん:2013/03/20(水) 22:56:44.94
> 全体の開発コストで言えば、Android向けにJavaで作るより、
> iOS向けにObjective-Cで作ったほうが安くすんでるな。
統計情報があれば信じるよ :P

572 :デフォルトの名無しさん:2013/03/20(水) 23:02:21.81
統計ねぇどっかにあるのかねぇ。
まぁ、うちは4本Releaseしてるけど、全般的に2/3ぐらいだったよ。
結局開発工程全体でMethodの有無が占める問題は極めて小さい。
一番重要なのは如何に俺実装を書かないか。その差が一番でかくなる。
俺実装が増えれば増えるほどバグの発生箇所が増えるわけだかね。

573 :デフォルトの名無しさん:2013/03/20(水) 23:03:39.00
つまり、俺実装を書かないというのが
安くすんでる理由なわけで、
全然Javaとか動的型付け言語とか関係ないといったも同然。

574 :デフォルトの名無しさん:2013/03/20(水) 23:08:11.43
strictモードみたいな機能がある言語だと
みんなたいていONにしてコンパイルチェックの
恩恵を受けようとしてるじゃないか?

575 :デフォルトの名無しさん:2013/03/20(水) 23:08:39.50
関係ないわけではないんだが、JavaはinterfaceとかProxyに投げれば済んだのに態々
classを書かなきゃいけないとか、Objective-Cでは書かずに済んだ
俺実装が増えやすいわけだし。

576 :デフォルトの名無しさん:2013/03/20(水) 23:10:00.21
>>574
誰がしてて、その人は成果を出せてるの?

577 :デフォルトの名無しさん:2013/03/20(水) 23:12:44.05
>>576
同じ人がstrictモードON/OFFで調べないと比較にならんだろw
誰がを聞く意味がわからん。

で、殆どの人がstrictモードONを選んでいる。
その人にstrictモードOFFを強要したら成果は下がるだろうね。

578 :デフォルトの名無しさん:2013/03/20(水) 23:14:18.66
>>575
あなたが書かずに済ます方法を知らないだけでしょう?

よくいるのが言語標準機能にないからと
毎回同じコードを書く人。
一回書けばいいだけなのにコピペをする。

そいうのはその人の問題。

579 :デフォルトの名無しさん:2013/03/20(水) 23:14:30.86
>>577
だろうね。じゃなくてどのぐらい下がったかじゃないと意味無いでしょ。

580 :デフォルトの名無しさん:2013/03/20(水) 23:16:10.35
>>578
JavaにSelector名を指定してEventを拾う方法はありますか?

581 :デフォルトの名無しさん:2013/03/20(水) 23:21:01.19
>>580
HTMLの話?
Selector名っていうのはHTML/XMLのタグを取得するものだとして、
http://jsoup.org/ セレクタであればこんなのが見つかったが

Eventってなんだ? 誰がEventを発行するんだ?

582 :デフォルトの名無しさん:2013/03/20(水) 23:22:18.45
AndoroidならWebKit + Javaの開発環境を
Googleが用意してるけど?

583 :デフォルトの名無しさん:2013/03/20(水) 23:23:46.26
面倒くさいから

Objective-CでSelector名を指定してEventを拾う方法を

聞けばいいんじゃね?

584 :デフォルトの名無しさん:2013/03/20(水) 23:25:58.87
>>578
あと、Messageの遅延送信(簡易的なlambda式)はできましたか?
ButtonのEventHandlerに対し親Viewのclassが生成した局所変数を渡すことができましたか?

585 :デフォルトの名無しさん:2013/03/20(水) 23:27:57.79
>>584
お前、手段と目的が反対になってるぞ。

586 :デフォルトの名無しさん:2013/03/20(水) 23:28:21.85
>>581
セレクターつったら、object.XXXXってあった時のXXXXの事だろ、
特定の言語に限らずセレクターと呼ぶはずだが。

587 :デフォルトの名無しさん:2013/03/20(水) 23:30:14.58
>>586
それはお前の視野が狭すぎるw

Ruby セレクター
PHP セレクター
JavaScript セレクター

なんでもいいから検索してみなよ。
特定の言語でしか使われてない用語だから。

(お前の知ってる数少ない言語以外にはない概念なんだろ?当然だって気づかないかな?)

588 :デフォルトの名無しさん:2013/03/20(水) 23:33:43.83
言語マニア(言語を作るのではなく、言語の研究が目的となってる奴)なんだろうなぁ。

589 :デフォルトの名無しさん:2013/03/20(水) 23:34:51.66
間違ったw

言語マニア(言語を使ってアプリを作るのではなく、言語の機能の研究が目的となってる奴)なんだろうなぁ。

590 :デフォルトの名無しさん:2013/03/20(水) 23:47:19.93
>>585
>>575が書かずに済ます方法があったらしいといったので、
Javaで書いた時冗長になって気になった事を書いたんですけど。
何か気になりましたか?

591 :590:2013/03/20(水) 23:48:43.79
× >>575
>>578

592 :デフォルトの名無しさん:2013/03/20(水) 23:51:25.42
>>587

Squeak
>message selector and argument names
http://wiki.squeak.org/squeak/671

Go
http://golang.jp/go_spec#Selectors
>セレクタは次の形式の基本式です。このxはパッケージ名ではありません

Objective-C
https://developer.apple.com/jp/devcenter/ios/library/documentation/ObjC.pdf
>メソッドとセレクタ

Java
http://docs.oracle.com/javase/specs/jls/se7/jls7.pdf
PrefixOp Expression3
( (Expression | Type) ) Expression3
Primary { Selector } { PostfixOp }

確かに多数派というわけではないわな。

593 :デフォルトの名無しさん:2013/03/20(水) 23:53:44.76
>>590
さっき書いただろ?

お前は手段と目的が反対になってるって
言語に特定の機能がなければ別の方法で実現すればいいだけだよ。

それが冗長になるのなら、簡単に書けるような仕組みかライブラリを
探すか一回だけ書けばいい。

さっきも書いたけど、お前は
よくいるのが言語標準機能にないからと
毎回同じコードを書く人。
一回書けばいいだけなのにコピペをする。
ってやつだろ?

どうだ図星だろう。

594 :デフォルトの名無しさん:2013/03/20(水) 23:56:04.56
ここの人たち頭いいね
ぜんぜんついていけないや
俺みたいに深くわかってないやつがいるから
業界がよくならんのかもね

595 :デフォルトの名無しさん:2013/03/20(水) 23:58:45.13
>>593
いいえ。私は無駄なものは書かない主義ですよ。
今上げた疑問はObjective-Cなら殆ど書かずに済んだ話です。
それにあなたはJavaだと書かないで済む回避策を提示できませんでしたよね。
それに疑問を上げた点は実際の開発で頻繁に使う機能ですよ。

596 :デフォルトの名無しさん:2013/03/20(水) 23:59:40.53
> それにあなたはJavaだと書かないで済む回避策を提示できませんでしたよね。

万能の回避策
コードジェネレータ

冗長でも書けるのであれば、回避策になる。
はい論破

597 :デフォルトの名無しさん:2013/03/21(木) 00:04:01.17
>>593
>言語に特定の機能がなければ別の方法で実現すればいいだけだよ。

>それが冗長になるのなら、簡単に書けるような仕組みかライブラリを
>探すか一回だけ書けばいい。

そもそも、ここの話がおかしな話。Javaだと上記の事をしなきゃいけないから
冗長だといってるんですが、話をねじ曲げてませんか?

598 :デフォルトの名無しさん:2013/03/21(木) 00:05:42.20
>>596
コードジェネレーターを使わないで済む言語の方が開発効率は良いですが。

599 :デフォルトの名無しさん:2013/03/21(木) 00:09:28.31
ある言語で書かなくて済んだ事を、ある言語だと書かなきゃいけない、ライブラリーを探さなきゃいけない
何らかの別の方法を探さなきゃいけない。なにか一手間必要になる。それは全て開発効率が
悪いってことなんですがわからないんですかね?それに、一手間加えたものは全て必要なかった
何らかの管理コストが発生する。実際開発したことあれば普通解る話なんですがねぇ。

600 :デフォルトの名無しさん:2013/03/21(木) 00:18:05.12
自前で実装する→作成の手間がかかる・保守の手間がかかる
非標準ライブラリーを使用する→メンバーへの学習コストが大きく増える・バグ管理が分散した分コストがかかる・バージョン管理のコストが増える
コードジェネレーター→正直論外・コードジェネレーター自体の管理コストが増える・生成元のコードの管理コストが増える・
              バグ発生時のデバッグ時間が爆増する・開発時に前処理が増える分のコストが増える

601 :デフォルトの名無しさん:2013/03/21(木) 00:24:41.35
>>593
>>596
目的を履き違えてんのはお前だろ
なんでライブラリー追加したり、コードジェネレーター
つかってまでJava使うんだよJavaを使うのが目的になってるじゃねぇか

602 :デフォルトの名無しさん:2013/03/21(木) 00:36:07.92
>>601
自分で言語選べない会社やプロジェクトもある
察してやれ

603 :デフォルトの名無しさん:2013/03/21(木) 02:10:24.93
そりゃJavaの方が実績のあるライブラリ等が揃っている分野はJava使うでしょ。
言語機能だけで使う言語は普通決めない。

604 :デフォルトの名無しさん:2013/03/21(木) 06:06:29.61
>>559
では静的型付けならば
単体テストさえ通ればプロダクションコードが確実に動作する
と言えるのかといえば、全然そんなことないよね。
でも単体テストで「多くのバグを」発見できるから、
静的型付けでも単体テストをやってる。

単体テストはコンパイル時型検査の完全な代替にはならないが、
「多くのバグを」発見できるというのは経験上正しい。

一方の「多くのバグを」が有効で、他方の「多くのバグを」が誇張だというのは
よほど定量的なデータで裏付けないと正当化できないと思うが?

605 :デフォルトの名無しさん:2013/03/21(木) 06:37:02.83
動的は静的へ変換できるだろ。
たとえば可能な型をすべて持っているクラスを用意してそれにスイッチ、フラグを付ける。
ユーザー定義の型は実行までに確認、取得しておく。

606 :デフォルトの名無しさん:2013/03/21(木) 06:44:47.69
動的型言語ではコンパイル時に何も検査していない
かのようなことを言うような粗すぎる論理の人が
はたして静的型システムを使いこなせるのだろうか?

607 :デフォルトの名無しさん:2013/03/21(木) 08:04:18.44
Javaと静的にも動的にも書けるGroovyの両方を使った開発を会社でやっているけれども、
Groovyで書くコードも公開メソッドは型付きで書くようにチームで徹底している。

理由は幾つかあるけれども、とりあえず引数や返り値の型については動的だろうが静的
だろうが結局ドキュメンテーションの際に明記することになるのであまり手間じゃない。
中身はそれぞれ静的に書いたり動的に書いたりしている。

単体テストの打率はそんなに変わらない感じ。テスト対象となるメソッド等々は個人個人で
見通しがきく大きさだし。ただ統合テスト時など他人の書いた部分を叩く際の凡ミスや仕様
変更の見落としは確実に少なくなる印象。同様にGroovyからJava側のAPIを呼び出す時も
基本的には型付きなど、要所要所の界面で型を利用して依存関係を追跡し易くする方針。

界面でいえば社内用にGroovyで書いていたREST APIを顧客向けにテスト公開する際には
Javaで全部書き直した。リソースクラスのメソッドについた引数の型やクラス定義などを
読んで入出力のJSONモデルも含めたREST APIのドキュメントやテスト用のWeb UIを自動
生成するツールがJava側には幾つかあったので。移行は手間だったけれども移行後はドキュ
メント管理などが格段に楽になった。

要所要所で使えば凄く便利だと思うけれどもね、型。
Python3.0の関数アノテーションみたいにAPIの部分に型情報をつけるのは御利益も大きいよ。

608 :デフォルトの名無しさん:2013/03/21(木) 09:11:44.31
>>607
>単体テストの打率はそんなに変わらない感じ。テスト対象となるメソッド等々は個人個人で
>見通しがきく大きさだし。

この辺りは自分の経験とも合致していて同意。

> ただ統合テスト時など他人の書いた部分を叩く際の凡ミスや仕様
>変更の見落としは確実に少なくなる印象。

モジュール単位での開発+結合テスト なスタイルだと、オレの経験でも同じ。

CI重視で各モジュール単位の開発中にも継続的に結合テスト相当も単体テストと一緒にやるスタイルだとどうだろう、という興味がある。
そういうスタイルは自分では動的型言語での経験しかない。
CI重視だと動的型言語でもモジュール間結合の問題も十分早期にバグを発見できる。
コード書きながらパラレルにxUnit動かすから、コードをsaveした数秒〜数十秒後には単純な型不整合は発見できる。
つまり、事実上コンパイルと同じ早さ。
静的型言語ではそれより効果が出るのか興味ある。

609 :デフォルトの名無しさん:2013/03/21(木) 09:56:21.73
>>608
結合テストの自動化って何使ってるの?

610 :デフォルトの名無しさん:2013/03/21(木) 10:02:19.57
>>608
> コードをsaveした数秒〜数十秒後には単純な型不整合は発見できる。

それだとどれくらいの間隔でsaveするかだな。
静的型付け言語だとIDEの機能ではあるが
コードを書いた直後に発見できる。

611 :デフォルトの名無しさん:2013/03/21(木) 10:09:13.64
>>604
私の身近で起こるバグは圧倒的にflagの1と0を逆に考えていた的なもので、
コンパイルテストで発見できたことなんてないけどな。

612 :デフォルトの名無しさん:2013/03/21(木) 10:14:19.67
>>610
Smalltalkの場合、数行のメソッド書く毎にsaveすることが多いから
事実上コードを書いた時点で発見できる。

613 :デフォルトの名無しさん:2013/03/21(木) 10:26:24.25
>>612
saveっていうかコンパイルな。Smalltalkのコンパイルは原則メソッド単位。
作業の流れの雰囲気はこんな感じ。http://vimeo.com/43740225

614 :デフォルトの名無しさん:2013/03/21(木) 10:33:16.12
>>611
そりゃそうだろw

コンパイルはテストじゃない。チェック。構文チェック。
構文上明らかにおかしいものを検出するもの

615 :デフォルトの名無しさん:2013/03/21(木) 10:35:26.72
>>612
またSmalltalkかw

なんか、動的型付け言語でも問題ないというよりか
Smalltaklなら問題ないって話に見えてきた。

今度からSmalltalkはちゃんと明記しないか?

616 :デフォルトの名無しさん:2013/03/21(木) 10:38:05.84
>>613
やっぱりSmalltalkだけ特別な世界だわw
君、Smalltalkでどんなの作ったことある?
一番大きいプロジェクトが聞きたいな

617 :デフォルトの名無しさん:2013/03/21(木) 10:44:20.37
>>608
そうありたいというか、今まさにテストのイテレーションの遅さが問題になっていて環境改善の
真っ最中なのでw
型付きで型付きのAPIを呼び出したときは確かに凡ミスは即座に解る。便利。でもそっちよりも
色々な単位でテストを素早く繰り返し行える環境の方が遙かに便利な感じで、静的云々はあまり
関係無いような気もする。

ただ呼び出しの不整合等々は各ブランチ内での開発中よりもむしろマージ段階で起こるケースが
厄介だと思う。マージ後の検証は大抵大きな単位でテストを走らせる必要があるので、その前に
静的に見つけられるものは見つけられた方が嬉しい。延々と走らせたテストが凡ミスでこけると
かなり切ないので。

あとは上にも書いたけれども界面を型付きで書くとファイルやプロジェクトをまたがった依存性
をかなりカッチリ把握できるので、何をするにしても影響範囲などを事前に把握しやすい分析面
での御利益は大きい。

蛇足ながらEclipseでGroovyを書くと静的に型を確定できない変数アクセスやメソッド呼び出し
は黒地のイタリックにアンダーラインという、見た目的にかなりイヤンなスタイルで表示される
ので、見た目の改善のため自ずと型を書いてしまうと言う副次的効果はある。個人的に。

618 :デフォルトの名無しさん:2013/03/21(木) 11:07:07.06
> 延々と走らせたテストが凡ミスでこけるとかなり切ないので。

まさにこれなんだよなぁ。
人間である以上ミスは避けられない。
そんなつまらないミスで時間とられることが
苦痛じゃないのかって思うわけだけど。

619 :デフォルトの名無しさん:2013/03/21(木) 11:10:49.77
だから苦痛じゃない人って
コードもプロジェクト全部で数千行程度
単体テストも数秒で終わるものしか
やってないんじゃないの?って思う

大規模だと単体テストでも全部やれば数分かかるんだよ。

620 :デフォルトの名無しさん:2013/03/21(木) 11:13:03.24
動的型の議論でSmalltalkだけ特別な世界だから議論から除外するなら、
静的型の議論で関数型は特別な世界だから議論から除外すれば?

あほらしw

621 :デフォルトの名無しさん:2013/03/21(木) 11:15:03.11
どうして単体テスト全部を動かすとかいうのかねー
改変部分に直接関与する分のケースを動かせばいいだけなのに
そしてそんなことは簡単にできるのに

あまりにも原始的すぎねーか?

622 :デフォルトの名無しさん:2013/03/21(木) 11:40:13.76
動的型付け言語で、改変部分に影響するところってどうやってわかるの?
影響するファイルというのは、修正したファイルだけじゃないよ。
動的だから実行しないと影響するかわからないじゃない。

静的型付け言語なら、リンクするための
情報などから静的にわかるけどさ。

623 :デフォルトの名無しさん:2013/03/21(木) 11:41:06.48
>>620
除外しないでいいからSmalltalkですって書いとけや。
書いとかなかったら聞くけどw

624 :デフォルトの名無しさん:2013/03/21(木) 12:14:13.04
>>622
メッセージセレクタ。

625 :デフォルトの名無しさん:2013/03/21(木) 12:17:50.11
>>624
またSmalltalkの話ってことでいい?

626 :デフォルトの名無しさん:2013/03/21(木) 12:20:02.38
Smalltalkなら標準機能だけで簡単だけど
Smalltalk以外でも簡単にフィルタ書けると思うけど?

ツールも一切合切用意されてないと何もできないタイプ?

627 :デフォルトの名無しさん:2013/03/21(木) 12:28:37.06
>>616
自分が関わったことのある比較的大きめのプロダクトだと
ざっと2000クラス、45000メソッドくらいだったかな。w

628 :デフォルトの名無しさん:2013/03/21(木) 12:40:28.00
自分が知らないものは除外したがる不勉強な奴がいて困る。

それに別にSmalltalkは動的型言語としては何も特殊なことは
やっていないんだがな。単にシステムとして、動的性をちょっと
追求しすぎちゃった感があるってだけで。

629 :デフォルトの名無しさん:2013/03/21(木) 13:20:29.95
> それに別にSmalltalkは動的型言語としては何も特殊なことは
> やっていないんだがな。

動画見ても十分やってるじゃん。

他の言語で、あんなエディタ使ってるか?
普通テキストエディタで書くんだよ。

630 :デフォルトの名無しさん:2013/03/21(木) 13:21:53.99
>>628
> 自分が知らないものは除外したがる不勉強な奴がいて困る。

全くだ。Smalltalk以外の
動的言語使ってる奴はどうした?
その話が全く出てないぞ。
知らないのかな?

631 :デフォルトの名無しさん:2013/03/21(木) 13:55:28.17
>>629
Smalltalkのチート感は半端ない

632 :デフォルトの名無しさん:2013/03/21(木) 13:57:46.99
> Smalltalkのコンパイルは原則メソッド単位。

それが特殊って気づかないのかな?

633 :デフォルトの名無しさん:2013/03/21(木) 15:49:08.09
Smalltalkが環境として特殊なのは第一にイメージベースなところだが
それは動的型であることと密接な関係にある。
Smalltalkのチートさは動的型のメリットのわかりやすい実例だな。

634 :デフォルトの名無しさん:2013/03/21(木) 16:11:37.83
だから他の動的型言語には、
適用できない技術なのかな。

635 :デフォルトの名無しさん:2013/03/21(木) 16:57:25.77
>>633
イメージってったって要はナンチャッテOODBだろ?
OODBに永続化されたデータで処理系を作って動かしたという点は
特殊かもしれないけれど、
それは動的型であることとはさほど関係ないように思うのだが

アラン・ケイだってもっと賢い型システムがあれば動的型にはこだわらない
って言っているわけだし。
http://d.hatena.ne.jp/nishiohirokazu/20100919/1284885238

636 :デフォルトの名無しさん:2013/03/21(木) 17:05:24.47
イメージベースで可能なことは、ファイルベースでも可能ではあるよ。
単にツールを充実させるモチベーションの問題だと思う。

ファイルベースだと、>>629が書くように、エディタ使えばいいという発想になる。
だからEclipseスゲーとか思って満足してしまう。

イメージベースだと、汎用エディタでプログラミングできるわけじゃない。
Smalltalkのブラウザはテキストエディタの拡張じゃなくて、クラスのUIなんだ。
だからより良い対話を実現するためにコードコンプリーションやリファクタリングブラウザが発明される。
ライブラリとのより良い対話を実現するためにSUnitが発明され、xUnitに発展する。

637 :デフォルトの名無しさん:2013/03/21(木) 17:11:06.33
>>635
そのOODBがGemStoneならばYES、ObjectStoreならばNOだな。
オブジェクトが永続化されていることが重要なんじゃない。
オブジェクトを動かすメタ情報や実行コンテキストがオブジェクトメモリ内で永続化されることが重要なんだ。

638 :デフォルトの名無しさん:2013/03/21(木) 17:27:21.39
ちと興味があるのできくのだけれども、SmalltalkでXML-Objectバインディングとか
JSONマッピングとの相互変換ってどうやるのだろう?

639 :デフォルトの名無しさん:2013/03/21(木) 17:28:22.50
>JSONマッピングとの相互変換ってどうやるのだろう?
なんだこりゃ。単にJSONマッピングね。

640 :デフォルトの名無しさん:2013/03/21(木) 17:45:52.14
>>638
ん? なんか特殊なことしないといかんの?

641 :デフォルトの名無しさん:2013/03/21(木) 17:53:21.36
いや、Jaxbとかだと最低限のアノテーションをつければあとは規約で型情報を読みとって
XMLへのシリアライザデシリアライザを自動生成するけど、その辺り動的型ではどういう
方法が一般的なんだろうかなと。

642 :デフォルトの名無しさん:2013/03/21(木) 18:03:38.07
テキストへのシリアライズ/デシリアライズなら
Smalltalkの場合シリアライズしたいオブジェクトにstoreOn:というメッセージを投げれば自分自身を構築するスクリプトを出力する。
デシリアライズはそれをevalすればいいだけ。

643 :デフォルトの名無しさん:2013/03/21(木) 18:06:13.06
>>642
いや、XMLとかJSONとか。他言語を相手としたやりとりに使うフォーマットの部分。

644 :デフォルトの名無しさん:2013/03/21(木) 18:51:08.30
>>643
動的言語で一般的なわけではないけれど、多くのSmalltalk処理系では
プラグマが使えるからそれ使うだけ。ただプラグマはメソッドにしか
付けられないからプロパティのマッピングとかに使うにはアクセッサを
介するとかちょっと工夫がいるけど。

http://www.cincomsmalltalk.com/present/XML2Object.pdf の14ページ

645 :デフォルトの名無しさん:2013/03/21(木) 19:45:52.52
これは・・・面倒です。全部名前付けしていくんだ・・・

646 :デフォルトの名無しさん:2013/03/21(木) 20:59:50.27
やっぱりSmalltalkだけ特別だな。

647 :デフォルトの名無しさん:2013/03/22(金) 00:46:13.82
>>644
最近はプラグマなんかいちいち書かんでもGUIで表の穴埋めするだけだけどな。

648 :デフォルトの名無しさん:2013/03/22(金) 00:47:50.26
GUIで表の穴埋めする
動的型付け言語って他に何かある?
つくづくSmalltalkに限った話ばかり続くね。

649 :デフォルトの名無しさん:2013/03/22(金) 00:54:53.45
JAXBだと頭に@XmlRootElementとアノテーションつけるだけで大体のたたき台は出来るよね。
後は規約を外れて細かく変更したいところをいじるだけ。

650 :デフォルトの名無しさん:2013/03/22(金) 02:23:48.26
はじめからXMLだとかJSONだとかいっているのにいきなりSmalltalk同士でしか使えないシリアライズの
話を持ち出す辺りにんともかんとも。

651 :デフォルトの名無しさん:2013/03/22(金) 03:24:46.27
ぶっちゃけマニアックな言語だと、簡潔に書けるって言われても
どれくらい簡潔なのかイメージが湧かないので、
次のXMLをデシリアライズして、
・x, y, zがdoubleとintとstringになってることを示して、
・次にdoubleとintは+1して、stringには'test'を足して、
最後にシリアライズするコード書いてみて欲しい。


<root xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<x xsi:type="xsd:double">1</x>
<y xsi:type="xsd:int">1</y>
<z xsi:type="xsd:string">1</z>
</root>

652 :デフォルトの名無しさん:2013/03/22(金) 04:00:46.00
マッピングの話なのに・・・

653 :デフォルトの名無しさん:2013/03/22(金) 05:24:55.30
マッピングの方法を知りたいんじゃなくて
動的型を叩くネタを知りたいだけだからじゃね?

654 :デフォルトの名無しさん:2013/03/22(金) 06:33:02.16
静的型(ていうかJava)のほうが圧倒的に冗長になりそうな例だが...

655 :デフォルトの名無しさん:2013/03/22(金) 07:37:02.60
言われてみればDOMを使って手続き的にXMLを読んだりシコシコ手作りする機会がめっきり減ったな。
大抵は宣言的なXMLバインディング。SAXの方がまだ特殊用途で出番があるぐらい。

656 :デフォルトの名無しさん:2013/03/22(金) 20:25:31.67
つーかXMLなんて喜んで使ってるアホはJavaドカタだけだろ
XML地獄で多少は懲りたみたいだが

657 :デフォルトの名無しさん:2013/03/22(金) 23:26:50.20
Java使いはXML地獄が嫌なのでアノテーション地獄に移行したよ

658 :デフォルトの名無しさん:2013/03/22(金) 23:35:23.66
ジェイソン地獄大好きw

659 :デフォルトの名無しさん:2013/03/23(土) 04:33:05.96
動的型付け言語は静的型付け言語でコンパイル時に自動的に行われる
型チェックの代わりに分岐網羅率100%のテストコードを書かなきゃ
いけないんでしょ。それってめんどくさくない?

660 :デフォルトの名無しさん:2013/03/23(土) 05:09:35.40
LLはYAML地獄からJSON地獄へ移行済み。

661 :デフォルトの名無しさん:2013/03/23(土) 06:02:16.84
>>659
へー、なんでC0ではなくC1なんだい?

662 :659:2013/03/23(土) 06:05:50.45
>>661
じゃあ逆に聞くけどなんでC0じゃなくてC1なわけ?おん?

663 :デフォルトの名無しさん:2013/03/23(土) 06:06:44.88
>>661
同じコードでも入っているオブジェクトによって
成功する場合と失敗する場合があるから

664 :デフォルトの名無しさん:2013/03/23(土) 06:08:06.20
>>662
C1が必要だと言ったのはオマエじゃないかw

665 :デフォルトの名無しさん:2013/03/23(土) 06:08:15.53
どんなオブジェクトが入るかってのは
結合時の話になるから、単体テストでは
テストできず、結合テストが必要になるんだよね。

666 :デフォルトの名無しさん:2013/03/23(土) 06:10:53.72
>>663
へー、じゃあC1では全く不十分だねえ。
C4が必要だねえ。

どうしてC1で十分だと思ったんだろうねえw

667 :デフォルトの名無しさん:2013/03/23(土) 06:14:13.51
>>666
C1って言い出したのはお前じゃないのか?

じゃあ ”お前の指摘通り正しく” 言い直すよ。

動的型付け言語は静的型付け言語でコンパイル時に自動的に行われる
型チェックの代わりに分岐網羅率100%のテストコードを書かなきゃ
いけないんでしょ。

つまり、C4が必要。

それってめんどくさくない?

668 :デフォルトの名無しさん:2013/03/23(土) 06:18:55.23
>>667
C1と言い出したのは>>659だろ?

669 :659:2013/03/23(土) 06:21:36.61
>>666
C4なんてないだろ。プラスチック爆薬のことか?爆発しろと言ってるのか?
お前は俺に爆発しろといってるのか?おん?
俺はお前がうらやむようなリア充であることを否定しないけどな。
あえて否定しないけどな。

>>668
俺だわ。完全に俺が言い出してたわ。反省はしないし間違ってるとも思ってない。

670 :デフォルトの名無しさん:2013/03/23(土) 06:22:13.57
>>667
はっきり言うと、あんた、網羅率の分類すらわかってないわけよ。
C1=分岐網羅率
C4=経路網羅率
出直してこい

671 :デフォルトの名無しさん:2013/03/23(土) 06:23:39.53
>>670
誰かと間違ってるだろw

まあいい、出直してきたよ。
今、出直してきたよ

672 :デフォルトの名無しさん:2013/03/23(土) 06:26:05.56
>>669
C1が100%でも引数として渡されるオブジェクトの種類を網羅できないだろ。
少なくともC4でないと。

で、C4が相手となると、動的型では100%達成どころか、計測することすら困難なわけだ。
結論としては、動的型では型安全をテストで「検証」することはできない。

673 :デフォルトの名無しさん:2013/03/23(土) 06:26:56.49
例えばこんなミスがあるから
動的型付け言語では、C1テストが必要になる。

var obj; // 本来はAと互換性があるものしか入れてはいけない。
if(cond) {
 obj = new A();
} else {
 obj = new B();
}

//AとBに互換性はない。

foo(obj); //fooの引数はAと互換性があるものしか想定していない。

674 :デフォルトの名無しさん:2013/03/23(土) 06:51:13.63
なんだか私とは別世界の人だらけらしいが、皆さんテスト屋さん?

675 :デフォルトの名無しさん:2013/03/23(土) 07:04:14.39
>>673
それはC0で検出可能だアホw

676 :659:2013/03/23(土) 07:17:01.76
wikipedia読んで勉強してきた。俺間違ってた。
if (condition1 || condition2) {
}
C1だとこういうとき条件式を全部チェックできないんだって。
それをやるのがC2。だから最低でもC2 100%にしなきゃいけない。

677 :659:2013/03/23(土) 07:39:06.44
違う、そうじゃない。
タイプミスをチェックするだけなら組み合わせなんてどうだっていい。C0だ。
C0でいい。

678 :デフォルトの名無しさん:2013/03/23(土) 08:15:58.54
静的型ではコンパイルエラーになってしまうコードも
動的型では正しいコードでありうる(ゆえに表現能力が高い)ということが
分からないかぎり、議論は永遠に平行線だな

679 :デフォルトの名無しさん:2013/03/23(土) 08:41:35.91
>>678
議論の主題は開発の生産性。表現力が高いことがわかっても
そのことが開発の生産性とどう関連するのかわからなかったら
意味がないと思うのよ。表現能力が高いことってどういうこと?
表現能力が高いことは開発の生産性が高いことにつながるの?

680 :デフォルトの名無しさん:2013/03/23(土) 08:44:21.13
Javaエバンジェリストの人は、
コード行数や必要なクラス数が減ると
開発生産性が向上するって力説してたよ

ttp://www.flickr.com/photos/33583790@N00/7465233960/

681 :デフォルトの名無しさん:2013/03/23(土) 08:54:09.71
>>679
表現力が低いと、顧客やQA屋からのフィードバックを反映させる時に
設計レベルから修正しなければならない可能性が増加するんだよ。
表現力が高いということは、そんな時に実装レベルでやりくりが出来るということだよ。

設計レベルでの修正を繰り返すのと、実装レベルのやりくりを繰り返すのと、
最終的にどちらがよいかは、案件の特性による。

682 :デフォルトの名無しさん:2013/03/23(土) 08:59:53.08
表現力の違いと影響範囲の違いの関連がよく解らない。

683 :デフォルトの名無しさん:2013/03/23(土) 09:03:22.35
Pythonの邪悪な非同期IOライブラリgeventは
標準のsocket, ssl, threading, selectなどにモンキーパッチを当てる事で
多くのブロックするシステムコールを協調的に動作するように変更できる。

http://methane.github.com/gevent-tutorial-ja/

> 例えば、 Redis の Python バインディングは通常の TCP ソケットを使って
> redis-server インスタンスと通信します。 gevent.monkey.patch_all() を実行するだけで、
> redis バインディングは 協調的にリクエストをするようになり、
> その他の gevent のスタックと一緒に 動くようになります。

> モンキーパッチを使えば、そのままでは gevent で動作しないライブラリを
> 1行のコードを書くだけで統合できるようになります。 モンキーパッチは邪悪ですが、この場合は必要悪です。

684 :デフォルトの名無しさん:2013/03/23(土) 15:09:50.46
>>680
そりゃ同じ言語での場合の話だ。

特に静的型付け言語と動的型付け言語では
コードに含まれる情報量が違うので
一概に比較はできん

685 :デフォルトの名無しさん:2013/03/23(土) 15:13:00.28
>>683
いや、それ邪悪じゃんw
標準ライブラリの内部コードが変更されたらどうする。

ラップしたライブラリを作って作るか、
標準機能にパッチを取り込ませるのが
正しい対応方法だよ。

686 :デフォルトの名無しさん:2013/03/23(土) 19:00:49.36
モンキーパッチも選択肢の1つだということが理解できない静的脳

687 :デフォルトの名無しさん:2013/03/23(土) 20:00:10.51
ドカタには存在しない選択肢だから仕方ないね

688 :デフォルトの名無しさん:2013/03/23(土) 20:12:09.43
マトモなプログラマの潜在開発生産性はドカタの100倍

689 :デフォルトの名無しさん:2013/03/23(土) 20:43:46.94
現実的にはJava土方の1000人月=まともなプログラマの50-100人月くらいだけどな。

690 :デフォルトの名無しさん:2013/03/23(土) 21:36:33.84
流石に基本クラスを書き換えるようなことはしないけど、ユーザクラスに対して
実行時にホットパッチを当てるのはJavaでも全然珍しくないし、その場合も大抵
はClassLoaderを分けて影響範囲を制限するけれどもね。

691 :デフォルトの名無しさん:2013/03/23(土) 22:46:17.26
>>690
> 流石に基本クラスを書き換えるようなことはしないけど

書き換えることまでは出来ないけど、ではなく?

692 :デフォルトの名無しさん:2013/03/23(土) 23:10:28.32
>>691
書き換え出来るよ。java.lang.Stringにパッチをあてるとか。

ただ基本クラスはルートのクラスローダーで読まれるので扱いは静的で、他のユーザー
クラスのように実行コンテキスト毎に異なるクラス実装を使用したりも出来ない。
あとライセンスの関係で配布が出来ない。

693 :デフォルトの名無しさん:2013/03/24(日) 07:15:09.45
ウンコレベルに冗長だけど、可能ではあるね

694 :デフォルトの名無しさん:2013/03/24(日) 07:24:22.42
冗長ではない。
LOC的に生産性が高いのだ!

695 :デフォルトの名無しさん:2013/03/24(日) 07:57:19.43
> 実行時にホットパッチを当てるのはJavaでも全然珍しくないし、

うんうん、全然珍しく無いよね。
だからそういうコードが「より簡潔に」書ける言語が良いってわけだ。

696 :デフォルトの名無しさん:2013/03/24(日) 08:34:05.10
いや、普通やらないだろ。
そんなことすると互換性の問題が発生する。

となるとやっぱり不要ってなるわけだが?

697 :デフォルトの名無しさん:2013/03/24(日) 08:37:37.69
>>696
ベースライブラリへのモンキーパッチでどう互換性の問題が発生するんだい?
具体的に言ってごらん?

698 :デフォルトの名無しさん:2013/03/24(日) 08:47:03.50
基本クラスにモンキーパッチ当てないと使えないようなものは他の物と組み合わせてつかい
にくいと思うのだけど。他のコンポーネントへの副作用とか出てくるでしょ。

prototype.jsがまさに基本クラス拡張型だったな。その教訓を受けてかjQueryはラッパー型で、
DOMのエレメントやそのprototypeをいじって拡張することは殆どない。

699 :デフォルトの名無しさん:2013/03/24(日) 08:48:16.69
全然具体的じゃなくてワロタwww

700 :デフォルトの名無しさん:2013/03/24(日) 09:03:04.09
>>697
>Python のランタイムは、モジュール、クラス、そして関数に至るまで、 ほとんどのオブジェクトに
>ついて実行時に編集することを許しています。 これは一般的にはとーっても悪いやり方です。
>「暗黙の副作用」を作り出し、 問題が発生した時にデバッグするのを非常に難しくするからです。

701 :デフォルトの名無しさん:2013/03/24(日) 09:04:38.90
>>700
>>699

702 :デフォルトの名無しさん:2013/03/24(日) 10:47:19.21
>>697
> ベースライブラリへのモンキーパッチでどう互換性の問題が発生するんだい?

ベースライブラリはモンキーパッチを当てると、
ベースライブラリの挙動が変わる。

その結果、他のライブラリの挙動が変わる。
また、ベースライブラリ自体がバージョンアップした時、
そのような結果が起きるか想像できない。
いいことは何も起こらない。

703 :デフォルトの名無しさん:2013/03/24(日) 10:49:51.01
Prototype.jsが廃れていった原因の一つも
ベースライブラリへのモンキーパッチ。

そのせいでPrototype.js以外のライブラリが
正しく動かなくなるなどの問題が起きた。
Prototype.jsを組み込んで大丈夫か検証する必要があった。

704 :デフォルトの名無しさん:2013/03/24(日) 11:07:06.42
prototype.jsよりJqueryの方が書き易くて人気があって、
両方ともグローバル変数$を使ってたため共存が少し面倒だった
だからprototype.jsが廃れただけ

705 :デフォルトの名無しさん:2013/03/24(日) 11:11:34.83
ベースライブラリを書き換えなかったから、
jQueryの方が書きやすくなった。

706 :デフォルトの名無しさん:2013/03/24(日) 11:15:08.48
へーwww
じゃあソース書いて比較してみ?
「ここはベースクラスを書き換えてないから、こういう書きやすい書き方になった」って説明付きで

まあ、どうせできないだろうが

707 :デフォルトの名無しさん:2013/03/24(日) 11:24:30.07
一応、Prototype.jsの開発者もダメだったことは認めてて、

http://perfectionkills.com/whats-wrong-with-extending-the-dom/


要約すると
・決まった仕様が無く、DOM extensionに全てのブラウザが対応してるとは限らない(特にモバイル)
・IE 6,7やsafari 2.x などには特別の実装を用意して回避できるが、パフォーマンスが悪い
・ブラウザにバグがあり、思ったように動かないケースがある


Javascriptは古いブラウザも含む様々な処理系で動かす必要があるから、事情が特殊だよ
他の言語処理系と同じようには議論できない

708 :デフォルトの名無しさん:2013/03/24(日) 11:40:41.69
>>702
> その結果、他のライブラリの挙動が変わる。

まさに、それを目的としてパッチをあてるんだが

> また、ベースライブラリ自体がバージョンアップした時、
> そのような結果が起きるか想像できない。

パッチを当てなくても同じじゃん

709 :デフォルトの名無しさん:2013/03/24(日) 11:53:45.29
>>706
Prototype JavaScriptライブラリの歴史を紐解いてみましょう。
PrototypeはあらゆるJavaScriptオブジェクトを変更する機能で有名でした。

バージョン1.6以前のPrototypeにはdocument.getElementsByClassName()と
いうメソッドが実装されていました。

Prototypeのdocument.getElementsByClassName()メソッドは、指定されたCSS
クラスを含む要素の配列を返しました。Prototypeでは配列にもメソッドが追加されていて
Array.Prototype.each()は配列に順にイテレートし、各項目に対して関数を実行しました。
この機能によって開発者は次のようなコードを書くようになりました。

 document.getElementsByClassName("selected").each(doSomething);

HTML5でこのメソッドが標準化され、これをブラウザがネイティブで実装するようになるまで
このコードが問題になることはありませんでした。

HTML5のdocument.getElementsByClassName()は配列を返さなかったで、each()メソッドは
存在しませんでした。

document.getElementsByClassName()は他のDOMメソッドと合わせるためにNodeListを返しました。

NodeListにはeach()メソッドがないので、document.getElementsByClassName()メソッドが
ネイティブで実装されているブラウザで実装すると、ネイティブでもPrototypeで追加された場合でも、
each()を使うとJavaScriptのエラーが発生しました。その結果としてPrototypeのユーザーは
ライブラリコードと自分のコードの両方をアップグレードしなければならず、メンテナンスが
悪夢になりました。

Prototpypeの失敗から学びましょう。JavaScriptが将来どのように変化するのか、正確な予測はできません。

『メンテナブルJavaScript』 P111 「11章 所有していないオブジェクトを変更しない」より
一部抜粋

710 :デフォルトの名無しさん:2013/03/24(日) 11:57:15.08
RubyですらRails等サードパーティライブラリの互換性を壊さないように
気を使って機能追加してるのに、Javascriptは本当に終わってるなw

711 :デフォルトの名無しさん:2013/03/24(日) 11:58:26.09
終わってるのは、モンキーパッチだろw

712 :デフォルトの名無しさん:2013/03/24(日) 12:10:36.08
Java土方とかJavascript土方ってモンキーパッチも使いこなせないのか……
所詮はドカタか……

713 :デフォルトの名無しさん:2013/03/24(日) 12:22:43.88
バカは限度を知らないからな

714 :デフォルトの名無しさん:2013/03/24(日) 12:24:06.69
> PrototypeはあらゆるJavaScriptオブジェクトを変更する機能で有名でした。

強力な機能だからこそ、ここぞという所で使うんだよ。

でも馬鹿には0と1しか無いんだよね。
使うか使わないかの二択より難しいことは考えられない。

715 :デフォルトの名無しさん:2013/03/24(日) 12:42:22.07
で、どういうときにモンキーパッチ使うんだい?
それによる影響がないと確認するにはどうするんだい?
予知能力が必要になるな。

716 :デフォルトの名無しさん:2013/03/24(日) 12:51:56.40
もう上のほうで利用例が出てたと思うけど、
ドカタには縁がないから、君はそのままで良いよ
底辺は底辺らしくしてれば良いよ

717 :デフォルトの名無しさん:2013/03/24(日) 13:32:59.59
利用例が無理やりすぎ。

モンキーパッチを使わないで
正攻法を使ったほうがいい。

モンキーパッチは不具合の元。

718 :デフォルトの名無しさん:2013/03/24(日) 13:35:13.06
モンキーパッチはいざという時に取れる選択肢の一つだが
誰でも彼でも土方でもやっていいものではない。

719 :デフォルトの名無しさん:2013/03/24(日) 14:45:53.59
>>717
sockscap

720 :デフォルトの名無しさん:2013/03/25(月) 03:41:21.73
確かに、他に方法がなくてどうしようもない時だけだな。

721 :デフォルトの名無しさん:2013/03/25(月) 07:46:42.74
このスレって延々と論争してるけど、
結局のところ想定してるプログラマ像が違いすぎるのが原因だから

「ドカタに使わせるにはどんな言語が良いか」

というテーマなら速やかに合意に達すると思う

722 :デフォルトの名無しさん:2013/03/25(月) 11:54:45.40
Java一択、で話が終わってしまうんだが?

723 :デフォルトの名無しさん:2013/03/25(月) 12:02:27.87
COBOL もあるぜ

まあ、Javaは21世紀のCOBOLだけどな

724 :デフォルトの名無しさん:2013/03/25(月) 20:17:05.82
VBのことも忘れないで!

725 :桃白白:2013/03/25(月) 20:38:31.83
>>709
なるほどー。JavaScriptはとくに絶賛成長中の言語だからな。
短期的にはよい結果をもたらすけれども、それが裏目にでることになるわけね。
なるほどー。

726 :デフォルトの名無しさん:2013/03/25(月) 20:44:26.06
>>721
なんでいつも職業プログラマを
目の敵にしてるの?

727 :デフォルトの名無しさん:2013/03/25(月) 20:55:24.73
Javaに +1

728 :デフォルトの名無しさん:2013/03/25(月) 21:35:57.38
ドカタならJava+eclipse+checkstyleでガチガチにするしかないな

729 :デフォルトの名無しさん:2013/03/26(火) 06:06:42.72
>>725
概してモンチーパッチの類を使うと将来の変化に弱くなる。

パッチを当てる相手(prototype.jsの場合はJavaScript)の変化に応じてパッチも更新する
必要があるし、パッチを当てた上に構築した成果物を将来拡張する場合も新たに導入する
ライブラリ等がパッチを当てた環境上でも動くか検証する手間が出てくる。

730 :デフォルトの名無しさん:2013/03/26(火) 06:08:07.12
そうそう、だからパッチを当てるのが不可能か、
難しい言語を使うのが望ましい
Javaとか


そう、ドカタはね

731 :デフォルトの名無しさん:2013/03/26(火) 06:43:13.21
局所的なスコープでだけパッチが有効になる仕組みについては
色々アプローチはあるんだけど、
どれもドカタには使いこなせないからなぁ……

732 :デフォルトの名無しさん:2013/03/26(火) 09:10:30.48
>>730
ヒント ドカタって言う奴がドカタ

733 :デフォルトの名無しさん:2013/03/27(水) 21:47:26.36
ところで動的言語が遅いというのは都市伝説、性的言語より速くなりうると言ってた人たちって
型情報与えたらいきなり数倍速になったasm.jsをどう思ってるん

734 :デフォルトの名無しさん:2013/03/27(水) 21:48:17.16
だいたいこの1年くらいJavaScriptの速度の伸び完全に止まってるし
やれること全部やっちまったみたいな

735 :デフォルトの名無しさん:2013/03/27(水) 23:43:31.51
>>733
asm.jsってJavaScriptのサブセットだよ。

JavaScriptから動的型付け言語の性質を抜き去った
命令だけを使うことで速くできる。

asm.jsで書くと動的型付け言語のメリットがないのだから
やっぱり静的型付け言語の方が速いねという結論にしかならないよ。

736 :デフォルトの名無しさん:2013/03/28(木) 00:37:06.50
静的のほうが速いのはまず間違いない。ここは議論の余地なし。
静的の問題は開発環境が重く開発効率も非常に悪いこと。

737 :デフォルトの名無しさん:2013/03/28(木) 02:06:42.50
開発環境が重いと言ったって雀の涙程度の違いだし、
その重さ=開発サポートのおかげで快適に開発できるし、
開発効率が悪いと思ってるのは
お前がテキストエディタで書こうとしてるからだ。

738 :デフォルトの名無しさん:2013/03/28(木) 02:17:44.79
テキストエディタで書けないから重いんだよ
むしろテキストエディタで書きたいぐらいだが
ビルドとか考えたら現実的じゃないしな

739 :デフォルトの名無しさん:2013/03/28(木) 02:20:03.83
なぜテキストエディタで書くのかわからない。
優秀な道具を使えよ。

740 :デフォルトの名無しさん:2013/03/28(木) 07:09:19.08
vimは超優秀

741 :デフォルトの名無しさん:2013/03/28(木) 07:11:24.97
静的言語はIDE使った方が便利なのはそうだけどビルドはあまり関係無いような気がするなぁ。
大きなプロジェクトほど依存性管理やビルドはIDE非依存でできるようにすると思うけど。
でないとCIとかやりにくい。

742 :デフォルトの名無しさん:2013/03/28(木) 07:13:48.10
JavaはEclipseでないとコンパイル出来ないドカタが山程居る
誇張じゃなく

743 :デフォルトの名無しさん:2013/03/28(木) 07:23:46.51
まあMavenだな。IDE使わずともビルドやテストはコマンド一発なのでテキストエディタ使用の
ドカタでも全然大丈夫。

ドカタがMavenプロジェクトを作れるかはまた別問題w MakeやAntよりは遙かに簡単だけど。

744 :デフォルトの名無しさん:2013/03/28(木) 09:22:55.67
コード少し直しただけでantだのmavenだの面倒くさすぎる
だから開発効率が悪い

745 :デフォルトの名無しさん:2013/03/28(木) 21:28:39.07
>>742
Javaは人間じゃないです。

なんで人間の問題なのに
Javaって言語の問題かのように言い方をするの?

746 :デフォルトの名無しさん:2013/03/28(木) 21:29:57.07
>>744
あんたantやmavenわかってないんじゃない?

あれはシステムrailsみたいに用意して少し設定すれば
勝手に裏でやってくれるもの

コード少し直した程度じゃ、何も触るところはない。

747 :デフォルトの名無しさん:2013/03/29(金) 14:36:11.49
面倒なのは間違いない。普段からJavaやってない人には初っ端からやる気を削ぐ。

748 :デフォルトの名無しさん:2013/03/29(金) 14:52:59.38
>>746
たとえ自動でもビルドとホットデプロイがかかるだろ
あれが面倒なんだよ
PHPやRubyならサクサク作れる

749 :デフォルトの名無しさん:2013/03/29(金) 14:58:27.68
>>748
おかげでRubyバグだらけじゃん

750 :デフォルトの名無しさん:2013/03/29(金) 20:02:14.80
RubyもRubyで互換性すぐ消えるし、互換性消えまくるから、バージョン違いのRubyを大量に管理する必要があって、
その為に管理ツールとかあるんだけど、その管理ツールすら互換性消えまくって、RVMはオワコンでこれからはrbenvの時代だなんだと際限なく学習を強いられる。

751 :デフォルトの名無しさん:2013/03/29(金) 22:29:45.65
互換性と型付けが関係あるとでも?

752 :デフォルトの名無しさん:2013/03/29(金) 22:32:31.95
そういや型付けがない言語のほうが
互換性低い気がする。
なんでだろう?

753 :デフォルトの名無しさん:2013/03/29(金) 23:09:27.01
D言語とSmalltalkを知ってると、とてもそうは思えないが……

754 :デフォルトの名無しさん:2013/03/29(金) 23:41:29.24
D言語とSmalltalkは単に使われてないだけかと。

755 :デフォルトの名無しさん:2013/03/30(土) 00:33:14.96
JavaもJarのバージョンの衝突は毎度悩まされるところだけど。

756 :デフォルトの名無しさん:2013/03/30(土) 07:11:13.96
pythonで後方互換性なくなったのは3kぐらいなものだと思うけど?

757 :デフォルトの名無しさん:2013/04/14(日) 20:43:46.28
iPhoneアプリ. Windowsアプリを売って生き残れ Ver 1.7 リンク数61
Http://qr. net/kh4y

758 :デフォルトの名無しさん:2013/04/24(水) 14:48:37.98
型システムのスレが無くてこんなスレしか無いとか2ch終わりやね

759 :デフォルトの名無しさん:2013/04/24(水) 15:15:34.42
>>758
先進なんだろう。

760 :デフォルトの名無しさん:2013/05/20(月) 23:01:31.12
>>754
Dはそこらのスクリプト以上に互換性が酷いからな…

761 :デフォルトの名無しさん:2013/05/23(木) 15:55:33.74
Dは動的バージョン付け言語だからな

762 :デフォルトの名無しさん:2013/05/25(土) 17:42:44.93
「主流」としか言えないことが悲しいな
なんで全てにおいて高性能なのに全てで使われないんだろうな
使い分けができないゴミには一生わからない問題だろうなあ

763 :デフォルトの名無しさん:2013/05/25(土) 19:01:00.20
主流?

764 :デフォルトの名無しさん:2013/07/07(日) NY:AN:NY.AN
生産性は動的言語

保守性が静的言語

765 :デフォルトの名無しさん:2013/07/07(日) NY:AN:NY.AN
>>764
今時のツールやフレームワーク、特にテスト関係や静的解析、IDEの補完機能や
他の色々な便利機能を考えると動的言語の方が生産性高いとは言えない。
一人で数十行程度の本来のスクリプトの用途で考えるならまだ動的言語の方が
高いかもしれないけどね。

766 :デフォルトの名無しさん:2013/07/07(日) NY:AN:NY.AN
人にとっての使用感は圧倒的に動的言語
最終的には動的言語で静的言語のようなサポートができるようになるし
今もその方向で爆進している。静的言語が良いというのは機械の都合でしかない

767 :デフォルトの名無しさん:2013/07/07(日) NY:AN:NY.AN
ついでに人間が書かなくても機械が勝手にプログラミングしてくれるようになるしな

768 :デフォルトの名無しさん:2013/07/07(日) NY:AN:NY.AN
そこまでは無理だけど、もうJavaやC#のようなゴミ言語では
到底たどり着けないレベルまで動的言語の生産性は高まってる

769 :デフォルトの名無しさん:2013/07/07(日) NY:AN:NY.AN
話の内容が全然具体的でないな。

まあ、いつものことだが (w

770 :デフォルトの名無しさん:2013/07/07(日) NY:AN:NY.AN
まあ、コードの生産性だけなら動的が勝ってるわな
つーか、そこに特化したのが動的だし、それしか勝ってないんだけど

771 :デフォルトの名無しさん:2013/07/07(日) NY:AN:NY.AN
ひとつの言語しか使えない低能を除くと、
適材適所で使い分けるのが最強という結論になる

772 :デフォルトの名無しさん:2013/07/07(日) NY:AN:NY.AN
だな

773 :デフォルトの名無しさん:2013/07/07(日) NY:AN:NY.AN
無理して一つの言語に固執せんでもってこったな

複雑な処理が必要だが今すぐぱっと答えが欲しい時、
あまりにも変化が激しすぎて開発速度が何よりも重要な時、
動的型付け言語の使い処はこんなところだよね

774 :デフォルトの名無しさん:2013/07/11(木) NY:AN:NY.AN
設計どおりに作って一切のエラー発生させないのを理想とするウォーターフォールモデルで頭が固まった人にはわからないだろうが。
静的型付け言語はエラーをわざと発生させてそこを直していくという作業で
プログラムを構築することができる。慣れるとそれが結構効率的だったりする。
エラーとか例外とかいうからいけないんだな。そうじゃなくて開発手法として整理すべきと思う。

775 :デフォルトの名無しさん:2013/07/11(木) NY:AN:NY.AN
>>774
言いたい事はわかるし、真意を汲めばこそ突っ込みたくは無いのだが…

「わざとエラーにする」ってのは日本語がおかしいぞ

776 :デフォルトの名無しさん:2013/07/11(木) NY:AN:NY.AN
「わざとエラーにする」って誰が言ったの?

777 :デフォルトの名無しさん:2013/07/11(木) NY:AN:NY.AN
わかりずらくてすまないな。主にコンパイルエラー。
実行時エラー(例外)を発生させるのは追いかけるのが大変だが一応ある。

778 :デフォルトの名無しさん:2013/07/11(木) NY:AN:NY.AN
>>776
「エラーをわざと発生させる」って>>774が。
あの文脈だと「わざとエラーにする」と読める。

もちろん真意は、
間違えて組んだら、コンパイルエラーとなるように、意図的に仕込んでおく、
という事だと思うんだけどね。

779 :デフォルトの名無しさん:2013/07/20(土) NY:AN:NY.AN
上流企業と底辺企業と一般人で、
カースト作りたいから変なもんを推す
PHP、JAVAとかマジでそれ
中には本気でそのゴミ使いやすいとかいっちゃうやついるから困る
企業戦略にハマりすぎてて見てて泣ける

780 :デフォルトの名無しさん:2013/07/20(土) NY:AN:NY.AN
ほらわかりやすい釣りですよ。

781 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
そういうことにしとけ
気づいてしまうと
今まで自分の足元にあった巨大なものと戦わなきゃなる

782 :デフォルトの名無しさん:2013/07/22(月) NY:AN:NY.AN
わかるー

783 :デフォルトの名無しさん:2013/07/22(月) NY:AN:NY.AN
まさかMS

784 :デフォルトの名無しさん:2013/08/05(月) NY:AN:NY.AN
動的型付けだとデータが違っててたまたまうまく動作したのか、
データが正しくてうまく動作したのかわからないと思うの。
だから静的型付け言語の方が手戻りがすくなくてとっても生産性が高いと思うの。

785 :デフォルトの名無しさん:2013/08/05(月) NY:AN:NY.AN
むしろ、その「たまたま上手く動いちゃう」を
最大限に使ってくのが動的型かと思う、だから設計も結構違うかと
静的なら最低限のものを用意して組み合わせさせたり
必要になったら、別の手段で出来ないか確認してから書くけど
動的型なら、テキトーに書いてもある程度動くように
どっさりと色んなアプローチを用意する形で書いてるわ
たまたま動いちゃうなら、そこはたまたまが正常に動いちゃうように書く感じ
(正常に見える、ではなく正常に動く、ね)

反対側と同じように書こうとすると上手くいかないと思うし
生産性も上がらないと思う

786 :デフォルトの名無しさん:2013/08/05(月) NY:AN:NY.AN
機動性に優れているのが一番

一戸建て住宅   = 静的型付け
キャンピングカー = 動的型付け

787 :デフォルトの名無しさん:2013/08/05(月) NY:AN:NY.AN
>>785
正常に見えると正常に動くは相互に排他的である、ということではないのじゃないかな?
どうやって判断するの?

788 :デフォルトの名無しさん:2013/08/05(月) NY:AN:NY.AN
テストを実行して引数が間違ってたけどたまたまパスしました。
正常に見えます。正常に動くことと区別することできないっすよね。

789 :デフォルトの名無しさん:2013/08/05(月) NY:AN:NY.AN
なんだよ、たまたま動くとかテストに漏れがあるとか
静的、動的関係ないじゃんか。

静的が凄いのは、その名の通り静的であるということ。
コードが定義でできてる。

コードを動かすことなく決まるから、
実行させなくても、いろんな解析ができるということ。
実行時間0(解析時間だけ)で情報が得られる。

実行させればわかるというが、実行させるには時間がかかる。
実行しなければ状態が確定しないということは、
変数によって状態がいろいろ変わることがあるということ。

規模が大きくなればなるほど、いろんな状態によって
答えが変わる動的言語は、解析とテストが大変になる。

790 :デフォルトの名無しさん:2013/08/05(月) NY:AN:NY.AN
>>789
静的型付けと動的型付けの比較をしてるんだから、
型付けによって改善できることを話してるんだって
読み取って欲しかったです。

791 :デフォルトの名無しさん:2013/08/06(火) NY:AN:NY.AN
まあ、適材適所だね

792 :デフォルトの名無しさん:2013/08/06(火) NY:AN:NY.AN
オレの感覚的には、20%の労力で80%の成果を得るのが動的
対して静的は80%の苦労で95%を得るものだな
勿論、どちらが絶対的に優れているというモノでは無いよね

793 :デフォルトの名無しさん:2013/08/06(火) NY:AN:NY.AN
静的+自動型解析や動的+アノテーション辺りが一番良いと思ってる。

794 :デフォルトの名無しさん:2013/08/06(火) NY:AN:NY.AN
>>792
その計算には、プロジェクトの規模が含まれてないだろ?

小さいものを作るときはいいかもしれんが、
数人以上で数ヶ月、ファイル・クラス数十個なんて
ものを作るとき、保守性が悪いのが動的言語だよ。

795 :デフォルトの名無しさん:2013/08/06(火) NY:AN:NY.AN
>>794
そんな当たり前のことをレスされても

796 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
>>795
それが当たり前なら対価の割合なんて一概に言えないじゃないか

797 :デフォルトの名無しさん:2013/08/23(金) NY:AN:NY.AN
効率を犠牲にしてわすかな完成度向上を絞りださざるを得ない
それが大規模プロジェクトの宿命
つまり >>791-792 でFA

798 :デフォルトの名無しさん:2013/08/23(金) NY:AN:NY.AN
大規模プロジェクトと呼ばれるものの大半は
ゴミを集めて人数が膨れ上がったプロジェクトを意味する

ゴミだから動的な特性なんて使いこなせないし、テストも書かないので
静的型チェックによる僅かな品質向上に望みをかけるしか無い

799 :デフォルトの名無しさん:2013/08/23(金) NY:AN:NY.AN
>>798
ワロタ
真実かもなw

800 :デフォルトの名無しさん:2013/08/25(日) NY:AN:NY.AN
例えばJavaにはローカル変数は初期化しなくても良いが
初期化せずに参照するとコンパイルエラーで弾かれる特徴がある
この機能を活用することでバグの混入を未然に防げるのだけど
土方はとりあえず初期化しちゃうから後々デバッガで追いかけることになる

801 :デフォルトの名無しさん:2013/08/25(日) NY:AN:NY.AN
>>800
つまり、Javaではローカル変数を初期化しないのがベストプラクティスで
あるということか?

802 :デフォルトの名無しさん:2013/08/25(日) NY:AN:NY.AN
初期化のための初期化でゴミを入れるなってこと

803 :デフォルトの名無しさん:2013/08/25(日) NY:AN:NY.AN
>>802
初期値が間違ってるってことねなるほど。
変数は必要になったときに宣言するようにすれば問題ない。

804 :デフォルトの名無しさん:2013/08/25(日) NY:AN:NY.AN
>>801
文脈として初期値が必要なケースでなければね

例えば以下の例はエラーになる。
以下の例は例外が起きたら別の処理を行ってから再び例外を投げたいものとする。

String value;
try {
    value = ...
} catch (Exception ex) {
    doSomething();
}
AnyClass obj = new AnyClass(value);
...

これは仮に value を null で初期化してたら
コンパイラがやってくれるチェックを自分ですることになる。

805 :デフォルトの名無しさん:2013/08/25(日) NY:AN:NY.AN
>>804
うーん?
間違った初期値を設定することが問題なんだよね?
だったら初期値なんか書くなと言うのは論点がおかしくないか?

806 :デフォルトの名無しさん:2013/08/25(日) NY:AN:NY.AN
ローカル変数だけしかチェックできないウンコじゃん
静的型言語の面汚しだよね

807 :デフォルトの名無しさん:2013/08/25(日) NY:AN:NY.AN
フィールドはdefaultで初期化されるからな

808 :デフォルトの名無しさん:2013/08/25(日) NY:AN:NY.AN
>>805
初期化してないとコンパイラが止めるんだよ
その止めるという機能が恩恵にあずかっている機能
throw exで再度例外を投げればコンパイルエラーにはならない
つまり正常系のみ処理が進むことが保証される

809 :デフォルトの名無しさん:2013/08/25(日) NY:AN:NY.AN
そのコードがどういう状況で到達可能なのかをJavaコンパイラはある程度理解している
到達不可能ケースで未初期化変数を参照してもコンパイラは無視するし問題にもならない

810 :デフォルトの名無しさん:2013/08/25(日) NY:AN:NY.AN
>>807
ぬるぽですね

811 :デフォルトの名無しさん:2013/08/25(日) NY:AN:NY.AN
どのみちオラクルの手に渡った時点でおわこんだよ

812 :デフォルトの名無しさん:2013/08/25(日) NY:AN:NY.AN
オラコン

813 :デフォルトの名無しさん:2013/08/25(日) NY:AN:NY.AN
預言者オワクル

814 :デフォルトの名無しさん:2013/08/26(月) NY:AN:NY.AN
オリハルコン

815 :デフォルトの名無しさん:2013/08/26(月) NY:AN:NY.AN
 
\\
\\\
\  ∧_∧
   ( ´・ω・)
   G   と) ガッ >>810
    ヽ⌒)、 \人∧__∧
      ̄ (_) >`д´)')
         ∨つ   /

816 :デフォルトの名無しさん:2013/08/29(木) NY:AN:NY.AN
F#の生産性が高すぎて人生が辛い(´・ω・`)

817 :デフォルトの名無しさん:2013/08/30(金) NY:AN:NY.AN
お前らバイトです

がんばってください

暑いならビール

818 :デフォルトの名無しさん:2013/08/30(金) NY:AN:NY.AN
そんなにF#いいのん?

819 :デフォルトの名無しさん:2013/08/30(金) NY:AN:NY.AN
すごいHaskell
もっとすごいF#

820 :デフォルトの名無しさん:2013/08/30(金) NY:AN:NY.AN
言語的にはHaskellやLispの方がイイかもだけどC#よりははるかに上。

IDEとかライブラリ含めた総合力ではトップクラスだと思う

821 :デフォルトの名無しさん:2013/08/30(金) NY:AN:NY.AN
>>820
HaskellとかLispのどこがいいんだよ

822 :デフォルトの名無しさん:2013/08/30(金) NY:AN:NY.AN
Webサービスか
それともスクリプトから呼ばれるライブラリか

823 :デフォルトの名無しさん:2013/08/30(金) NY:AN:NY.AN
F#は実行時に決まる部分が多すぎだろ。
.NETの呪縛から逃げ切れてない。

824 :デフォルトの名無しさん:2013/08/30(金) NY:AN:NY.AN
だな、コンパイル終了の時点で要求メモリ量が分からないなんて、
大規模計算処理では使い物にならん

この条件を満たすのは COBOL/FORTRAN/C などで、
これらはどれも実世界の社会インフラを支える本物のプログラミング言語だ

JavaやらC#みたいな実行時にメモリを割り当て、
そのあげくに不要になったゴミ回収が必要になるなんて、
これらがお子様むけのオモチャ言語である証拠だ





こうですか?よくわかりません ........

825 :デフォルトの名無しさん:2013/08/30(金) NY:AN:NY.AN
>>823
どのへん?OCamlだとその辺は良いもんなん?

826 :デフォルトの名無しさん:2013/08/30(金) NY:AN:NY.AN
>>825
Ocamlは知らん。
F#は型の取り扱いがJavaみたいで面倒。

827 :デフォルトの名無しさん:2013/08/30(金) NY:AN:NY.AN
Ocamlって岡村って人が作った言語ですか?

828 :デフォルトの名無しさん:2013/08/31(土) NY:AN:NY.AN
そうです。
同様の言語にMTsumt(通称Ruby)があります。

829 :デフォルトの名無しさん:2013/08/31(土) NY:AN:NY.AN
>>826
何がJavaみたいなんだか分からん。イイと思う言語とのひかくでよろ

830 :デフォルトの名無しさん:2013/08/31(土) NY:AN:NY.AN
Lispはゴミ
いまどきLispなんて使っているバカは頭がクルクルパー

831 :デフォルトの名無しさん:2013/09/01(日) 09:01:26.40
Clojourならどうよ

832 :デフォルトの名無しさん:2013/09/01(日) 10:40:31.79
名前も覚えられないのに勧めるなんて

833 :デフォルトの名無しさん:2013/09/01(日) 11:13:49.94
一時期clojureのステマが酷かったけど
全然流行らなかったな

834 :デフォルトの名無しさん:2013/09/02(月) 00:02:23.53
>>832
ケツの穴のちいせぇ男だな( ´Д`)y━・~~

>>883
まぁアレは番人が使うものではないんじゃないか。使う人は使ってるでしょ。

835 :デフォルトの名無しさん:2013/09/02(月) 00:24:23.03
>>833
Lispが流行る(一般プログラマに受け入れられる)わけねーじゃん
あれはClojureのステマじゃなくてjvm言語ステマの一環です

836 :デフォルトの名無しさん:2013/09/02(月) 23:46:49.93
>>834
安価もまともに打てないのに勧めるなんて

837 :デフォルトの名無しさん:2013/10/02(水) 15:31:09.47
あれって、lisp周りの資産をそのままjavaで流用するためのものだろ
普通の業務開発のどんな場面でlisp資産を使うのか甚だ疑問
一般的な開発者には何の恩恵もないって。触るだけ時間の無駄

838 :デフォルトの名無しさん:2013/10/02(水) 18:10:33.83
Lisp周りの資産をそのままJAVAで使うなら、ClojureではなくABCLを使うと思う。

839 :デフォルトの名無しさん:2013/10/02(水) 19:39:56.19
>>837
開発対象がどうあれ生産性、保守性の高い言語を使うだけだろ。
まあ普通のプログラマはLispなんか使わず分相応のもの使ってればいいんじゃね?

840 :デフォルトの名無しさん:2013/10/03(木) 02:28:55.83
今時のソフトウェアやシステム開発は言語単体もそうだけど、テストやデバッグ、
デプロイメント、ドキュメンテーションや運営等の周辺も色々含めての生産性に
なるんだけどね。使い捨てに近いコードを早く書けるってのだけじゃダメな段階に
なってきてる。

841 :デフォルトの名無しさん:2013/10/03(木) 06:08:29.94
厳密性を取るなら関数型だが
これに柔軟性を加えるならJavaScriptのような
スクリプトLLしかありえない
工夫のない静的型付け言語はクソ

842 :デフォルトの名無しさん:2013/10/03(木) 09:59:38.43
>>841
静的関数型では出来ない柔軟性ってどんなんよ。
でそれが必要な場面ってどんなんよ

843 :デフォルトの名無しさん:2013/10/03(木) 10:26:56.39
できるできないじゃなくて潜在開発生産性は一番少ないってことだな。
至極当然。

844 :デフォルトの名無しさん:2013/10/03(木) 11:43:38.17
だから、そう思う理由を尋ねられてんだろアホ

845 :デフォルトの名無しさん:2013/10/03(木) 12:17:13.59
C#とF#メインで使っていて、この間HTML5の技術検証でjavascript触ったけど生産性の低さにびっくりしたわ。
動かすまでわからないタイポ、イミフなスコープ、イミフなthis。このthisは何を指すかがクイズになるぐらいイミフw
メソッドヒョコヒョコ付け足したり便利なとこもあるかもだがそれを押しつぶすほどのイミフな仕様でもううんざりですよ(´・ω・`)

846 :デフォルトの名無しさん:2013/10/03(木) 12:39:06.87
>>845
そりゃよく知らない言語使えば生産性落ちるだろ
静的型付け言語なら言語仕様知らなくても生産性が高いっていう主張?
ていうかお前が言ってるのって、動的型付けっていうかJS固有の話だから

俺は静的型付け派だけど

847 :デフォルトの名無しさん:2013/10/03(木) 14:28:15.39
>>845
そこら辺が安定していてバカでも書けるのが静的型付言語
Javaが典型的な例で、ただの静的型付言語には潜在性などない

逆に言うと可能性を無くすことで安定性、統一性、厳密性を取るのが
静的型付言語の最も基本となる性質だから当たり前
束縛のなく気楽な自由にこそ可能性はある

848 :デフォルトの名無しさん:2013/10/03(木) 17:36:31.74
>>845-846
上でjavascriptがーとか言ってるから書いたんだけどなんか話の流れおかしいか?
jsは柔軟性のメリットとデメリットで後者が勝るだろって話だけど

849 :デフォルトの名無しさん:2013/10/03(木) 17:46:25.76
おかしい。
LispからJavaScriptときて、やっぱり動的型付け言語の方が可能性あるよねって話の流れだから。
ましてや対して使ったこともない奴が1つの言語取り上げて云々言うのはスレチ。

それにメリットとデメリットなんて紙一重で表裏一体のもの。
それでも潜在能力はそちらの方が上だよねっていうスレタイに沿った流れ。

特定言語の批評ならここがオススメ。
http://toro.2ch.net/test/read.cgi/tech/1379350030

850 :デフォルトの名無しさん:2013/10/03(木) 17:56:55.22
JavaScriptは当初は敬遠されてた
構文は10年前から殆ど変わってない
それなのに今では活躍してる
それは一言で言えば柔軟性のお陰

ES6,7を見ればわかるが
あんなに言語を拡張しても
後方互換性を失わなわずに済むのは
総じて柔軟性のお陰

柔軟性こそが直接潜在性に繋がる
静的型付け言語はその考え方と合わない
最近の主流に合わせるんなら最近出来た言語を使うか
結局後方互換性をなくして新しく設計しなければならない

つまり言語に可能性がない
言語に可能性がないのに開発の可能性なんてない
静的思考言語でそれを求めるんなら先に上げたように
別物に乗り移るしかない

今あるものに可能性、長期間の進化を求めるのならそりゃLLが一番に決まってる
その例としてJSは至極適当

851 :デフォルトの名無しさん:2013/10/03(木) 20:23:59.98
>>849
何ができるようになるかって可能性と生産性は別の話だろ(´・_・`)

852 :デフォルトの名無しさん:2013/10/03(木) 21:54:33.61
>>850
> それなのに今では活躍してる
> それは一言で言えば柔軟性のお陰

環境とライブラリが出来たからだろ?

言語としては普通だけど、
それだけじゃだめだってことだよ。

853 :デフォルトの名無しさん:2013/10/04(金) 13:51:57.10
つまりその分可能性があるってことだなやっぱり。
といううか普通に考えてあらゆる意味で変更に強いのは動的型付け言語だし。
つうかこのスレ期待してたけど1つも「静的型付け言語の潜在開発生産性」とやらが示されてないんだけど?
批判するだけなのは楽でいいよな。

854 :デフォルトの名無しさん:2013/10/04(金) 14:04:14.99
「変更に強い」の定義によるな。
同じ機能変更に対して
変更するコード量が少なくて済む、なら動的型付け言語だし
変更によるバグ混入の可能性を少なくする、なら静的型付け言語だな

855 :デフォルトの名無しさん:2013/10/04(金) 14:38:36.99
JavaScriptが拡張に強いのは動的型付けだからでもLLだからでもじゃない
Webを背負ってるのと大きな勢力が幾つも関わってて慎重だからだよ

勿論最初はどのLLも皆シンプルでこの性質を持ってるけど
すぐに便利そうなものをどんどん追加して10年立たずに多くが破綻する

JavaScriptは言語の整合性を崩すような奇妙なものは入れてないし、これからもそう
これは紛いなりにも構文がJavaを参考にして生まれたお陰

反対にPerlを参考にした正規表現に限っては腐って非推奨の山になってる
そういうことだよ

856 :デフォルトの名無しさん:2013/10/04(金) 16:03:44.49
その割にライブラリレベルのプラットフォーム互換性低すぎ。
あと構文がJavaを参考にしているとか意味不明。

857 :デフォルトの名無しさん:2013/10/04(金) 16:17:40.76
jQuery等が出てきてDOMやXMLHttpRequestを叩く際のブラウザ間の差異を吸収して
くれるようになったので手軽にDHTMLやAJAXも扱えるようになったのであって、
それ以前のJavaScriptでのクロスブラウザ開発はまぁ酷い物だったと思う。

858 :デフォルトの名無しさん:2013/10/04(金) 16:24:52.40
>>853
そもそものjavascriptの出自が10日で作った突貫工事で、とりあえずなんでもできるようにしといたことで色々やる術が有るとして、それと実際にプログラムする時の生産性は別だろよ(´・ω・`)

おまいらjavascriptでどこまで大規模なやつつくってんの?プロトタイプ作るのには使ったけど訳わかめなバグくらいそうでこれをそのまま大規模に適用するのはためらわれるわ。

859 :デフォルトの名無しさん:2013/10/04(金) 17:34:33.68
JavaScriptとかクソ言語だと思うが、
大規模にこだわるのはもっとクソだと思うぞ。

860 :デフォルトの名無しさん:2013/10/04(金) 17:55:26.39
>>856
「a > b > c」と「a > b && b > c」が同義ではないという
スクリプト言語としてはかなり残念な性質を持ってるが
その辺り基本構文は全部Javaからの参考

あとライブラリの互換性も高い
DOMを使ったものでなければ転用は容易


>>857
それはJavaScript関係ない
DOMは皆のもので特定言語だけのせいじゃないし
IEのは暫くJScriptでJSとは違ってた
所謂ECMAScript自体に悪い点はない

861 :デフォルトの名無しさん:2013/10/04(金) 17:59:42.12
>>858
大人数でやる大規模は現状大変かもしれないが
1人で作るものに限っては1000行、5000行書いてもそう困った事はない
デバッガが優秀になってくれたおかげがなによりまず一番だし、
言語仕様として事前(コンパイル前)エラーが出るようになったから
十二分ではないが七、八分くらいは満足できる

あと別に現時点で生産性が高いとは誰も言っていない
潜在開発生産性は高いということ
それはデバッガの進化もエンジンの進化も当然あるし、
ES.nextで大規模開発向けの仕組みが続々と入る

型に関しても色んな型やguardという仕組みがES7で入る
これは型を決めて宣言するのではなく、受け入れる型のタイプを選ぶ
まさに「ガード」を設置するというもので汎用性がかなり高い

現状活躍出来てるのはライブラリやWebAPIのお陰という声もあるが
それらは標準に取り入れられてきてる
最近だと型付配列、そういうものからもっとフレームワーク的なものまで
言語を支える仕組みとして導入が予定されている

とにかくJSはどんどん進化していけるんだから
可能性の高さは否定出来ない
というか、もしかすると一番それを示してくれていて、
これからも見せてくれる言語ではないのか

862 :デフォルトの名無しさん:2013/10/04(金) 18:23:54.95
>>860
>「a > b > c」と「a > b && b > c」が同義ではないという
>スクリプト言語としてはかなり残念な性質を持ってるが
>その辺り基本構文は全部Javaからの参考

ここ、笑うところでしょうか?

863 :デフォルトの名無しさん:2013/10/04(金) 18:31:59.73
>>860
>「a > b > c」と「a > b && b > c」が同義ではないという
>スクリプト言語としてはかなり残念な性質を持ってるが

JSはどうでもいいが、よく知られた言語の中で「a > b > c」と
「a > b && b > c」が同義なのはPythonだけじゃないのか?
a > b > c が型エラーにならないJSは残念な性質かもしれないが、
比較のためだけに意味不明な構文を設けているPythonも欠陥言語だろ

864 :デフォルトの名無しさん:2013/10/04(金) 18:46:46.75
>>862
笑うところじゃないよ
実際にES.nextで議論されたけどJavaベースのJSでは無理だねってなったことだから

>>863
単変数ならまだいいけど
DOMやCSSのプロパティはやたら長い事があるから
それらを比較する時結局見栄えなんかのためにキャッシュすることが避けがたく
余計な行数と変数が増えて手間がかかるのは実際問題悲しい

865 :デフォルトの名無しさん:2013/10/04(金) 19:55:55.03
笑うところだろ
a > b > cと書けるかどうかと
構文がJava風かどうかなんて
これっぽっちも関係ないw

866 :デフォルトの名無しさん:2013/10/04(金) 20:12:59.72
>>865
そこは一例だよ
最近取り上げられたから出しただけ
証明としての例じゃなくて、それが与えた結果を説明する例だから
別に矛盾してないんだから成立している

867 :デフォルトの名無しさん:2013/10/04(金) 20:23:19.63
そうかー、JavaScriptがJava風ってんなら、
きっと最近のJavaではオブジェクトリテラルを書けるんだなw
きっと最近のJavaScriptはclassとかextendsとかimplementsとかするんだなw
publicとかprotectedとかprivateとかアクセス修飾子つけるんだなw

そもそも「;」に関する構文規則すら違うというのにww

あほじゃなかろうかw

868 :デフォルトの名無しさん:2013/10/04(金) 20:46:56.94
classは入るぞ爺さん

869 :デフォルトの名無しさん:2013/10/04(金) 20:49:18.51
>>861
その可能性ってのは現在が足りないものゆえやれることがあるってのと同義ではないの?

逆にある程度成熟してしまったが故に進化がほとんどない言語というものもあるかもだけど。

javascriptだけがいつまでも可能性を秘めたまま進化していける理由があるなら教えてくれたまい。

870 :デフォルトの名無しさん:2013/10/04(金) 20:58:37.52
ES7がブラウザで広く使えるようになるのって何時よ。
個人的にはJava10と良い勝負だと思う。

871 :デフォルトの名無しさん:2013/10/04(金) 21:41:21.07
>>867
JavaScriptでは昔から
class、extends、implements、public、protected、private
は予約語
class、extends←ES6
private←近いうちに入る
public、protected←検討中

872 :デフォルトの名無しさん:2013/10/04(金) 21:48:58.80
>>869
理由は散々書いたし、別に無限とは言っていない
ただ数年で変わる言語と比較したら、ざっと5倍ほどの柔軟性はあるし
こんなにも広い範囲で活躍できる言語であることは事実

>>870
別にブラウザで広く使える必要なんてない
Node.jsやFirefoxOS、各種ブラウザアプリなんてのもあるんだから
それにJava10と大きく違うのは、
全て後方互換性を崩さない変更だから
どれでも形になったものから少しづつ追加できること

今も各ブラウザはそれぞれ10%〜50%くらいES6に対応してる
お決まりの言葉で言うとLivingStanderd
そういう目で見るとES7が来るのは遅くても2015年中から

873 :デフォルトの名無しさん:2013/10/04(金) 22:37:22.38
ブラウザにスクリプトが載ってることには意義があるがJavascriptは嫌い
emscriptenでてからC++から変換できるようになって直接書かなくなった

874 :デフォルトの名無しさん:2013/10/04(金) 22:40:43.94
あー、まー誰にでも好き嫌いはあるよね。
そんだけのこと。

875 :デフォルトの名無しさん:2013/10/04(金) 23:45:42.46
いやあんなので大規模なコードかけない

876 :デフォルトの名無しさん:2013/10/05(土) 01:12:18.50
書き方を知らないだけ。
動的型付け言語には動的型付け言語らしい書き方がある。
アプローチの仕方とも言っていい。

877 :デフォルトの名無しさん:2013/10/05(土) 02:03:15.14
大きなJavascriptのオープンソースプロジェクトってなんかある?

878 :デフォルトの名無しさん:2013/10/05(土) 02:06:30.72
旬なのだとshumwayとか?
この前Firefoxに入ったよね

879 :デフォルトの名無しさん:2013/10/05(土) 02:23:14.43
大きいプロジェクトでJavaScriptが
使われている例ならたくさんあるんだけどね。

880 :デフォルトの名無しさん:2013/10/05(土) 02:39:07.71
Node.jsとかもJSの塊やぞ

881 :デフォルトの名無しさん:2013/10/05(土) 04:33:46.99
いやそれ処理系やん・・・

882 :デフォルトの名無しさん:2013/10/05(土) 05:10:49.06
JavaScriptに関しては普通にブラウザ向けの開発で使わざるを得ないのだがいつになったら
このウンコな変数スコープとのおつきあいを止められるのか。

883 :デフォルトの名無しさん:2013/10/05(土) 07:38:43.16
たかが変数のスコープごときで何言ってんだから。

だからおまえは、知らないんだって
ばれるんだよ。

884 :デフォルトの名無しさん:2013/10/05(土) 07:41:09.34
>>872
広い範囲でって、そのほとんどがブラウザーがjavascriptエンジンを乗っけてることに起因するんじゃないの?

ブラウザーの乗っけてるのがjavascriptエンジンじゃなく仮想マシン処理系でその上で使える言語は何でもいいとなったらjavascriptは選択されないと思うけどね。

まぁ家庭の話をしてもしょうがないのでjavascriptの柔軟性の源泉について>>841からの流れにあるの?

885 :デフォルトの名無しさん:2013/10/05(土) 07:46:51.42
>>884
nodeの存在が、それが間違いであることを証明した。

886 :デフォルトの名無しさん:2013/10/05(土) 08:27:06.78
node.jsはクライアント側がjsだからというだけの理由で話題になっただけで
マトモな実用にはなっていないだろw

887 :デフォルトの名無しさん:2013/10/05(土) 09:46:55.14
>>885
いや、それも処理系の場所が増えたってだけで言語としての特性は関係ないんじゃないの?
nodeの利点はクライアントと同じ言語でサーバーサイドもかけるよってのが主じゃない?

888 :デフォルトの名無しさん:2013/10/05(土) 09:58:49.07
>>887
それを言ったら他の言語だってそうだろ。

でもひとつ言えるのは、言語がだめなら
サーバーサイドで使われることはないということ

全ての言語は、積極的な良い理由があって使われるんじゃない。
実用レベルの言語であり、言語の特性以外の何かしらの
理由があって普及したものが、使われるんだ。

889 :デフォルトの名無しさん:2013/10/05(土) 10:26:22.07
>>887
>それを言ったら他の言語だってそうだろ。
いや違うだろ。
PHPなんてクライアントで使ってるの見たこと無いが。

890 :デフォルトの名無しさん:2013/10/05(土) 10:30:08.44
>>888
>でもひとつ言えるのは、言語がだめなら
>サーバーサイドで使われることはないということ

おまえ、それ Perl さんの前で言ってみろ!w

891 :デフォルトの名無しさん:2013/10/05(土) 10:41:50.71
Nodeのパフォーマンスがいいだけで、言語そのものは駄目だろ。

892 :デフォルトの名無しさん:2013/10/05(土) 11:18:33.84
フォールトトレランスを考慮にいれたら
Nodeなんて選択肢にも上がらんゴミ

893 :デフォルトの名無しさん:2013/10/05(土) 11:47:53.21
>>883
>たかが変数のスコープごときで何言ってんだから。

たかがも何も、とても重要でいわゆるオブジェクト指向プログラミング言語だと
必須なんだけどな。カプセル化とか知らんのかね? COBOLが嫌われるのは
全部グローバル変数なところだし。スパゲッティなコードを書きたく無ければ
変数のスコープがきっちり決まってる方がいいんですよ。

894 :デフォルトの名無しさん:2013/10/05(土) 11:57:56.18
Javaもpublicなstatic変数使えるしC/C++はグローバル変数がある
そこをJavascriptだけ指摘するのはおかしいな。

newとfunction駆使すればクラス相当の書き方可能だし。

プロトタイプベースが基本なのがわかりにくいんだと思う。

895 :デフォルトの名無しさん:2013/10/05(土) 12:02:41.92
>>894
いや、デフォルトがグローバルとか、
こんなんで実用する気になるほうがおかしい。

896 :デフォルトの名無しさん:2013/10/05(土) 12:12:08.59
use strictつけるだけのものをそんなに気にするのがおかしい

897 :デフォルトの名無しさん:2013/10/05(土) 12:26:26.97
そんなクソ宣言が必要であることが気にならないのがおかしい

898 :デフォルトの名無しさん:2013/10/05(土) 12:30:28.34
C/C++でもワーニングレベル調整しなきゃざるだし
LLがそういうデフォルトになってるのにケチつけるのはおかしい

899 :デフォルトの名無しさん:2013/10/05(土) 12:35:17.91
気軽さが身上のLLなのにそんなボイラープレートが必要な時点でダメ言語だろ

900 :デフォルトの名無しさん:2013/10/05(土) 12:45:29.16
LL基本だからvarつけなくても動作する。
チェックをしたい場合はuse strictをつける。

まさに仕様なんで
これが気に食わないってことならあまり相手にされないと思うよ。

901 :デフォルトの名無しさん:2013/10/05(土) 12:47:52.89
varを付けたときと付けないときの挙動が
逆なら良かったね

902 :デフォルトの名無しさん:2013/10/05(土) 12:51:33.91
まさに仕様なんで気に食わないってことならあまり相手にされないと思うよ。

903 :デフォルトの名無しさん:2013/10/05(土) 12:59:42.54
結論は>>901だな。undefinedに代入ができたり。実にダメな言語だ。

904 :デフォルトの名無しさん:2013/10/05(土) 13:09:48.04
まさに仕様なんで気に食わないってことならあまり相手にされないと思うよ。

905 :デフォルトの名無しさん:2013/10/05(土) 13:18:09.26
仕様がうんこ
仕様だからで思考停止する奴もうんこ

906 :デフォルトの名無しさん:2013/10/05(土) 13:22:43.02
別にJavascriptがいいなどとは言ってない。
>>893は的外れだから相手にされていないと言っている。

907 :デフォルトの名無しさん:2013/10/05(土) 13:36:35.21
クソプログラマはスコープなんて気にしないってこと?

908 :デフォルトの名無しさん:2013/10/05(土) 13:46:54.64
後付けされたstrictモードの存在自体がJavaScriptの"varつけ忘れでいきなりグローバル"
という元々の振る舞いは失敗でしたウンコでしたと認めたようなものでしょ。

仕様だから我慢すれというのであれば別にES6でlet導入する必要も無いんでない?
こんなのが導入されるのもまともなブロックスコープすら無いと方々でブーブー文句言った
からでしょ。現状のJSの関数スコープが素敵だなんて話殆ど聞いたことが無い。
いまさらごく当たり前のブロックスコープを導入したところでIE10とそれ以前が無視できる
レベルまで置き換えが進まない限りブラウザ向けの開発では使えないんだれどもな。

class等にしてもそう。クラス的なことをするのに現状どれだけ異なる書き方の流儀がある
ことやら。import的な仕組みもライブラリごとに手作りしていたりとか。ES6でこの辺りに
仕様の追加が入るのもそういう現状はよろしくないよねという合意があるからでは?

あとは型注釈かな。きっちり型注釈が入ったライブラリで開発できるFlex+AS3は現状でも
なかなか優れたGUI開発系だし、HaxeはもちろんTypeScriptやDartなどJavaScript+型注釈
的な後発言語も多いのもそのメリットは無視できないからだと思う。
ただこれもブラウザ上のJSが対応するにしても広く普及するのはずっと未来だろうな。

909 :デフォルトの名無しさん:2013/10/05(土) 13:48:49.51
github、RubyとMVCの限界を悟りC#とMVVMに全面移行 / オープンソース界に激震
http://engawa.2ch.net/test/read.cgi/poverty/1380941226/

910 :デフォルトの名無しさん:2013/10/05(土) 13:57:38.08
的外れが図星でワロタ

911 :デフォルトの名無しさん:2013/10/05(土) 14:03:45.31
的を射ててワロタ

912 :デフォルトの名無しさん:2013/10/05(土) 15:37:23.33
>>888
だからそういった動く環境が多いとか言った話を除いて、この言語は可能性無限だぜひゃっはー!って言ってる言語上の特性ってなによって話をしてんだが。

なのにいろんなとこで動くからとかnodeがーとか言うから話がそれる(´・ω・`)

913 :デフォルトの名無しさん:2013/10/05(土) 16:31:03.74
だから言語上の特性が理由じゃなくて、
色んな所で動くから可能性無限大なんだろ。

914 :デフォルトの名無しさん:2013/10/05(土) 16:38:55.13
>>888
>でもひとつ言えるのは、言語がだめなら
>サーバーサイドで使われることはないということ

ダウト。どんなクソ言語でもサーバで使うヤツは必ず現れる。

正しくは「JavaScriptでさえ、サーバサイドで使われた。」

915 :デフォルトの名無しさん:2013/10/05(土) 16:40:35.26
色んな所で動く+大企業のサポートが強大って所かな。

いかに言語が優れていたとしても、
それ以外の部分ができてないとダメなんだよ。

そしてそれ以外の部分を強化するのってすごく難しんだよね。
努力だけではなく運やコネなんかも必要。

その点、JavaScriptは言語以外の部分が極めてすごい。
そのため、急速に言語の問題点も改善されていっている。

ほら、可能性無限大でしょ?

916 :デフォルトの名無しさん:2013/10/05(土) 16:41:29.27
JavaScriptをサーバーで動かすってのも
言語的にはもともとダメだった。

だけど、言語以外の部分が強力だから
ほら、大幅に改善された。

917 :デフォルトの名無しさん:2013/10/05(土) 16:43:41.10
つまり言語自体はクソだと認めた訳だなw
JavaScriptがいまだに使われているのは大企業のゴリ押しのおかげ。

918 :デフォルトの名無しさん:2013/10/05(土) 16:45:34.24
馬鹿だなぁ。
クソなんて一言も言ってないじゃん。
反論の前に、お前の推論能力を疑うわw


反論ほしいのか? 簡単。クソの理由が無いか、
重箱の隅をつつくようなものしか無い。
以上。

919 :デフォルトの名無しさん:2013/10/05(土) 16:46:39.59
必要な機能がなければクソだが
すごい機能がなければ、クソってことにはならないんだよね。

そこんところよく勘違いしている人がいる。

920 :917:2013/10/05(土) 16:49:50.71
>>918
企業サポートが強い = 言語はクソ

極めて論理的で科学的な推論です!
成績は5です!

921 :917:2013/10/05(土) 16:52:03.65
>>920
ナリスマシしてまでJavaScriptを傑作言語にでっち上げたいのかw
おまえ、人間として最低のカスだよ。

922 :デフォルトの名無しさん:2013/10/05(土) 17:00:05.91
最低だな

923 :デフォルトの名無しさん:2013/10/05(土) 17:03:04.01
いや、優秀なIDEだとおかしな構文を勝手に修正してくれるじゃないか

924 :デフォルトの名無しさん:2013/10/05(土) 17:32:40.66
改善されるも何も、その改善された仕様だけでやってけるのは何時になるのでしょうか?

925 :デフォルトの名無しさん:2013/10/05(土) 17:38:54.20
>>921
なりすましなのか?

どうでもいいけど、じゃあなんで
お前は企業サポートが強いといったら、
言語がクソだと認めた訳だなって言ったんだ?
これならなりすまししてる人と同じ事言ってるじゃん。

さあ説明を求む。

926 :デフォルトの名無しさん:2013/10/05(土) 17:42:15.31
>>924
ロボットがプログラムを書いてくれないのなら
人間が書いても同じなんですよね。
仕事が減りません。どうすれば・・・。

927 :デフォルトの名無しさん:2013/10/05(土) 18:01:50.74
言語仕様への問題指摘に対して何の反論もできていない挙げ句の
> いかに言語が優れていたとしても、
> それ以外の部分ができてないとダメなんだよ。
だからなあ

マトモな対人コミュニケーション能力を持っていれば結論は見えてるよな

ところでナリスマシしといて逆ギレってのは、本当にみっともないぞ

928 :デフォルトの名無しさん:2013/10/05(土) 18:03:55.57
JavaScriptだって悪い所はあるさ
それに
メリットとデメリットなんて表裏一体
それを静的言語系の人は大抵デメリットと感じるのは当然の当然

デフォルトでグローバル変数になるのだって
プロトタイプベースなのだって
スコープチェーンとプロトタイプチェーンという
真に自由なオブジェクト指向プログラミング言語なんだからだよね

http://www.slideshare.net/yuka2py/javascript-23768378

929 :925:2013/10/05(土) 18:08:19.96
やっぱ説明できなくて逃げたねw

930 :デフォルトの名無しさん:2013/10/05(土) 18:17:42.48
良い悪いなんて人の好みだと思うが、公平に速度の観点から見ると
JSは悪い言語設計とは言えないと思うな

931 :デフォルトの名無しさん:2013/10/05(土) 18:19:53.17
だからJSは普通にいいんだってw

932 :デフォルトの名無しさん:2013/10/05(土) 18:27:49.36
全く…JSは最高だぜ!!

933 :デフォルトの名無しさん:2013/10/05(土) 18:27:51.68
>>929はどこまでゴミ人間なんだろうねwww
逃げて、なりすまして、また逃げて、ついに逆ギレして、呆れられて、勝利宣言w

面白いから晒しとくw

934 :925:2013/10/05(土) 18:34:05.56
なりすましじゃないんだけど?

どうでもいいけど、じゃあなんで
お前は企業サポートが強いといったら、
言語がクソだと認めた訳だなって言ったんだ?
これならなりすまししてる人と同じ事言ってるじゃん。

さあ説明を求む。

935 :デフォルトの名無しさん:2013/10/05(土) 18:51:02.56
>>934
言語のクソな部分の具体的な問題点の指摘に何の反論もできずに逃げた事

胸に手を当てて考えてみろwゴミ人間くんw

936 :デフォルトの名無しさん:2013/10/05(土) 18:52:14.29
>>925
>さあ説明を求む。

自分がなりすました理由を説明したら?

「恥を知れ」って、よく言われない?

937 :デフォルトの名無しさん:2013/10/05(土) 18:58:02.62
1か0か病はプログラマや理系人間の悪い癖
さらにたちが悪いのは
1を信仰するものはたとえ0.99であっても1じゃないとケチを付け
0を信仰するものはたとえ0.01であっても0じゃないとケチを付けること
お互い歩み寄ろうとしない

938 :925:2013/10/05(土) 18:58:32.91
なんか必死だね。
なりすましは俺してないし、
誰かと勘違いしてるんじゃないか?
まったく思い込みで何一人で熱くなってるんだかw



918 名前:デフォルトの名無しさん[sage] 投稿日:2013/10/05(土) 16:45:34.24
馬鹿だなぁ。
クソなんて一言も言ってないじゃん。
反論の前に、お前の推論能力を疑うわw


反論ほしいのか? 簡単。クソの理由が無いか、
重箱の隅をつつくようなものしか無い。
以上。

939 :デフォルトの名無しさん:2013/10/05(土) 18:58:54.59
920が排泄物なのは確定だな。

940 :デフォルトの名無しさん:2013/10/05(土) 18:59:44.75
JavaScriptは良い言語だし、
企業のサポートも多いから
今でも普及しているが
これからさらに普及するということでしょ。

941 :デフォルトの名無しさん:2013/10/05(土) 19:00:01.68
>>938
それがなりすましの言い訳か。呆れたね。最低だね。ゴミだね。

942 :デフォルトの名無しさん:2013/10/05(土) 19:01:14.87
>>941
なんでそんなに必死なの?
親でも殺された?

943 :デフォルトの名無しさん:2013/10/05(土) 19:02:11.80
これはなりすましって言ってる奴が
なりすましの犯人というオチだなw

944 :デフォルトの名無しさん:2013/10/05(土) 19:31:26.45
JS厨バカすぎw

945 :デフォルトの名無しさん:2013/10/05(土) 20:04:41.49
プロトタイプベースは面白いと思うけど、
デフォルトでグローバルは擁護できんな
どう考えても、ローカル変数の方がよく使うんだから

946 :デフォルトの名無しさん:2013/10/05(土) 20:07:13.77
は?
じゃあ上のスコープの変数使う時はどうすんのよ
グローバルっていうのは一番上のスコープってことだぞ

947 :デフォルトの名無しさん:2013/10/05(土) 20:09:02.46
問題はグローバルに新しく変数ができることだけで
アクセスできるのがデフォルトなのは何もおかしくない
まあstrict modeにすればいいだけのことだが

948 :デフォルトの名無しさん:2013/10/05(土) 20:13:19.05
一貫性を保つためでしょ
プロトタイプチェーンと同じでシンプルにっていう思想
x = nonlocal

x = global.nonlocal
が同じになるのが普通なら

nonlocal = x

global.nonlocal = x
が同じになるのが自然って感じな

949 :デフォルトの名無しさん:2013/10/05(土) 20:14:08.87
javascriptでthisとスコープで間違いを犯したことがないものだけ静的に石を投げなさい(´・ω・`)

950 :デフォルトの名無しさん:2013/10/05(土) 20:19:50.01
プログラミング言語の文法で悩んだことにない人だけが、文句を言いなさい。

951 :デフォルトの名無しさん:2013/10/05(土) 20:20:22.54
静的を批判するレスなんてないんだが?

952 :デフォルトの名無しさん:2013/10/05(土) 20:20:58.41
>>949
被害妄想乙

953 :デフォルトの名無しさん:2013/10/05(土) 20:25:07.74
例のJS大嫌いなキチガイが来てるんでしょ?

954 :デフォルトの名無しさん:2013/10/05(土) 20:31:42.81
批判する意見が全て同一人物によるものだと思い始めたら危険
視野の狭い低能にありがちだけど

955 :デフォルトの名無しさん:2013/10/05(土) 20:34:41.25
全員アイツのなりすましだ!

956 :デフォルトの名無しさん:2013/10/05(土) 20:53:24.37
結局>>901でFAでしょ?
use strict とか関係なくて

957 :デフォルトの名無しさん:2013/10/05(土) 20:57:06.04
そんなことはないな
クロージャとか深いスコープネスト多用するんだから

958 :デフォルトの名無しさん:2013/10/05(土) 21:01:49.41
参照するだけなら関係無いし、
そんな簡単に変数を上書きしねーよ
副作用脳のサルかよ

959 :デフォルトの名無しさん:2013/10/05(土) 21:02:43.27
>>949
thisのどんなところが間違えやすいのよ?

960 :デフォルトの名無しさん:2013/10/05(土) 21:07:51.69
変数がヒットせずにスコープチェーンをどんどん遡っていったときに
最終的にグローバルに新しく出来てしまう事が問題なわけで
べつにvarが逆でも問題は解決しない
新しくできるのを防ぐのが大事でそれがstrictmode

961 :デフォルトの名無しさん:2013/10/05(土) 21:09:47.04
ブロックスコープが無いことも叩いて。
実質的な御利益が何もない。

962 :デフォルトの名無しさん:2013/10/05(土) 21:10:24.32
>>960
そんな程度の問題。
昔からjshintあたりで
検出できてたよな。

963 :デフォルトの名無しさん:2013/10/05(土) 21:11:13.54
>>961
ブロックスコープなくても
クロージャースコープが有るじゃん。
これがブロックスコープの代わりになるし、

えー、そもそもブロックスコープが必要になるような
長い関数書かなければいいんじゃね?

964 :デフォルトの名無しさん:2013/10/05(土) 21:13:58.01
>>961,963
意味不
JSにブロックスコープはできただろうが

965 :デフォルトの名無しさん:2013/10/05(土) 21:17:20.24
ブロックスコープはletがあるし、thisバインドのアロー関数もある。
無知ばかり。

966 :デフォルトの名無しさん:2013/10/05(土) 21:19:44.79
ES6でね

967 :デフォルトの名無しさん:2013/10/05(土) 21:21:11.79
letは全ての最新ブラウザで使える(IEは11)

968 :デフォルトの名無しさん:2013/10/05(土) 21:27:11.46
>>960
わざわざvarを付けないと、そんなウンコな振舞いになるのが問題

969 :デフォルトの名無しさん:2013/10/05(土) 21:29:41.51
>>968
つstrict mode

970 :デフォルトの名無しさん:2013/10/05(土) 21:36:10.55
var付ける付かないの問題じゃねえって何度言ったら分かるんかな
C言語しか書いたことのない人か??

971 :デフォルトの名無しさん:2013/10/05(土) 21:36:37.86
varを付けないのが禁止になるだけじゃん

別にvarくらいどうってことないよ?
でも良く使うもの程より短い記述で書けるべきだろ
つまりJS作った奴はアホ

972 :デフォルトの名無しさん:2013/10/05(土) 21:38:53.95
>>970
わかってないお前に一言で説明してやるよ。

varの問題はとっくに解決済み。
お前の言う問題は、全て解決している。

973 :デフォルトの名無しさん:2013/10/05(土) 21:40:27.56
>>971
よく使うもの?

そうだな。

functionとreturnの文字が
1ファイルにつき、1000個ぐらいあるとか
そういう話?

それは書いた奴が悪いよw

974 :デフォルトの名無しさん:2013/10/05(土) 21:42:57.36
ん?
もしかしてローカル変数への代入にはvarがいるとか勘違いしてる?
宣言無しで変数を使った場合は上のスコープにない場合最終的にグローバル変数になるってだけで

問題っていうのは「「宣言を忘れて代入しちゃったとき」」なんだが
忘れてるものを付けるだけだから別に手間が増えるとか無いぞ?

それとも宣言なしに勝手にローカル変数にしろってか?
それはほかのスコープチェーンを辿る挙動と合わなくておかしいだろう

975 :デフォルトの名無しさん:2013/10/05(土) 21:49:14.63
何がおかしいの?

976 :デフォルトの名無しさん:2013/10/05(土) 21:51:29.58
宣言なしに勝手にローカル変数になるってことは
上スコープの変数の参照、代入に全てvarか何かを付けないといけなくなって
かなり大変なことになるじゃん
それくらい考えてよ

977 :デフォルトの名無しさん:2013/10/05(土) 21:54:37.06
代入にはいるけど参照には不要だろ

978 :デフォルトの名無しさん:2013/10/05(土) 21:55:59.44
たかだかブロックスコープを使うためにクロージャ書いたりとかIE10以前が絶滅するのを待つとか、
無駄じゃん。

varの書き忘れを書き損じとして扱うのに毎度use strictとか書くの、無駄じゃん。

普通にこの辺りは初期の言語仕様の失敗だと思うけど。

979 :デフォルトの名無しさん:2013/10/05(土) 21:59:32.21
use strictはテスト時のみつければいいので
対応ブラウザとか関係ない
lintみたいなもの
使ったことない奴がほざくな

980 :デフォルトの名無しさん:2013/10/05(土) 22:00:49.09
"use strict"
の12文字を書くのがそんなに嫌なのか
それなのに冗長な静的型を好む
矛盾

981 :デフォルトの名無しさん:2013/10/05(土) 22:08:08.44
>>976
関数スコープを飛び越えて再代入する時は
何らかの宣言があった方が好ましいよ
再代入は参照に比べると危険な操作だし

982 :デフォルトの名無しさん:2013/10/05(土) 22:10:01.15
静的言語ならそうかもしれないが、スクリプト言語だからね

983 :デフォルトの名無しさん:2013/10/05(土) 22:10:39.77
>>979
テストしたソースを書き直すのはテストの意味ないんだけど?

984 :デフォルトの名無しさん:2013/10/05(土) 22:15:33.61
別に書きなおす必要はないぞ??
非対応ブラウザでは文字列になるだけだから

985 :デフォルトの名無しさん:2013/10/05(土) 22:16:26.77
静的型付けの型推論はどうなのよ

986 :デフォルトの名無しさん:2013/10/05(土) 22:18:38.20
>>983
>>979はテストのときのみと書いてるけれど、対応していない処理系は
"use strict";
を無視するから大丈夫。

987 :デフォルトの名無しさん:2013/10/05(土) 22:22:58.12
"use strict"は開発のサポートのため
もっと言えばグローバル変数以外にも
オブジェクトキーの重複とか、色んな"Early Error"を出すためのものだから
開発が終ればstrict modeだろうがそうで無かろうが大して問題じゃない
最後は「動かないより動いた方がいい」しね

988 :デフォルトの名無しさん:2013/10/05(土) 22:24:07.89
型注釈によるオプショナルな型付け+型推論がベストかと。
いずれも持たないJavaScriptはプリミティブ過ぎる。

989 :デフォルトの名無しさん:2013/10/05(土) 22:30:08.31
JavaScriptでは型は「揃える」もの。
seisu = hoge|0 とか。
DOMを扱うJavaScriptでは型変換がしょっちゅう要るからそこは暗黙的な方が便利。
まあそうは言ってもES7でguardが入るんだけどね。

990 :デフォルトの名無しさん:2013/10/05(土) 22:30:51.47
>>982
スクリプト言語だから、何なの?

991 :デフォルトの名無しさん:2013/10/05(土) 22:33:14.82
型推論は後付けするのは難しい
TypeScriptのゴミ推論を見れば分かる

992 :デフォルトの名無しさん:2013/10/05(土) 22:33:17.18
気軽な方がいいってことじゃない?

993 :デフォルトの名無しさん:2013/10/05(土) 22:35:03.23
コールバック地獄=クロージャ地獄のJSに>>901の仕様は合わない。

994 :デフォルトの名無しさん:2013/10/05(土) 22:49:52.08
http://wiki.ecmascript.org/doku.php?id=strawman:trademarks
http://wiki.ecmascript.org/doku.php?id=strawman:guards

995 :デフォルトの名無しさん:2013/10/05(土) 23:29:10.45
クロージャーっって知ってる?

この機能の重要な点の一つとして
関数上のスコープの変数を読み書きできないといけない
というものがあるんだが、知ってるかな?

varのつけ忘れで上のスコープの変数参照できるからって何?
クロージャーってのはそれが出来ないといけないんだよ。

上に登っていった結果、グローバル変数になったら問題だけど
それは"use strict"で防げるから、今は起こりえない問題。
古いブラウザ用であってもjshintなどで検出もできるし。

996 :デフォルトの名無しさん:2013/10/05(土) 23:51:00.85
同じ話を何回するんだよww

997 :デフォルトの名無しさん:2013/10/06(日) 00:16:40.24
別にクロージャ実現するのにJavaScriptのウンコな関数スコープである必然性も必要性も
無いし、外のスコープの変数を参照できるのはJavaScriptに限らず多くの言語が持つ機能
だし、他方で参照解決できなかったらいきなり大域変数作るなんてメリット何も無いし。

この辺り失敗だった事は後付use strictとletで明らか。
JavaScriptだって欠陥混じりの言語としてスタートして改良を必要としながら変化して
きたことは他の言語と全く変わらん。

仕事でもJavaScriptはそれなりに書くけどうわぁここは型をつけてIDEに仕事させたい
とか成果物ごとにモジュール化の書き方が異なって気持ちが悪いとかクロージャ書く度に
functionfuncitonfunctionfunctionfunction文字数多いよとかクロージャ以前に文字列の
式展開とかヒアドキュメントとか無いの面倒でしょHTML弄るときは特にとか不満は他言語
と同程度に普通に感じるかな。
だから改善にも期待するし、他方で合意形成やブラウザ対応の遅さにもげんなりする。

998 :デフォルトの名無しさん:2013/10/06(日) 00:25:52.84
>>997
名に話をごっちゃにしてるんだよw

クロージャーと関数スコープの話は別だろ。
クロージャーと関係があるのはvarで
変数宣言しなかった場合どうなるかの話だ。

999 :デフォルトの名無しさん:2013/10/06(日) 00:26:16.39
失敗だったものなんてないよ
最悪と言われるwith文だってブラウザでのコンソールシステムとかで活かされてるし
何をどう使うかの話
functionが長いとかもうねw笑わせんな
一応後方互換性は保ちながら進化してるんだから失敗じゃない
そりゃあ新しいバージョンの規格のほうが良いけど
だからといって古いものが何もかも失敗になるわけじゃない
JSに大規模開発サポートが増えてきたのも、使われ方、要求されるものがかわって来たってだけ

1000 :デフォルトの名無しさん:2013/10/06(日) 00:26:58.91
>>997
どの言語にも「失敗が一つもなかった」といえる言語はないよ。
Rubyとか互換性切り離してまで、
失敗した原因をなくそうと頑張ったじゃん。

JavaScriptも同じ。

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

276 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)