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

1 ：2013/03/03 〜 最終レス ：2013/09/02

人間がやっていたことを、コンピュータにやらせる。
これが生産性を上げる最大の方法。
コンピュータは間違わない、同じ事を何度も高速に行える。
その為に、コンピュータがコードの意味を正確に
認識できる方法が必要。実行しないとわからないことは
コンピュータは認識できない。
すなわち静的型付け言語であれば、実行しなくてもわかるので
コンピュータが理解できる。そうすれば様々な
コンピュータの高度な情報支援が得られる。
コンピュータのバックアップを受け、人間の生産性は
限りなく向上する。

2 ：

ここが次スレか。で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 ：

あとこれもつけとくか
初期値を設定する例
943 デフォルトの名無しさん sage 2013/03/02(土) 22:07:33.46
"注入側"
DI type1: NewDelegate withBlock:[Integer integerWithInteger:0.].
"依存排除側"
DI type1 new."Integer integerWithInteger:0.の戻り値が返される"
ね。簡単でしょ。

4 ：

>>2
関係ないスレに出てくるな
キモいよお前

5 ：

主張してる内容は真逆なのに、何故か同じ奴が立てたような気がしてならない
そんな低レベルなスレ
http://toro.2ch.net/test/read.cgi/tech/1362301911/

6 ：

リファクタリングじゃ対抗できないから
スレタイ変えただけだろ

7 ：

いいよココが隔離スレで

8 ：

前スレ

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

9 ：

>>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 ：

>>6
ム板じゃ対抗できないから、マ板に立てたらしいぞ(>>9)

11 ：

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

12 ：

>>10
ム版に立てて欲しいのか？
それなら俺が立てるけど？

13 ：

>>12
面倒くさいからこのスレ使えよ

14 ：

埋もれてる限り無価値に等しいのはお前等のチンコが証明してるだろ
潜在とか言葉遊びは止めるといいね

15 ：

効率上げたかったら型付けなんか計算機にやらせれば良いだろ。

16 ：

ふーんいつになったら潜在能力開花すんの？
おら邪眼の力だか見してみろよ

17 ：

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

18 ：

関数の中に処理が
　A1
　B1
　A2
　B2
　A3
　B3
と並んでいたとする。 これを
　A1
　A2
　A3
　B1
　B2
　B3
と並び替えられるだろうか？
並び替えることが可能であれば、
このよう書き換えることが可能になる。
funcA()
funcB()
funcA {
　A1
　A2
　A3
}
funcB {
　B1
　B2
　B3
}

19 ：

行の並び替えは、出来る場合と出来ない場合がある。
実はコンパイラの最適化ではこのような行の入れ替えが行われている。
だから行の並び替えが出来るかどうかをコンピュータが判定するのは不可能ではないはずだ。
（だが動的型付け言語では不可能だろう）
これは長いコードを短い関数に分割する場合に役に立つ。

20 ：

プロコン目指してる高校生か？
そんな初歩的な話するんだったらtwitterの方が楽しいだろ

21 ：

動的型割り当てなんてモダンな最適化の基礎だろ
人間様が指定してやる時代なんてもう終わるわ

22 ：

ん？ 誰が最適化の話してるんだ？
知ってる用語並べてみた？

23 ：

むしろ言語のほうで人間様が指定しなきゃいけないことが増えてる

24 ：

ゴミムシなのに様なんて名乗れるの？

25 ：

動的言語の時代ｸﾙ━━━━━━(ﾟ∀ﾟ)━━━━━━ !?
って展開は確かにあったけど、結局性的言語持ちこたえてんじゃん。
http://www.tiobe.com/content/paperinfo/tpci/images/history_paradigm_type%20system.png
最近のブログ界隈の議論でも性的言語サイドが明らかに優勢に見えるがどうよ？
思うんだが今の時代、流れが少し良くなったからと調子に乗ると
でっかい落とし穴が待ち構えてるね。任天堂、GREE、マクドナルド以下略
よくよく心しないといけないと思うんだ(´・ω・｀)

26 ：

言っちゃ悪いけどPerl云々で始まった型についての記事なんて
最終的に自分の好みと自分の狭い世界での経験を話しをしてるばかりで
読み物としても大した参考にならんかったわ
プログラマーなら生産性のベンチマークとかして喋れよっていう

27 ：

あ、どちらの派閥もな。
動的型付け派も具体的にどういう測定方法で何倍の生産性が得られるか言わないよね
そんなの議論じゃなくて妄想乙だよ
処理速度の比較くらいだろ定量的なの

28 ：

あれな〜。
速攻で"Perl.*型"をフィードのフィルタにぶち込んだわ。
ナンセンスにも程があるし、ブクマ狙いすぎで実に草い。

29 ：

プログラムを書かない人のためのツールを書く言語がJavaやC#
プログラマ（自分自身を含む）のためのツールを書く言語がPerlやPython

30 ：

そんなずっと前から分かってることで、一人や少人数で小さ目のプログラム書くなら動的型付、多人数で大きなプログラム書くなら静的。この認識で間違いない。

31 ：

>>30
そうではなくて、
型に拘るなら静的型付け、拘らないなら動的型付け、です。

32 ：

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

33 ：

>>32
一般的には確かにそうだと思う。しかし、開発規模に関わりなく、
記号処理用の言語に見られるように、引数にリスト以外の構造体が
来ないことが普通の言語もある。この場合引数の型は意味解析に
全く役に立たない。したがってそういう読み方をしない。

34 ：

全く役に立たない。これは言い過ぎだった。変数名に意味を暗示させる
よりは、型で宣言して、変数のクラスを暗示する方がよいという考え方
もある。

35 ：

>>34で訂正している気がするがまあ無視するとしてｗ
>>33
> この場合引数の型は意味解析に 全く役に立たない。
お前、コンピュータなん？ コンピュータならどんな汚いコードでも
変な名前でも、書いたとおりに正しく動作するよ。だからなんでもいいよ。
だがな、俺らは人間だ。汚いコードだと解析に時間がかかるし、
変な名前でもそうだ。型に関してもそう。
コンピュータが正しく意味解析できるかは問題ではない。
人間が、正しく意味解析できるかのほうが重要。プログラミングの7〜8割は
既存のコードのメンテナンス。新規に書くよりも、既存のコードを読むことのほうが多い。
読む時間を減らす＝開発速度の向上。（文字数＝読む時間ではないぞ。定型句は読み飛ばすから時間には含まれない）
コードを読んで修正するのは人間だ。その人間のためにコードを書くんだ。
型が省略されていれば、その変数に何が入っているかを別の方法で確信を得なければならない。
推測ではだめだ。推測なんかするから想定外のことが起こったなんて言い訳をすることになる。
型が近くに書いていれば、すぐに確信を得られる。遠くに書いてあれば時間がかかる。
生成する箇所すべてを見なければわからないなら時間がかかるのは当たり前。
小規模だと全体を見る必要があっても時間がかからない。
だが大規模では全体を見ていたらいくら時間があっても足りない。
だから大規模開発では小さい範囲を見るだけで確証を得る手段が必要になる。それも確実な方法で。

36 ：

小規模だと、書く（タイプする）速度が重要になるが、
大規模だと、読む（理解する）速度のほうが重要なんだよね。
文字数はタイプするときには重要なことだが、
読む速度の場合、文字数はほとんど影響がない。
例えばファイル冒頭のimport文とか
どうせ読まないから、いくらあっても
読むスピードには影響しない。

37 ：

こういうコードが読みやすいって？馬鹿なの？

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 ：

ユーザーがプログラマで自分でコードを直せるなら動的型
ユーザーがエンドユーザーで自分でコードを直せないなら静的型

39 ：

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 ：

>>37
それは書き方が汚いだけ。

41 ：

>>39
ファイルの開け閉めなら自動クローズさせればいいよ。
http://d.hatena.ne.jp/argius/20110908/1315486185
あとGooglGuavaも使ってみるといいかな。
com.google.common.io
■Files
http://d.hatena.ne.jp/mtoyoshi/20100725/1280040233

42 ：

Groovyで静的に型指定して書くとこうなるね。
new File("sample.txt").eachLine{ String line ->
　line.trim().split(" ").each{String str -> bag.put(str, bag.get(str)+1)}
}
要するに{ -> }みたいな簡便なクロージャ記法の有無の問題であって静的動的は
あまり関係無いと思う。

43 ：

勝手に>>42付け加えるなら、記述量と読みやすさはあまり関係がない。
確かにクロージャの簡単な書き方がなければ ”書くのは” 面倒になる。
だけどその面倒な部分ってのは、あまり読まなくてもいいところ。
コメントのようなものだと思えばいい。だから読むときにの影響は少ない。
そして書くのは面倒といったが、そういうのは自動生成できることが多い。

44 ：

静的動的は関係ないけど、読みやすさには関係あるよ

45 ：

それはGroovyの静的型がオマケみたいな扱いだからじゃね？
クロージャの型だとか。

46 ：

一般的に、処理コードは読むが、定義コードは読まない。
静的型付け言語で、冗長なのは定義コードの部分であって
処理コードの量は、大差ない。

47 ：

それ、「オレは型なんて読まないぜ、だから静的型でも読みやすいぜ、キリッ」ってこと？

48 ：

型を含めた定義部分は、じっくり読むようなところじゃないってこと。
ちらっと見て、脳の短期記憶領域にさっと入れれば終わり。
もしくは必要なとき見れればいいし、IDE使ってるなら
画面外に定義があっても、簡単に見れるだろう？
時間をかけて読むのは、処理部分ってこと。

49 ：

>>45
Grooby2.0からクラスやメソッド単位で静的な型チェックを強制できるようになった
ので、クロージャの引数や返り値も静的に検証させたり推測させたり出来るよ。
個人的には静的型や動的型のどちらかではなく中間のオプショナルな型付けが好き。
その場合は言語仕様だけではなくライブラリ環境も重要で、言語は静的動的どちらで
かけるにしても、言語の主要なライブラリは特殊なもの以外はバリバリに型情報付きで
提供されている、そんな言語。
ようするに、ActionScript3さいこ〜

50 ：

つかJava由来のinterfaceは糞。
gccのsignatureやgoのinterface法式が普及すれば、
動的型付の需要が減る。
あとAutomated delegationまで使えれば、
敢えて動的型付を使う理由はない。

51 ：

>>50
>敢えて動的型付を使う理由はない。
「おれの土方仕事の範囲内では」が抜けてるぞ。

52 ：

Squeak Smalltalk で書いてみた。
| bag |
bag := Bag new.
FileStream fileNamed: 'sample.txt' do: [:file |
　　[file atEnd] whileFalse: [bag addAll: (file nextLine subStrings: ' ')]
].
^bag valuesAndCounts

53 ：

>>52
Bag使わんで書いたらどうなる？

54 ：

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

55 ：

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 ：

>>52
Smalltalk最近よく見かけるようになったな。良いことだ。

57 ：

>>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 ：

>>55
import しないで書いてみたらどうなるの？

59 ：

突然の Python3 vs Squeak Smalltalk ！

60 ：

>>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 ：

カウンターやBagの類のユーティリティクラスを使ってループを一つ隠さないと結局
どれも複雑になるなぁ。

62 ：

標準添付のライブラリすら使わないという制約下で書かれた>>57>>60と、
標準で付いてこないライブラリを使って書かれた>>39を比べてるのかい？

63 ：

そもそもBagなんざSmalltalkにはプレリリース版(-80 v1)から
組み込みになっているごく基本的なクラスなんだから
後続言語はせめて標準添付ライブラリくらいにはいれておけと

64 ：

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

65 ：

>>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 ：

だって、Smalltalk環境にFileなんてもともと無いし

67 ：

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 ：

Groovy+Guavaで静的型に書くとこんな感じ。
Multiset<String> bag = new HashMultiset<String>()
new File("sample.txt").eachLine{String line -> bag.addAll(line.trim().tokenize(" "))}

69 ：

>>66
おいおい、どこのバカに教わったか知らんが勝手に無くすなよ！ｗ
ファイルの扱いなんざSmalltalk-80の前身のそのまた前身のSmalltalk-72から普通にあるぞ。
http://squab.no-ip.com:8080/collab/uploads/61/smalltalk-72-1977.jpg

70 ：

単に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 ：

>>69
今と同じファイルだっけ？全部シリアライズしたオブジェクトだろ？

72 ：

>.70
Javaで委譲ってかったるい？
こんなに簡単にできるんだけど。
http://blogs.wankuma.com/kazuki/archive/2008/03/23/129171.aspx

73 ：

Eclipseの機能で言語機能じゃねぇし
それに、移譲先が変化しても勝手に委譲されるわけじゃない
かったるすぎる

74 ：

統合開発環境で1000行でも2000行でもスニペットを貼り付けるのは簡単だろうよw
だったら、そのスニペットを自動生成する言語でも使えばいいんじゃね

75 ：

>>72
100種類クラスがあったら100回それするんだろ
コピペファストとか言ってたアレはどうなるんだろうなぁ

76 ：

なんかCOBOLerさんを思い出すわ

77 ：

JavaBeanswww

78 ：

コピペで簡単に出来るっつうなら言語は何でもいいっつうの

79 ：

コピペ最強さんは
プログラムを読む事など
一切想定してないんだろうな

80 ：

う〜ん、アノテーション使ったこういう委譲の方法が、無いわけでもない。
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 ：

やっぱS/N比が低すぎねえか？w

82 ：

ただの慣れだろｗ

83 ：

ソースコードは静的なのに、
型定義を動的にやっても意味は無い。

84 ：

速度が全てじゃないとはいえ、速度も含めたトータルで比較したい
実際の開発だと、パフォーマンスチューニングで工数取られることもあるから

てわけで、某スレのパクリだけど、次の内容で検証して下さい
・モンテカルロ法で円周率計算して値を出力
・実行できる完全なソースコード（他者がベンチマークを検証できるように）
・サンプル数10000000のときの実行時間（実行環境も併記）

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

85 ：

ちなみに、ライブラリの使用はありです。
可読性を上げるために、ライブラリをでっち上げるのもありです。
”ライブラリを除いた部分の” 可読性で勝負をします。

86 ：

>>80
@Delegateってなんぞ
自作の注釈なら実装貼れ
実装不可能なら意味がない

87 ：

実行速度も計るので、架空のライブラリはダメです

88 ：

>>81
どの辺が具体的にノイズだろう? 委譲自体は基本的に次の一行で簡潔していて、Thinという
インターフェイスに定義されたJavaで言うところのメソッドの扱いがthinに委譲されている。
@Delegate private Thin thin;
残りの2行はthinの値の初期化と差分の実装で、>>70の例と一緒。
何を委譲するかはThinというインターフェイスとして静的に定義しているけれども、これは
静的型だから仕方が無いねぇ。これがノイズかと問われると、インターフェイスを定義する
ことで注入する委譲先の型も静的に検証出来るし、FatがThinを実装しているというのも静的
に解るなど、静的型付けなりのメリットが出てくる。
>>83
一応>>80は型定義も静的。

89 ：

>>80
Fat自体がinterfaceなんだからFatが実装になったらいかんぞ

90 ：

>>80
そのFat classを元にして新しいclassを自動生成ってのは
おそらく可能だろうただFat自体にMember関数追加すんのは無理。
机上の空論にもならん。

91 ：

精々JNA的なトコまで実装すんのが精いっぱいだろうな
単に委譲するだけで、新しい処理を追加すんのは無理じゃね

92 ：

>>86
そういう話も出るなと思ってimport文も貼ったんだけれども。これはlombokというライブラリ。
書いたコードもちゃんとコンパイルして動くコードだよ。
http://projectlombok.org/features/index.html
裏側では委譲のためのJavaコードをアノテーションプロセッサで生成している。なので裏側は
>>74の言うところの「スニペットを自動生成」そのものなのであまり見て欲しくはないw
JavaだとDecoratorの類を書きにくいのはその通りで、言語仕様的には>>72のいう大量の
ラッパーコードを使うのがどう考えても素直で静的型検証もきっちり動く。ただこの辺りを
表面的には綺麗に取り繕うことも出来なくはないひとつの例として見てもらえると。
>>89
Fatは委譲のやり方の一例であって、インターフェイスであることは初めから意図していない。
この例だとa()とb()の実装はthinに委譲していて、Fatはc()の実装だけ持っている。

93 ：

>>92
プリプロセス的でも自動で出来るなら別にいいよ
手作業でミスするよりはるかにマシだ
変更の度に他に手が入るのは最悪だから

94 ：

移譲先と移譲元に変更があった場合も再コンパイルせにゃならんの
相変わらずメンドイな

95 ：

>>92
オーバーライドの干渉制御は手作業か。夢はあるけど不便だな。

96 ：

>>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 ：

委譲先に変更があってもインターフェイスが変わらない限り変更があった委譲先だけの
再コンパイルだし、委譲する側に変更があっても委譲先の再コンパイルは必要ないよ。
インターフェイスに変更があった場合は、そのインターフェイスを利用しているクラス
全てに影響が波及する、これは委譲しようがしまいが一緒だね。コンパイルに関しては
Javaでの既存の委譲方法に比べあまり不利はないように思う。
>>95
それはそう思う。今は干渉は静的にチェックされてコンパイル時にエラーで蹴られるので、
委譲するメソッドを列挙したインターフェイス定義を調整する必要がある。
安全と言えば安全だけど、手間はでかい。

98 ：

大規模開発向け(キリッ)

99 ：

>>97
これgenerics対応出来ないよな。
動的型付なら、委譲先のメンバー全て使える。
Javaのやり方だと委譲先のinterfaceに束縛されて、
今のinterface以外は委譲できないだろう。
新しいinterface間同士の委譲が必要になったら、
その都度class作ってSelectorDを書かなきゃならんのか？

100 ：

>>84
Java
http://ideone.com/yEqYUC

101 ：

普通にJavaが最強の件

102 ：

>>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 ：

>>102
ん?やっぱりThin以外に対応できないんだよね

104 ：

重要なの忘れてた。
やっぱり新しいクラス作らないとThin以外に対応できないんだよね

105 ：

>>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 ：

>>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 ：

>>99
それってさ、重要なところは
Javaの場合は、コンパイル時に委譲コードを生成するから委譲は楽にかける。
ただし、インターフェースにないメソッドの追加はできないってことだよね？
前から思ってるんだけど、インターフェースにないメソッドを追加したいってことあるの？
ダックタイピングの例で言えば、「アヒルのように歩き、アヒルのように鳴くのならアヒル」
つまりアヒル は アヒル歩き と アヒル鳴きインターフェースを持っている。
そこにアヒル食いを追加したいってことでしょ？
だったら最初っからインターフェースにアヒル食いを追加しておけばいいと思うんだけど？

108 ：

>>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 ：

>>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 ：

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

111 ：

JFrameにsetTextなんてあったっけ。

112 ：

>>110
それ結論でいいよ

113 ：

>>111
setText付いてんのJFrameじゃなくJLabelだったっけ
まぁ、どっちでも良いよ

114 ：

>>109
> あれのsetTextって動作同じなのにinterface共有してないから
> JTextFieldとJFrameをおなじ関数で処理できないんだ。
それは一長一短でしょ？
今回はたまたま、setTextの動作が同じだったから
そういう結論だけど、setTextの動作が違ったら
別の関数で処理したいはず。

115 ：

>>109
> あれのsetTextって動作同じなのにinterface共有してないから
> JTextFieldとJFrameをおなじ関数で処理できないんだ。かと言ってJTextFieldとJFrameに別のinterface追加したり、
１．オーバーロードを使う。
２．Object型を使う。
３．GenericsでJTextFieldまたはJFrame用の関数を生成する
４．Adapter パターンを使う

116 ：

同じsetTextだからって同じ動作をするとは限らないからねぇ。
例えばインプットフィールドがあったとして、
setTextは、入力文字列の変更でしょ？
で、ラベルがあったとして、
setTextは、表示文字列の変更でしょ？

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

117 ：

実はVB6がこの問題をうまく解決している。
（継承はできないという問題はあるけれど）
setTextをもったインプットフィールド、setTextをもったラベル。
その両方をインターフェース継承した
ラベル付きインプットフィールドを作ることが可能になっている。
この時、ラベル付きインプットフィールドが持っているのは、
setTextという関数ではなく、
inputfield_setText と label_setText という別の名前を持った
二つの(プライベート）関数。
このラベル付きインプットフィールドを
インプットフィールドにキャストして、setTextを呼び出せば
inputfield_setTextが呼び出され、ラベルにキャストしてsetTextを呼び出せば
label_setTextが呼び出されるという仕組み。

118 ：

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 ：

>>115他の言語ならせずに済むそんな事をせにゃならんのがめんどくせぇ。
だから、他の言語だったら、
setTextで動作が違う場合に面倒になるんだよ。

120 ：

ぜんぜんめんどくさくないのに、
なんで面倒くさいって思ってるんだろう？

121 ：

>>119
意味がわかんない。動作が違って困るなら分けて使うだろうし。
多少動作が違おうと構わない場合もいくらでもある。
大体、そこの判断はコンパイラーがするわけじゃなく、
人間が決められることだ。

122 ：

>大体、そこの判断はコンパイラーがするわけじゃなく、
ここは言い方が変か。要するに、誰かに強制されるわけじゃなく
使用者の器量で判断できるってことだ

123 ：

>>120
他の言語ならしなくて済むことを態々書いてんだから
面倒以外の何物でもないぞ
C++ですら回避できる話なのに

124 ：

やっぱり>>110でFA

125 ：

>>124
ALGOLのことだね。

126 ：

>>117
下策じゃん。
text = complexText.TextField
text = complexText.Label
text.Text
こんな風に、PropertyでそれぞれText I/Fにアクセス
出来るようにした方がマシだったろ。
因みにcomplexText.xとcomplexText.TextField.x、
complexText.Label.xの実体は同じ。
Smalltalk的な解決手段。

127 ：

Structual typeはあっても良いけどオマケだなぁ。欲しくなるケースがイマイチ少ない。
とりあえずJLabelとJTextFieldの例では具体例として説得力が弱いのではないかと。

128 ：

>>126
マシじゃないよ。
インターフェース名ってのはsetTextじゃない。
これはインターフェースのフルネームじゃない。
名前空間みたいなものと考えればいいよ。
foo.hoge
bar.hoge
両方共hogeだけど、この二つは同じものじゃないだろう？
foo.setText
bar.setText
これも同じものと考えてはいけない。

129 ：

VB6だと
TextWithLabel text = ラベル付きテキスト
Text t1 = text;
t1.setText(); テキストのsetText()が呼ばれる
Label t2 = text; ラベルのsetText()が呼ばれる
t2.setText()
実にスッキリ

130 ：

単純な話、数の型をしていしてやらなきゃならない高級言語なんてものはカタワだ。
ただしCは除く。Cは高級言語ではないからあれで良い。

131 ：

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

132 ：

>>130
本当にどんな型でも扱えるクラスってのは他のオブジェクトを
格納するだけのコンテナぐらいしかない。たいていは特定の型でしか動かないコードになってる。
人間が型を意識しているのに型を書かないなんてただの手抜きだよ。
例えば valueは何型でしょうか？
function foo(value) {
}
valueには複数の（クラスまたは値）型が入ってくる可能性があるから、
fooを呼び出している所すべてを見ないと型がわからない。
もしくはコードの中身を見て推測（完璧ではない）するしかない。
該当行の遠くを見ないと型がわからなくても、
小規模開発なら遠くといってもたいしたことないので問題無いだろう。
でも大規模だと ”時間がかかる” んだよね。わかる分からないの話じゃない。
テスト通せばいいとかいう話でもない。”時間がかかる” という大きな問題。
valueには何が入るってわざわざコメント書くのなら、型を書いたほうがいいじゃないか。

133 ：

fooを呼び出す側を見に行ってvalueの型を調べる？アホか
お前OOPに向いてないよ

134 ：

で？ お前の意見がなにもないのがいい証拠だな。

135 ：

そうとも言えない。
コンパイラ判断で、文脈から推論して静的型付けできるケースは多い。
つまり、文脈から自明なら、型指定は省略しても構わないと思う。
C++11 の auto や C# の var は秀逸。

136 ：

>>135
autoやvarは関数の引数には使えないでしょ？
あくまでローカル変数。そしてローカルスコープの中には
最低１つは型が書いてある。
つまり方が省略されていても、ローカルスコープだけを
ざっと見れば型がしっかり書いてある状態になるから
それは問題ないんだよ。
問題はスコープが広い所からどう使っているかわからないとか
ローカルスコープであっても、コードの使われ方（呼び出してるメソッドは何か？）を
全部調べなきゃわからないような状態だと
時間がかかる わけさ。

137 ：

function foo(value) {
　value.hoge();
　bar(value);
　value.hage();
}
もしこんなコードがあれば、barの中まで探らなきゃいけない。
さらにbarの中で他の（ｒｙ

138 ：

>>136
ライブラリ側の事を言ってるの？
実装にジェネリクスが使えるなら、使わない理由はないし、
使う方も、ジェネリクスなら型を明示する必要はあまりないと思うよ。
また、できる限りそうあるべきだと、俺は思う。
君の言っているケースでのみも議論するなら、確かにその通りだと思うよ。
型を前提した関数なら、型を明示するべき。
そこに異論は全くない。

139 ：

メソッド名が被るとか、見ても分からないとかナンセンスすぎ
他と被りようがない一意な名前を付ければ良いじゃない
例えば
IterativeDeepeningAlphaBetaSearchUsingKillerMoveOrderingAndTranpositionTableSimpleMaterialAndPositionalEvaluationChooseRandomlyBetweenBestMovesStrategy
みたいなメソッド名や変数名に付ければ、絶対に他と被らないし、型なんて書かなくても一発で分かる

140 ：

>>139
賛成。

141 ：

>>139
満足した？

142 ：

Javaってウンコだね

143 ：

いまさら言うまでもない

144 ：

>>139
で、どんな型なんだよ？
全くわかんねーよw

145 ：

ググったらJavaのコードだったから
Java使いなら分かるんだろう
アホ的に冗長なコードを好むJavaらしい命名だね

146 ：

>>128
setTextの描画先が違う、setTextの結果がバッファリングされる。
それぐらいなら、多態性の一種でしかないけど？
例えば、入力する文字列が、正規表現じゃないといけないとか、
JSON形式じゃないとダメってなら、仕様は異なる。
そういう特異な場合でなければ一緒にしたって問題はない。
それがダメだと思うならJavaに毒されてるし、OOにゃ向いてない。

147 ：

なんだここでも「向いてない」論議か。
もういい加減、OOなんて止めたら。

148 ：

>>146
でもさ、polymorphismが使いこなせなきゃ
関数型言語なんてもっと無理だよ

149 ：

多態性なんて、全く没交渉にOOPは使えるでしょ。同様にそれに相当する
思考なしに、関数型言語も問題なく使えるのではないかな。

150 ：

私は「LISPに帰ろう」。その意は、記号処理の立場から出直そう。
だから、このスレでは最初から外れてますから、無視して結構です。

151 ：

>>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 ：

それでも型があるから大規模開発に耐えられる。

153 ：

Javaは耐えきれずに頻繁にデスマってますがな

154 ：

同じぐらいの人数でやったら
型がない言語のほうがもっとデスマになるね。
所詮人数が少ない時にだけどうにかなる言語。

155 ：

signature方式は静的型チェックが働くぞ
Javaは糞だがな

156 ：

静的型付けだったら何でも良いってわけじゃないんだよ
Javaは糞

157 ：

interfaceがクラスにへばりついてるってやり方が最早古い。
C++や.Net系言語でもtemplateやDynamicその他の拡張で
徐々に分離可能になってきてるがJavaは未だ改善の兆候がない。
尤もVMに縛られてるから不可能なんだろうがな。

158 ：

Java厨はコードに密結合を生むのが好きなんだよ

159 ：

動的型付け言語にインターフェースが
ないと思ってるの？
コンパイラが認識できないだけで、
人間はインターフェースを認識してるんだよ。
メソッドが必要というインターフェースをね。

160 ：

動的型付け言語だって処理系は型を認識してるだろ
型チェックが走るのが実行時ってだけの話だ
一度もテストで実行しないコードをリリースしちゃうような
お粗末な現場でもなければ問題にならん

161 ：

>>160
実行時に型チェックするぐらいなら
実行前に型チェックすればいいじゃないか。
実行時だと全パターンチェックしないとわからないんだぞ。
2の何十乗パターンが有ると思ってるんだ？

162 ：

>>161
ぷ

163 ：

>>161みたいなのが、xUnitも通らない、ビルドで警告たっぷり吐き出される、ただコンパイラが通っただけのバグまみれのコードをコミットするんだな。

164 ：

オプショナルな型付けとか型アノテーションってどうなの。
動的型付け言語を使っている人にとっては融通さをスポイルするので邪道なのかな。

165 ：

別にいいんじゃね？
でも、Strongtalkでもう決着ついたことだと思ってるけど。

166 ：

dartやhaxeみたいなベターJavaScriptの中にもオプショナルな型付けの言語があるよね。

167 ：

型とかあんま難しく考えなくていいんだよ。
あんなのコメントと一緒。
この変数や引数には○○なオブジェクトが
入りますっていうコメント。
数学的計算をするのなら、数値型が入るって書くだろうし、
日数計算するなら、日付型が入るって書くだろうし、
showとhideメソッドを呼び出しているのなら、
showとhideインターフェース型が入るって書くだろう。
型っていうのは、コメントを書く代わりに
コンピュータが解釈して、簡単なミスを検出してくれる
便利なものって考えればいいよ。
コンピュータがなくても小さなものなら
人力でもなんとかなる。その程度のものだよ。

168 ：

Java使いらしい意見だな
頭悪そう

169 ：

型付けの静的/動的なんて難しく考えなくていいんだよ
静的だろうが動的だろうが、いずれにしろ処理系による型チェックは走る
むしろ型の強さの方が重要

170 ：

>>169
型チェックが走るかどうかが問題なのではなくて、
それがいつ走るかが問題なのでは？
いずれ走るのであれば、型チェックはやっぱり
必要ということだろう？

171 ：

>>168
何か内容に問題がある？

172 ：

>>170
型チェックはそれだけではテストとして不十分なので
自動テストを走らせる必要がある
どうせ自動テストは走らせるんだから、
型チェックが行われるのがコンパイル時でも
自動テストのときでも変わらん

173 ：

テスト走らせるまで書き損じに気づけないというのも不便な話ですね。
型に厳格な言語と賢いIDEであれば書いている最中に凡ミスは随時指摘されるのに。
テストするにしてもオールグリーンになるまでの手戻りの手間は違ってくる。

174 ：

>>172
自動テストって自分で書かないといけないものってわかってないのかな？
自分で書く以上、ミスは生じるものだよね。
自動テストは不完全なものなわけで、
実行すれば、型チェックが終わるってなんで思うの？

175 ：

動的型でもタイポくらいは気付けるよ、最近のIDEをなめちゃいかん

176 ：

>>174
型チェックは不完全なものなので、型だけ厳密でも意味ないんだわ
まあ、RDBからデータ引っ張って来てHTMLに流し込む程度の
ドカタシステムなら別だけど

177 ：

テストってのは仕様とあっているかを調べるもの。
だから仕様と違っていたとしても、プログラムは動く。
動くから、人間がテストを書かないといけない。
でも、型チェックというのは、仕様とは無関係。
コーディングミスなので、間違っていれば動かない。
仕様と合っているかを調べるテストと
書き損じを調べるチェックは本質的に違うもの。
書き損じのチェックのためにテストを流すのは
間違ったやり方。

178 ：

>>175
見つけられるタイポがあるだけ。
メソッドやプロパティのタイポは見つけられない。

179 ：

>>176
> 型チェックは不完全なものなので、型だけ厳密でも意味ないんだわ
いや、当たり前だろ。
そもそも、書き損じのチェックは
仕様確認のテストではない。
コンパイルチェックと、テストは
本質的にやってることが違う。
お前が言ってるのは、統合テストがあれば
単体テストは不要と言ってるのと同じ事だよ。

180 ：

>>175
IDEであっても動的言語相手だと補完や修正の打率が全然違う。

181 ：

>>180
どんなIDEを使ったことあるの？Smalltalkは？

182 ：

コンパイルチェックをテストだと思うからダメなんだわ。
C言語でプログラミングしていた時代の人なら、
コンパイルに通ってからが、テスト開始だってわかってるはず。
「コンパイルに通ったのでバグはない」という
勘違い超初心者はいたらしいけど。

183 ：

テスト工程の前段階が存在するということに気づけば、
前段階であるコンパイルチェックを
テスト工程に持ち越す愚かさが理解できるだろう。

184 ：

>>181
今となってはろくに使われない言語の特定実装の話をしてもらっても理屈倒れでクソほどの役にも
立たないので、今日広く使われている動的言語での話をしてくれないかな。

185 ：

>>183
REPLで実行しながらコード書いてるから、
型チェックどころか振舞いまで
その場で確認しがららコーディングしてるよ
え？テストまで振舞いも確認できないの？遅れてるー

186 ：

前段階工程 → 単体テスト工程 →統合テスト工程

簡単に図式化してみた。
前段階工程でやれることを単体テスト工程に持ち越すことは
単体テスト工程でやれることを統合テスト工程に持ち越すのと同じ事。
統合テスト工程があれば単体テストは不要ですよ？理屈上はね。
本当にそう思いますか？

187 ：

うん。やっぱり静的型で厳密に型チェックすべきだよな。
だから静的型付け関数型言語の時代だよ。

188 ：

>>184
は？Smalltalkが現在使われてないとでも？

189 ：

使われてないとは言っていないが、
殆ど使われてないというのはあってるな。

190 ：

>>185
それ実際にやればわかるけど、面倒くさすぎ。
いちいち止めて再実行しないといけない。
テスト以前に開発に時間がかかる。
動かさないでさっさと書いたほうが速い。

191 ：

>>190
いちいち止めて再実行www
REPL使った事ないの？

192 ：

>>191
間違ってコードを実行してしまった時、
どうしますか？

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

193 ：

>>192
ほんとに知らなかったwww
ブレークポイントwww

194 ：

使った事無いから
いま必死にREPLを調べてます

195 ：

>>187
中身は関数型でも動的型でも何でも良い。ただライブラリを書く人間は外面のAPIはちゃんと
型付きで厳格な形で提供して欲しい。
そうすれば自分は型付きのメリットを享受しつつ手を抜きたいところや融通を効かせたいところ
は型無しで書くから。オプショナルな静的型付き動的型言語さいこ〜。
つまるところ、静的言語・動的言語・オプショナルな静的型付き動的型言語・関数型言語が
一通り揃っていてまぜこぜで使えるJVMファミリーは便利。

196 ：

ユニットテストっていうのは、間違いを見つけるのは簡単だけど、
その間違いを修正するデバッグ行為は楽ではないんだよ。
不具合の原因を追求するってことだからね。
ただの書き損じのために、わざわざデバッグ作業を始めるなんて
馬鹿だと思わないかね？時間の無駄だとは思わないかね？
書き損じはテストを書かなくても、コンパイラが知らせてくれるような
いいような簡単なミスなのに。

197 ：

>>193
どう？ 反論する方法は思いついた？

198 ：

>>194
http://shirusu-ni-tarazu.hatenablog.jp/entry/2012/06/24/051114
pry-nav
pry-navというgemを使うと、
デバッグ実行するための以下のコマンドが使えるようになります。

199 ：

>>197
え？ブレークポイントの話題を引っ張ってほしいの？
Java厨はREPL使った事無くて、
デバッガで実行するのとREPLの区別付かないんだなーってだけでしょ？

200 ：

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

201 ：

http://labs.timedia.co.jp/2011/12/rubyist-should-use-pry.html
簡易デバッガとして使う
Rubyのコードを書いていてある程度の量になってくると、個々のモジュール
はRSpecによるユニットテストにがっちり守られていても、やはり、
ソフトウェアを開発する以上デバッガの恩恵を受けたいものです。
往々にして、個々のモジュールを結合したときに、予想できなかった問題が発生するものだからです。
原因をすばやく追及するために、デバッガはプログラマにとって必要不可欠なツールでしょう。
実は、Pryの真の機能はREPLではなく、この先ほどのオブジェクトの調査機能にあるようにデバッガとしての機能によるものが多いです。

202 ：

>>195
ここ最近はずっと、個々の言語が生産性で競うというより、
Javaを筆頭とするJVMファミリーと
C#を筆頭とする.netファミリーと
C/C++を基盤とするUNIXファミリーの戦いになっている

203 ：

どうでもいいけど、ソフトウェアの開発っていうのは
0から作ることはほとんどなくて、
既存の何かの修正なんだよね。
それを本能で理解しているかどうかで、あぁこいつ
ちゃんとした開発やったこと無いな。
サンプル程度のやつを0から書いてみただけだなってことがわかる。

204 ：

どうでもいいけど、Javaドカタの言う「ちゃんとした開発」ってのは
ネットからサンプルコードをコピってきて
フレームワークの穴埋めするだけなんだよね
普通の開発者とは議論が噛み合ないから、あぁこいつ
Javaドカタだなってことがわかる。

205 ：

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

206 ：

>>204
って思いたいんでしょ？ｗ

207 ：

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

テストは型誤りを見つけるもので
型誤りがないことを示すものじゃないってのは常識
静的型付け言語のコンパイルチェックは、型誤りがないことを示すもの。

208 ：

>>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 ：

>>205
> そしてSmalltalkはどこのファミリーに入れてあげれば良いのだ?
どこにも入らないから、しばしば議論に入ってきてるけど場違い感がハンパない

210 ：

>>178
え？今時メソッドのタイポも見つけられないIDEがあるの？
具体的に挙げてみてよ

211 ：

>>209
ドカタ言語じゃないから、>>202にあるようなファミリーには分類しにくいねw

212 ：

Smalltalkはドカタ言語じゃないけど、それが理由で>>195に分類できないんじゃない
jvmや.netやunixと並ぶ環境だから

213 ：

間違えた>>202だった

214 ：

SmalltalkはJVMや.NET、UNIX等の
エコシステムから取り残された箱庭言語
後発の言語が「あえて」環境を抱え込まず
エコシステムの一部になる方針を取っているのに、
Smalltalk使いはSmalltalkが特別な言語だから環境とセットになっていると思ってる
そりゃマイナー言語ですわ

215 ：

>>210
引数のオブジェクトが持つメソッドのタイポとかも見つけてくれるの？

216 ：

具体的なIDEの名前が聞きたいだけだろ？
動的型付け言語でIDEなんてないから
でてこないと踏んでIDEの名前を聞いたってところだろう。

217 ：

>>208
ただ最近は意識しないで使っていたライブラリもソース引っ張ってきて開けてみればscala
でしたってパターンも多い。
使う分には何で書かれているのか全然気にしなくて良いのは楽。mavenのおかげで多言語混在
のプロジェクトも気兼ねなく配布出来るし。

218 ：

社内のサイドワークでJavaとPython、それとErlangで共有する実装をCで書く部分を
担当しているのでEclipseにPDTを入れているけど、頑張っているとはいえやはりJDTには
届かないなぁ。

219 ：

>>218
PythonでEclipse + PDTってどういうこと？

220 ：

>>219
ん、ごめん。PyDevだっけ。Python用のプラグインとしか認識していなかったので名前ど忘れ
していた。PDTはPHPか。

221 ：

>>220
PyDevってJDTと比較しようかと思うくらいには頑張ってるんだ。
ちょっと興味出てきた。どの辺が頑張ってた？

222 ：

ないよりはマシぐらい程度は頑張ってたな。

223 ：

なんだ。使った事がないから、具体的なことには答えられません、ってか。
せっかく話のネタになりそうだったのに。

224 ：

>>223
う〜んとね。何に驚いたかというと言語混在モジュールので(あとメインの担当は
Javaなので)Eclipse上にプロジェクト作ってJava、C、Pythonと全部突っ込んで
開発したのだけれども(Erlangは他の人の担当)、言い方は悪いけれども普通に
使えたのに驚いた。
Eclipse上のJavaの開発と同様に補完もビシバシ効くし、代入時の行を見て型もある
程度推測してくれる。名前変更程度のリファクタリングも小さいプロジェクト内で
あれば実用的な範囲で出来る。
あとデバッガもJava他のその他の言語と全く同じUIで出来るのは何気に助かったな。
このPython開発はあくまでサイドワークなので他にPython向けの良い開発環境が
あるのかは知らないけれども、Eclipse使いで多言語を同時に扱うのであれば凄く
便利だと思った > PyDev

225 ：

> 代入時の行を見て型もある
> 程度推測してくれる。名前変更程度のリファクタリングも小さいプロジェクト内で
> あれば実用的な範囲で出来る。
それってローカルスコープ限定の機能でしょ？

226 ：

>>225
当然レキシカルに特定できる範囲に限られるけれどもローカルスコープに限らないよ。

227 ：

まあ、それにPythonってあんまりOO全開じゃなくて
総称関数ベースの手続き型（ちょっと関数型風味もあり）な言語なので
importの補完とモジュール名.関数名の補完が効くだけで十分だったりもする
もちろんレキシカルに特定できるならメソッドも補完できるが

228 ：

>>226
ローカルでもレキシカルでもいいけど、
範囲が狭いなら、それは人力でもなんとかなるんだよね。
問題は広い範囲。
コードを見るだけじゃ、影響範囲が把握できない。って状態が
一番大変で、そこを一番にコンピュータ化したいんだよ。

229 ：

>>228
ローカルでもレキシカルでもどっちでもいいって、ホントにプログラマの発言かよ。
広い範囲ってのは、具体的に何を指してる？

230 ：

>>229
普通にローカル・レキシカルよりも広いスコープでしょ？
分かりやすく言うのなら、修正対象のファイル以外。
修正対象のファイルだけ見ればいいのなら、修正は楽だけど、
修正対象のファイル外に、影響を及ぼすものは修正が大変だよ。
例えばパブリックメソッド名を変えたら、そのファイル外に影響をおよぼすでしょ？
だからそれをコンピュータの力で楽をしたいと思うわけ。
人力でもできることは、人力でもいい。
人力じゃ大変な所を、コンピュータにやらせなきゃ。
そういう発想。大事だよ。

231 ：

>>230
レキシカルスコープの対比がファイルスコープかよ。
馬鹿すぎて卒倒しそうだわ。
で、ファイルが違ってもレキシカルに特定できるなら問題ないけど、何か？

232 ：

>>229
> ローカルでもレキシカルでもどっちでもいいって、ホントにプログラマの発言かよ。
お前日本語がわからないんじゃね？
この場合は、ローカルとレキシカルの区別は付けなくてもいいとかいう話じゃなくて、
スコープが広い方が影響範囲が大変という話において、
ローカルとレキシカルはどっちも影響範囲は狭いから、
どっちでも大した違いがないって意味だろ。

233 ：

>>231
> で、ファイルが違ってもレキシカルに特定できるなら問題ないけど、何か？
ファイルが違っていてレキシカルに特定できる場合って？
具体的なコードでお願い。どの言語でもいいよ。

234 ：

>>232>>233
ヒントあげるよ
レキシカルスコープ/ダイナミックスコープ
スコープの広さはぜーんぜん関係ありませーん

235 ：

>>234
そんなこと知ってる。
その上で、お前がちゃんと答えを出せるか聞いてる。

236 ：

> ローカルでもレキシカルでもいいけど、
> 範囲が狭いなら、それは人力でもなんとかなるんだよね。
> 普通にローカル・レキシカルよりも広いスコープでしょ？
> 分かりやすく言うのなら、修正対象のファイル以外。
> ローカルとレキシカルはどっちも影響範囲は狭いから、

こんだけ馬鹿さらしておきながら
>> スコープの広さはぜーんぜん関係ありませーん
> そんなこと知ってる。
いやー、そりゃ無理すぎでしょ。3アウトですよ。

237 ：

Pythonの補完の話になんでいきなりダイナミックスコープが出てくるんだよ。
始末に負えない馬鹿だなこりゃ。

238 ：

バカというか単にレキシカルの意味がわかっていないだけでしょ。
228あたりでそんな雰囲気は漂っているが230で確定、以降は単に弄って遊ばれている。

239 ：

で、さっさと違うファイルでも
レキシカルに特定できる
言語いったら？ｗ

240 ：

むしろ出来ない言語を挙げてくれ。

241 ：

Ruby、PHP、Perlあたりだな。

242 ：

レキシカルスコープすら理解せずに型付けの議論をしてたのか、このアホは…

243 ：

ファイルが違うとレキシカルに特定できないってことは、
クロージャの中で別ファイルの変数/関数を参照したり、
生成したクロージャを別ファイルの中で利用したり出来ないってことか。
すげーな。そんな言語見た事ねぇ。

244 ：

静的有効範囲( 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 ：

ちなみに、LexicalのLexとはLexerのLexと同じ。
構文を意味する。つまり構文に基づく有効範囲という意味になる。

246 ：

動的な局所変数なんて概念存在すんだろうか

247 ：

>>225
で、君が主張するレキシカルには分析できないような、静的型付けでしか不可能な補間機能というのを説明してくれたまい。

248 ：

>>247
そもそもなんで、ローカルスコープの話に
レキシカルが出てくるの？

249 ：

>>248
>>225へのレスが>>226だから

250 ：

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

251 ：

いやー、たぶん>>230は
静的型付けならファイルを超えてレキシカルな構造を特定できるが
動的型付けだと無理だ、と言いたかったんだと思うよ
なんでそんな発想に至ったのか理解不能だけどwww

252 ：

>>250
普通にできるけど？あほ？
動的型のマトモな環境使ったことないの？

253 ：

ファイル超えたって
普通にモジュール化とimport機能がある言語なら
普通に補完もタイポ検出も可能だよなー

254 ：

>>252
foo(KURASU1)
foo(KURASU2)
KURASU1にはhogeがあるが
KURASU2にはhogeがない
void foo(kurasu) {
　kurasu.hoge(); ← 何型かわからないから補完できない。
}

255 ：

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

256 ：

つまり、動的型付け言語の、コード補完には
信頼性がない。

257 ：

動的言語の場合、補完というより候補だしてるだけだからね。
その候補以外でもコンパイルに通ってしまう。
実行時じゃないと本当にエラーにすべきかどうかわからない。

258 ：

>>214
環境と独立したSmalltalk言語なんていくらでもあるんですがね。
GNU Smalltalk然り、Dolphin然り、VistaSmalltalk(#Smalltalk)然り、Redline Smalltalk然り。

259 ：

>>254
普通にできるけど？あほ？
動的型のマトモな環境使ったことないの？

260 ：

>>259
じゃあやってみせてよｗ
ちなみに、fooの呼び出しは
fooの定義のレキシカルスコープ外に
あるものとします

261 ：

>>256
ばか？
コード補完に信頼性がないんじゃなくて
実際言語仕様的にそういうコードがvalidであり得るのだが？
これから君のことはKURASU君と読んであげよう。よかったね。

262 ：

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

263 ：

くっそ何も反論できない。
こうなったら！
動的型のマトモな環境使ったことないの？
（そんなの無いけどねｗ）

264 ：

>>260の神聖あほっぷりに世界が沸いたw

265 ：

>>262
それテンプレートじゃんｗ
マクロのようなものと考えればいい。
マクロがコード補完とか意味わからん。
マクロを使った時にコード補完されるから問題ないんだよ。

266 ：

>>263
くやしいねえ、KURASUくんww

267 ：

まさに>>263が正解って感じがしてきたなｗ

268 ：

やってみせられないことが
全てを物語っているよな。

269 ：

やってみせられないって…どうやって見せるの？
KURASU君みたいにアホ丸出しのコードをここに書き込んで
何かの証明になるとでも思ってるの？ばかなの？あほなの？

270 ：

ていうか、ここのKURASU君（良い名前だw）に
動的型言語でinvalidなコードを書いてみて貰ったら良いんじゃないか？
なお、invalidってのは処理系にとって未定義な振舞いで、例えばseg faultするようなヤツな

271 ：

> 動的型のマトモな環境使ったことないの？
ふいたｗ
動的型にまともな環境無いじゃん。
いつもテキストエディタで書いてるじゃん
Smalltalkだけは例外でいいよ。
あれはIDEと実行環境が一体化した変な世界だから。
それ以外の動的型言語にまともな環境はない。
あるなら知りたいくらいだ。
いい加減テキストエディタの開発やめたいんだよね。

272 ：

-(void)withString:(*NSString) value // 動的型付
{
　　puts( [value UTF8String] );//補完できる
}
template<class Type> void Example( const Type &value ) // 静的型付
{
　　　value.Function(); //補完できない
}

273 ：

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

274 ：

>>273
じゃあ、お前の定義は？

275 ：

>>265
詭弁だねぇ

276 ：

PyDev も Python tools for Visual Studio も vim (+ipython) も
環境込みで動いてる

277 ：

>>265
>マクロを使った時にコード補完されるから問題ないんだよ。
意味がさっぱり判らん。もっと人間に優しく説明しておくれ

278 ：

俺にとってinvalidというのは、実行時に必ず
想定外の動作をするコードだな。

279 ：

>>271
で、Smalltalk環境でできることが他の動的言語ではできない理由は？
ちなみにKURASU君が大好きそうなEclipseもSmalltalk由来だから
Smalltalkで作った環境がノーカウントだとするとEclipseもノーカウントだぞw

280 ：

>>273
違うというなら無効(invalid)以外の言葉で条件を定義したら？
異常終了とか。

281 ：

>>277
テンプレートってのは雛形。
コードそのものではなく、
コード生成機
コード生成器 → コード生成 → コンパイル
こういう流れだから、コード生成した時に
検出できるので問題ないという話。

282 ：

>>278
それって言語仕様や処理系にとって想定外ってことだよね
まさか言語がエスパーして人間の想定を考慮するはずないもんね

283 ：

>>278
「想定外」なんていう脳内仕様を要求する基準を持ち出す時点でアウトだなw

284 ：

>>281
補完の話してたろ都合よくすり替えるなよ

285 ：

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

286 ：

かぶったw
まあ健康な脳を持つプログラマなら普通に気付く間違いだがw

287 ：

じゃあinvalidの定義「バグ、コードを修正することでしか、直せない問題。」でどうだ？

288 ：

>>279
Objective-CとXcodeなら出来るぞ。

289 ：

>>285
つまりKURASU君の主張を裏付けるためには悪魔の証明が必要だと。
なんていい加減な主張をするんだろうね、KURASU君はw
「まともな環境はない」と断言したからには、ちゃんと理由を示せよww

290 ：

ほう、できるというのなら、
その証拠を出すんだ。
今なら勝てるぞ！

291 ：

悪魔の証明どころか、れっきとした反例が出ちゃったね、KURASU君w

292 ：

>>289
いや、無いの証明をするのは難しいっていうのが
悪魔の証明ってやつだから。
そんなのを要求するほうが頭が悪いで話は終わるんだよ。

293 ：

>>287
いい加減Engrishみたいに横文字に執着すんのやめたら気持ち悪い

294 ：

>>290
Objective-CとXcodeなら[NSString s]と打ち込んだ所で、NStringの
selector一覧が出る。

295 ：

なんか勘違いして勝ったつもりの奴がいるが、
http://ja.wikipedia.org/wiki/Objective-C
弱い静的型付け
^^^^^^^^^^^^^^^^^
だぞ？

296 ：

>>295
落ちにワロタｗ

297 ：

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 ：

>>295
バラすなよ。
せっかくいい感じで
釣れたのにｗ

299 ：

>>295
Objective-CのCの部分は弱い静的型付けだが、
OO部分は完全にSmalltalk由来の動的型付けだ

300 ：

>>299
だからこういうことになるわけですね
http://ponpoko1968.hatenablog.com/entry/20101030/1288395400
> 実は、どうやら最新のバージョン2.8においても、objective-cの
> クラスやメソッドを認識する機能が実装されていないようで、
> C言語の関数しか補完候補に現れません。

301 ：

>>295
うんにゃそれはWikipediaの定義でしかないし、
Cの側面からみた定義でしかない。
あんたらの問題視している範囲から言えば動的型付言語だ。
じゃなにかい？Objective-Cも静的型付言語だから、
静的型付言語も実行時に型異常を起こすから危険って事でいいのかい？

302 ：

Objective-Cは静的型付け言語です。

303 ：

>>301
その下読んだ？
> 2010/11/1補記：
> どうやらobjective-Cクラス/メソッドも認識しているようです。

304 ：

>>300
もうXcodeは4.x時代ですが、時空の間に取り残された人ですか？

305 ：

つーか、型定義がある時点で静的型付けでしょ？
いや、正確にはNSStringみたいな型定義がないと
補完できないわけでしょ？

306 ：

KURASU君が必死にググって対抗しようとしてるのが笑える

307 ：

これってつまり、動的型付け言語で補完したいなら
静的型付けと同じような、型定義が必要って話になってるんじゃね？

308 ：

http://en.wikipedia.org/wiki/Objective-C#Dynamic_typing

309 ：

>>305
> つーか、型定義がある時点で静的型付けでしょ？
馬鹿すぎ

310 ：

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

311 ：

で、Java厨は>>297をかたくなに無視してんのはなんでだ？

312 ：

-(void)withString:(*NSString) value // 動的型付
{
　　puts( [value UTF8String] );//補完できる
}
template<class Type> void Example( const Type &value ) // 静的型付
{
　　　value.Function(); //補完できない
}

313 ：

>>311
Java厨が忌み嫌うエディタで出来るなんて我慢できないから

314 ：

そもそも、動的型付ならMethodが存在しなくても正常に実行できるんだけどな。
そういう事が出来ない時点で、静的型付というか(というと失礼なので)Javaは糞だよ。

315 ：

動的型付け言語でも型定義があれば補完できる。
型定義の重要性を再認識することになった。

316 ：

そうだね。でもそれは、静的、動的の問題じゃないね。スレ違いだね。

317 ：

>>314
それは仕様通りに動くという意味じゃないだろう？
バグが有っても、バグと認識できずに動いてしまうという話だよね？

318 ：

>>316
別スレってことは
別のスレを立てろって言ってるのかい？

319 ：

>>318
建てたければ立てればいいんじゃないの？

320 ：

ActiveRecordすら知らないと来た
いや、名前は聞いたことあるけど仕組みは理解できてない、か

321 ：

>>317
NULL objectとかListener objectとかProxy objectとか仕様通りですけど。

322 ：

>>318
スレタイは「レキシカルスコープも型付けも分かりません、助けて！」に決定

323 ：

>>320
Active Recordというよりメッセージ転送の話だよ

324 ：

こんなかんじでどうだ？
「型定義の重要性 〜 コーディングミス解決,補完,etc」
本質的ではないバグに翻弄される人々
タイプミスにどんだけ時間奪われたか計算してみ？
動的型付け言語であっても、型定義があることで
さまざまな問題を解決出来ます。
Objective-Cは定義が存在する動的型付け言語の一つです。

325 ：

>>321
NULL objectとかListener objectとかProxy object 以外では
仕様通りじゃないということですか？

326 ：

>>324
いいねそれｗ
それでいこう。

327 ：

>>323
そんなの実用的じゃないって返されないように有名な適用例をあげてみた

328 ：

型定義が存在しない言語となると、
javascriptとself、shell scriptぐらいか。
はようたててこい

329 ：

>>325
鳥でなければ空は飛べないのですか？

330 ：

Active Recordは設計がおかしい。
ModelとActive Recordはis-a関係でないのに
Active Recordを継承してModelを作っている。
実用されているが、間違った例だ。

331 ：

>>328
LazyKも入れよう

332 ：

型定義というのは
変数にって意味だろ？

333 ：

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

334 ：

変数に型定義がないっていうのは
Class1 a; みたいなのはなくて全て
var a; みたいになっているもののことか？
それなら結構有りそうだな。
PHP、Perlあたりとか。

335 ：

>>332
お前だけなんか色々言葉の定義がおかしいわ。
学生もしくは発達障害か？

336 ：

>>333
Active Record設計者も
設計がおかしいことに気づいて
直そうとしているみたいだけど？

337 ：

そういうのは型注釈という

338 ：

>>336
Active Record知らんけど、ソースくれ。

339 ：

おR

340 ：

>>334
template<class Type> void Example( const Type &value ) // 静的型付
{
　　　value.Function(); //補完できない
}
これどうなるんだろうな

341 ：

>>340
それテンプレートだから関係ない話じゃない？

342 ：

>>336
メッセージ転送を使うところは一緒
Ruby的には継承よりmixinのほうが良いよねーってだけ

343 ：

>>330
確かに、ModelとActive Recordの関係はおかしいかもな。
Smalltalkなんか、Objectの派生は全てModelとして動作するし。
まぁ、Active Recordが悪いって話にはならんわ。
Model設計のもんだいだ。

344 ：

>>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
いや楽しいねｗ
Plain Old Java Object 通称POJO に
やっとたどり着いたって感じだ。

345 ：

>>341
あえてtemplateが除外される理由はない。
奴らにとって問題の焦点は補完出来るかどうかが全てだからな。

346 ：

テンプレートも具体的な型を使えば
補完されると思うけど？

347 ：

>>344
結局Modelの問題で、Active Recordの問題じゃないんだろ。
>>330 をよく読まず突っついたのが悪かったが、
別にメッセージ転送云々の問題じゃないから、>>330 の話は
無視しときゃよかったんだよな。

348 ：

>>338
これまでこう書いてたのを
class Foo < ActiveRecord::Base
end
こう書こうってだけ（こうすれば単一継承のRubyでもFooがActiveRecord以外を継承できる）
class Foo
  include ActiveRecord::Model
end

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

349 ：

>>340
JavaのGenericsなら、そのvalueはただのTypeじゃなくて
「Functionメソッドを持ったクラスを継承したType」って
書くんだけど、C++ではそういうこと出来ないの？

350 ：

>>349
継承している必要がないからな

351 ：

>>346
具体的な型を指定しない場合の話してるんだろ

352 ：

>>350
でもvalueはFunctionを持っている必要が有ることは
コードをみれば明らかじゃん？
ならvalueはFunctionメソッドを持ったインターフェースを
継承している必要があるじゃん。

353 ：

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

354 ：

>>348
こう書こうってだけで終わらないことを祈るよ。
include ActiveRecord::Modelで追加されたメソッドは
原則としてプライベートメソッドとして扱うべき。
継承じゃないんだから。
そこにみんな気づくといいんだがね。

355 ：

>>353
Java脳が嫌いなら、valueはFunctionメソッドを
持っている必要があるって言い換えてもいいけど？

356 ：

valueがFunction関数を必要とするかは、
value.Function()と書いたか、書かなかったかで決まる。
必要かどうか決めるのは、Example関数自身なんだよ。

357 ：

>>354
気づけばいいね。Rubyスレに殴りこんで議論してきたら？
歓迎してくれるよ。きっと。

358 ：

いい話よのう。まるで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 ：

スレ違いだからRubyスレでやってこい

360 ：

俺は、private関数なんて使ったことないわ。
privateなMethodなんて存在意義を感じないし。
大半の言語じゃ存在しないから必要性も全然感じない。

361 ：

ほら、>>360を見て、馬鹿か釣りですよ？

362 ：

Member関数方式じゃなくMessage&Method方式で敢えて、
privateな処理が欲しけりゃBlockやLambda使えばいいしなぁ。

363 ：

Java厨が早速反応している

364 ：

お前が反応したｗ

365 ：

結局、Javaと同じ言語仕様が正解で
Javaと違うのは間違い、と言いたいんだろう？
だって静的型・動的型に関わらず、Javaと違う仕様には
全部噛み付いてるからね

366 ：

そもそもこのスレってずっとJava厨vs他だろ

367 ：

>>358
Javaは素の状態で委譲が簡単にできないから、
継承多様しまくりだよな。
Message方式の言語ならMessage転送で済むから、
ある種の委譲目的以外では継承する必要が無い。

368 ：

まぁなんだAutometed Delegationや、Duck Type、Message Forward。
これらが出来ない所でJavaの生産性は糞低い。ここは覆しようがない。

369 ：

>>292
証明できないような主張をするほうが馬鹿w

370 ：

>>368
それらができることと、
生産性が結びつかないんだけど？

371 ：

不要なものを書かなければ生産性は上がるのは当然。
そんな事もわからないの？

372 ：

interfaceを10分考えている間に他の作業が出来る。
それだけで十分生産性が上がる。

373 ：

>>371
> 不要なものを書かなければ生産性は上がるのは当然。
言い換えると、必要な物を書けば生産性は上がるってことになるんだけど。

374 ：

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

375 ：

コードを書く時間よりも理解する時間のほうが
大幅にかかるのであれば、
このメソッドを呼び出しているのはどこだー？と
ソースコード全体をくまなく調べあげるよりも
さくっと一覧表示させたほうが開発効率は良くなる。

376 ：

>>373
言い換えになってない
不要なものを書かなければ→元は不要なものがあった
必要なものを書けば→足りないものを足した
国語から学び直せ

377 ：

>>376
まず「不要」の定義をしろよ。

378 ：

面倒なんで先読みしてレスするわｗ
それは、なくても出来るというだけで、
ないほうが生産性上がるの根拠になってないだろ。
例えば、自転車はなくてもたどり着ける。
だが、自転車があったほうが速くたどり着ける。
足のほうが柔軟性はあるがね。

379 ：

>>374
Graphviz使うような場面だから、静的型動的型関係ねぇなぁ
逆に大量のinterfaceや、AdapterやProxyのためだけに大量に生成したコードは
Graphivizなんか使った時の可読性を下げる。

380 ：

>>377
その他の言語なら書かなくて済んだコード。

381 ：

>>118がいい例だよな

382 ：

JLabelとJTextFieldのメソッドが名寄せできる程度で生産性云々を誇られても。
JLabelとJTextFieldに関してはそもそも名寄せが必要な場面って殆ど無いし。
こんなことが出来るぜと誇る割には出てくる具体例にあまり有り難みがない。
必要も無い例をネタに言語機能を誇ったところで空しいだけだよね。

383 ：

ああ、KURASU君、きみはOO での多態の意味がまるでわかってないんだね

384 ：

敵は皆同一人物病発病か。

385 ：

え、あんな馬鹿が何人もいるの？
そらすげえな()

386 ：

>>385
お前もその馬鹿だろ
見え見えだって

387 ：

>>382
JavaでMVCやりたくなったらそれしか無いだろw
Javaならな。

388 ：

gdgd化作戦成功してよかったねKURASU君

389 ：

>>387
なんで、その他の方法ができないと思った？
お前がやろうとしていることは、全てできると思って間違いないよ。

390 ：

MVCと多態に何の関係があるんだ？
最低限メッセージ送る仕組みさえ作れば出来るんだが。

391 ：

>>388
よくわからんが、成功組と
失敗組がはっきりしたのか？

392 ：

>>389
じゃやり方示してみな。できるもんならなlol

393 ：

>>390
関係ないよ。単にMVCを簡潔に書けるかどうかっつう話しだし。

394 ：

コードジェネレーター作ればいいだけなので
Javaでも簡潔に書ける。

395 ：

JLabelとかJTextFieldはViewの実装の詳細であってMCとの通信とは何の関係もないわな。
MVC持ち出す時点でなんか勘違いしているか時代遅れの筋の悪い作法しか知らないのでは。

396 ：

MVCは継承しないと出来ないって
Rubyの神様が言ってたんだとさ

397 ：

古かろうがなんだろうが作る作れるよな。(最新はMorphicだが)
古いものすら作れないの？
結局Duck Typeが使える言語なら簡単にできる古典的様式が
Java単体じゃ簡単にできない事が判明したわけだ。

398 ：

>>394
Javaなど人間が読み書きするに値しない
機械的にコードを生成するレベルの低級言語ってことですね、わかります

399 ：

>>394
アセンブリ言語でもいいんじゃね

400 ：

>>397
作れるし実際に広く使われているよ。
MVCするのにJLabelとJTextFieldを名寄せしたりDuckTypingが必要なケースがそもそも謎。
VとMCの通信はVの実装の詳細とは独立に定義するものだが普通。

401 ：

>>400
御託はいいから早くやれよ

402 ：

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

403 ：

>>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 ：

「名寄せ」だってw

405 ：

>>403
JLabelとJTextFieldってさ、setTextは共有してるのに
インターフェースを共有してないから、setTextを呼び出すコードを
JLabelとJTextFieldで別々に容易しなきゃダメって話じゃないの？
そもそも実装の話なんて誰もしてなくて、structual subtypingの観点で同じコードを
重複して実装する非効率さを問題にしてたと思うんだけど、
そういうインターフェースの設計ミスが無い前提で話をしてない？

406 ：

>>405
さあ？
>>387がJavaでMVCするにはそれ(メソッド名の名寄せ)をするしかないと書いているから
んなわけね〜と書いたまでだけど。
あとさ、JLabelとJTextFieldでメソッドを分けなければいけないって、当然それらのクラスの
インスタンスを引数として受けるメソッドの事だと思うけど、具体的にどんなケースにそんな
メソッドが必要になるだろう？具体的に。

407 ：

>>403
だれもViewModelのなんてやれっつってねぇよ。
純粋なMVCやれ、別にPluggableMVCでもいいぞ。
てか、ViewModel型のMVCやるだけでもそんだけ面倒くさくなるんだな。
しかもJLabelとJTextFieldの２通りも必要とは。
そんな事してる間にDuck Typeが使える言語ならModel内部の作成に入っとるわ。

408 ：

>>407
は？ 純粋なMVCだが。どこが不純か詳しく。
Viewのインターフェース定義もViewModelの導入も、VへのメッセージをVの実装とは
独立して定義する実装パターンのひとつにすぎないが。
> てか、ViewModel型のMVCやるだけでもそんだけ面倒くさくなるんだな。
>しかもJLabelとJTextFieldの２通りも必要とは。
何のためのViewModelか全く理解していないのがまるわかり。

409 ：

現実的に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 ：

>>407
あとMVCにJLabelなどのメソッド名の名寄せが必要なパターンはよ。
どうせMやCにViewのロジックが食い込んだ汚い例しか出てこないと思うが。

411 ：

>>408
http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html
この辺りを見てお勉強しなおしたらいいんじゃないかなぁ？
MVCっつうのは、複数のViewで1つのModelを映し出し、
かつそこからControllerを分離した方式の事だよ。
Modelを複数のViewで投影できないなら意味がない。

412 ：

>>410
FruitListViewが、JLabelとJTextFieldに対応するにはどうしたらいいんですかねぇ〜

413 ：

>>409
テキストをポリゴン表示するど派手なラベル部品を使いたいんだが、テキスト表示するメソッド名
がrenderTextだったらど〜する。
adapterがViewの実装に依存している点で30点。

414 ：

>>411
出来るが。これは典型的なViewがModelへの参照を持たないパターンだが何を見ているの？
ViewModelについても何か勘違いしてない？
>>412
それはViewの実装の詳細。心配せんでもJLabelとJTextFieldで別メソッドを用意せんと
いけないような場面はViewの実装では殆どないよ。あるなら>>406にレスしてくれ。

415 ：

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 ：

>>414
具体的にどう書くか聞いてんだよ。
JLabelとJTextが問題になってたんだから、
JLabelとJText無しで出来ますじゃ意味ないだろ。

417 ：

間違えたんで細部修正
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 ：

ところで、標準ライブラリの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 ：

>>414
>出来るが。これは典型的なViewがModelへの参照を持たないパターンだが何を見ているの？
出来るなら具体的にそのコードを書いてくれ

420 ：

>>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 ：

全然本題と関係ないコード貼って何がしたいんだ……これがアスペか

422 ：

>>421
modelを複数のviewに投影することが出来る例だが、本題って何だっけ。

423 ：

事の始まりはDuckTypingできないJavaってゴミだねって話から

424 ：

どのJavaにこてんぱんにされてるｗ
型がきっちりしてる分、
抽象化能力が鍛えられてるんだよな。
型がないととりあえず作って
問題があったら、型調べて適当にディスパッチで
対応とかしてるから、何と何が共通の機能であるとかが適当になってる。

425 ：

>>424
>>418に答えてあげなよ。Javaだよ

426 ：

>>418
> ところで、標準ライブラリのOutputStreamとDataOutputの関係はどうなの？
別に問題ない。抽象化することで拡張性が得られている。
> こんな感じのコードを別々に書くことに合理性はあるの？
”書くこと” ではなく ”書けること” に合理性はある。
面倒であれば、別々に書かなくていいライブラリを使うか
自分で作れば良い

427 ：

>>423
とりあえずMVCに関してはDuckTyping別に必須じゃないねと言うことでFAだな。
静的型でも全然普通に出来る。

428 ：

>>426
つまり、標準ライブラリの設計が失敗してゴミで
共通の処理をまとめたくてもまとめられないウンコだから
別のライブラリ探すか自作するかしろ（標準ライブラリ使ったコードとは混ぜられないけどな）ってことですね。
分かりました！ありがとうJavaの人！

429 ：

>>428
自分に力がないのを言語のせいにするな
初心者の頃に習わなかったか？

430 ：

>>428
実際のところ>>418のようなのを両方書く必要があるケースって殆ど無いから。

431 ：

>>420
Javaになってないんですけどー
あと、あんたがしきりに言ってるフレームワークって具体的に何。

432 ：

>>420
JLabelだけを実行時に取り外せんぞ
なんつってMVCじゃねぇか。
Smalltalkなんかは、実行時にModelとViewの関係を
組み直せるメリットからMVC開発が進んだのに退化してるじゃねぇか。

433 ：

>>420
ViewをJLabelからJTextFieldに差し替えるコードを書いてくれ

434 ：

>>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 ：

>>430
OutputStreamWriterとRandomAccessFile（のサブクラス）両対応の出力コードを書くとき

436 ：

>>435
何を出力するコードさ?

437 ：

言葉よりもコードが雄弁に語ってるね
Javaが冗長でオワコンだと
こんな言語で書いてたら、そりゃIDEの補完機能に異常に拘るわけだよ
まあ、補完できようが可読性は最悪だし、
なにより動的言語でも補完できちゃうんだけどねw

438 ：

潜在的に100倍の冗長さがあり、それを生産性と勘違いした。
というところか。

439 ：

>>434
具体的にフレームワークの名前を挙げろと言ったんですけど。
ああ、結局自作しないと無いんですね。生産効率わるぅ

440 ：

>以下同文。FruitViewを継承したViewをJTextField使って実装して差し替えれば?
結局JLabel用のViewとJTextField用のViewを作るのか

441 ：

お前らいつまで書く時の話ばっかり見てるんだ？
コードは書くより読むほうが何倍も多いんだぞ。
だから生産性が高い言語使ってるはずなのに
開発期間が短くならないんだよ。

442 ：

なんかMVCパターンわかってない奴がいるみたいだね。
基本パターンは、Modelに対してViewが自分自身を登録し、
Viewがイベントを受け取るんだよ。
Modelが直接ViewのsetTextとかを呼んだりしない。
ModelはViewが持っているメソッドを意識しない。
ここまでわかっているなら、JLabelとJTextFieldの
継承関係がどうなっていようと関係ないってわかるはずだが。
繰り返すがMVCパターンの話な。MVCパターンが
面倒くさいという話ならそれは言語関係ない。

443 ：

なんかもうそろそろなんで
MVCパターンなんか使うの？
面倒くさいだけじゃんって
言う奴が出てきそうだなｗ

444 ：

それよりもWeb系の偽MVCと
GUI系の本物のMVCをごっちゃにしている奴がいそうだ。
偽MVCはオブザーバーパターンがでてこない

445 ：

>>442
>>440

446 ：

>>445
JavaScriptのMVCフレームワークを考えればいい。
JTextFieldというのは、<input type="text> のことだ。
Viewを作るか作らないかって？
inputタグがViewになってるフレームワークあるか？
初心者も甚だしい。

447 ：

View内部で使っているUIコンポーネントをシグニチャ的に互換性のある別コンポーネントに
(動的に)差し替えられるか？って話をしてるのに、全く話が通じてなくてワロス
都合が悪いから曲解してるのか、アスペなのか、馬鹿なのか……

448 ：

シグニチャ的に互換性があっても
機能的に互換性がないのだから
入れ替えることないだろ？
変なことを言うやつだな。
ボタンがいきなりテキストボックスなって嬉しいのか？

449 ：

ラベルとテキストフィールドに
機能的互換性があるかというと
ないよな。
テキストフィールドならsetFocusで
きるだろうけどラベルだとできないし。

450 ：

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

451 ：

>>449
setTextには文字を表示するという互換があるな。
interfaceでつながってないのは、設計ミスとjava.beansで
できるからっつうコトだろうけど。ちなみに、java.beansを使う環境だと、
JLabelも、JTextFieldも、setText、getTextは、xxx.textってな感じになって
共有できますね。

452 ：

なんでSmalltalkって廃れたんだろうね。

453 ：

RubyやPython用のMorphicが登場したり、.NetにSmalltalk移植されたり、
Smalltalkを例にした話題が増えたり徐々にSmalltalkが
復調してる気配があるね。

454 ：

Morphicは、Objective-C版とjavascript版も出てるぞ
Javaだけ取り残されていくな

455 ：

>>453
全体に、実務向き言語が退潮気味で、理論指向の言語が地歩を確保したり、
復権傾向にある。Smalltalk,LISP系,Prolog,関数型など。

456 ：

結論。Javaは糞。

457 ：

>>452
UNIXライクOSとそれ向けCPU（つまりCマシン）の異常な繁栄が
あるけど、
それ以前にゼロックスが売り方を二重の意味で（アラン・ケイの
考えるパソコンOSでもなく、IDEとしても価格設定やライセンスの
しかたで）間違えたから

458 ：

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 ：

>>458
http://www.google.co.jp/trends/explore#q=Squeak&cmpt=q
http://www.google.co.jp/trends/explore#q=Scratch&cmpt=q

460 ：

右下のRelated termsを見る限り別なもののトレンドなのではないか。

461 ：

Scratchみたい一般的な単語のトレンドとか何の参考にもならんだろwww
なんだ、SmalltalkerにとってはScratchと検索したら何でもSmalltalk関連かい

462 ：

DB接続、ファイル入出力、外部API使用、
何をやるにもJavaは冗長で可読性最悪。
言い訳は「そんなの書かなくてもフレームワークがやってくれるし！」

463 ：

まあフレームワークやライブラリといったソフトウェアスタック無しでJavaを使う意味は無いわな。

464 ：

一体どの言語ならフレームワークが不要になるのだろうか？

465 ：

Smalltalk系とかググらんでもだいたいわかるけど、
Javaはググらにゃ判らん事が多すぎる。
APIなんかググること前提だろ。
ちなみに、今はJavaのuninstall方法をググるのが大人気
http://www.google.co.jp/trends/explore#q=java%20uninstall&cmpt=q

466 ：

>>464
そもそもFrameworkとは何だ？Library全てがFrameworkだと思ってんの？

467 ：

>>466
フレームワークとは何だ？
Railsとかがフレームワークらしいよ。

468 ：

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 ：

>>467
FortranにもTesting FrameworkってのがあったねFrameworkとしての共通点はなんだい？

470 ：

>>468
なにそれ？ このリストに入っている奴ってなんなの？
Buzzwordとかもリストに入ってるけど？

471 ：

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

472 ：

まぁWeb2.0やCloudと同じ薄ら寒い用語ですしおすし

473 ：

>>471
そのFrameworkとは具体的に何を指してるのか言ってくれバズワードで言われても判らん

474 ：

Web servicesもバズワードなんかいｗ

475 ：

>>462よ。
フレームワークとはなにか聞いてるぞｗ

476 ：

>>474
出典がついてんだから出典読めよ

477 ：

フレームワークの説明なんて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 ：

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

479 ：

>>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 ：

日本語はダメらしいねｗ
http://en.wikipedia.org/wiki/Software_framework

481 ：

>>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 ：

>>468
おい、英語のWikipediaもダメらしいぞｗ
クソペディアを出典にしないでもらえないでしょうか
卒論ですら禁止されてることを大の大人がやって恥ずかしくないの？

483 ：

オレオレ定義はいらない。
フレームワークの用語の意味を
用語サイトから引用してください。

484 ：

知りたいならGoogleで「フレームワーク 定義」で検索すればいいじゃないの？

485 ：

>>484
俺もそう思う。なんで俺に聞くのかわからない。

486 ：

>>482
じゃもっとマシな出典だしてくれ。お前に任せる。

487 ：

>>485
自分で説明できない言葉を使うなよ。ルー大柴かよ。

488 ：

>>486
出典は見つかりませんでした。俺達の負けだ。

489 ：

>>487
じゃあお前、ルー大柴って言葉を説明してみ？

490 ：

もう意味がよく判らんし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 ：

>>490
全くわからんｗ

492 ：

>>489
東京都新宿区市谷冨久町出身1954年1月14日生まれの大柴 亨事だよ。
地名については地図に乗ってるから一意に解るよ。
同じ地域に1954年1月14日生まれの大柴 亨は1人しかいないから、
戸籍謄本で一意に特定できるよ。

493 ：

フレームワークの出典が見つからない
=> これまでの議論の前提が崩れる
=> Javaが完全敗北した事実も無効

494 ：

>>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 ：

>>492
そんな調べてわかるような説明はいらん。
お前の定義をかけ

496 ：

>一体どの言語ならチキンタツタが不要になるのだろうか？
何かこの一文のおかげで文章が成立してる気がする

497 ：

http://e-words.jp/w/E38395E383ACE383BCE383A0E383AFE383BCE382AF.html
フレームワーク【framework】

▼ 分野
▼ 文中の用語
枠組み、下部構造、構造、組織という意味の英単語。
ソフトウェアの世界では、アプリケーションソフトを開発する際に頻繁に必要とされる
汎用的な機能をまとめて提供し、アプリケーションの土台として機能するソフトウェアのこと。
アプリケーションの雛型。開発にフレームワークを利用すると、独自に必要とされる部分だけを
開発すれば済むため開発効率の向上が見込める。具体的なソフトウェアだけでなく、
汎用的に適用できるプログラムの設計モデルや典型的な処理パターンなどを含めてフレームワークと呼ぶ場合もある。

498 ：

もしかしてフレームワークってJavaの特権だと思っていたのか？

Ruby、PHP、Perl、JavaScript
ほとんどの言語にフレームワークがあるんだけど？

はい論破

499 ：

>>495
他で調べて検証できることを、自分で書いてくれればいいんですが。
だれもオレオレ定義を書いてくれとは言ってないし、
オレオレ定義を書くなと言ってるじゃないですか。

500 ：

コンパイラ言語
http://e-words.jp/w/E382B3E383B3E38391E382A4E383A9E8A880E8AA9E.html
>同じプログラミング言語にコンパイラとインタプリタの両方が用意され、必要に応じて使い分けられるようになっている言語も多い。
支離滅裂な辞典だな
「コンパイラ言語」なんてくくりの言語存在しないだろ

501 ：

>>497
かつて存在したFoundation(基礎/土台)とは違うのですか？
Foundationじゃだめなんですか？
「Foundationはつかってません」って柴崎コウ気取りなんですか？

502 ：

>>471
話を少し戻すけれど、どの言語にもフレームワークがあるというのは、
無理があると思う。

503 ：

フレームワークが無い言語って、Brainf*ckとか？
もっともBrainf*ckですら誰かが冗談でフレームワークを作ってそうだが

504 ：

>>503
新しい言葉だから、古い言語では使わないよ。

505 ：

>>502
たしかにそのとおりだ。
だからフレームワークがある言語を言おう
Java、JavaScript、Ruby、PHP、Perl、Python

506 ：

Smalltalk (Seaside)

507 ：

>>505
サーバ・クライアント時代の言語？

508 ：

サーバー・クライアント時代ではない言語ってなんだろう？

509 ：

>>508
FORTRAN とか

510 ：

C#の場合ASP.NETがウェブフレームワークになるだろうか

511 ：

>>510
フレームワークと呼びたくないというようなことはあるだろう。

512 ：

>>511
そういう頭悪そうなレスはやめたほうがいいと思う。

513 ：

LISP,Prolog,関数型言語などでは、ライブラリを使うことでさえ、
恥ずかしいという感覚があって、フレームワークなんて拒否される。

514 ：

んなわけねーだろw

515 ：

>>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 ：

Frameworkと名の付くものならCOBOLにだってあるよな
Frameworkと名が付くものが無いのはBrain Fuckとか
White spaceとかマイナー言語ぐらいになるじゃないか？
>>506
定義のらんFrameworkとやらと同列に語ってほしくない

517 ：

×定義のらんFrameworkとやらと同列に語ってほしくない
○定義の解からんFrameworkとやらと同列に語ってほしくない

518 ：

JavaにはCollection Frameworkというのがあるが、
STLはFrameworkになるのだろうか。C++側でFrameworkと
言われてるのを聞いたこと無いが。

519 ：

おまえらはバカだな
自分が書いたコードから呼び出すのがライブラリ、
自分が書いたコードを呼び出すのがフレームワークだよ
PHP、Ruby、Pythonのフレームワークは
総じて軽いから問題にならない
Javaのは…、まあおまえらが知っての通りだw

520 ：

>>519
Fotran Testing FrameworkはLibraryから呼び出されないんですけど・・・

521 ：

>>519
Task Parallelism in a High Performance Fortran Framework
これもライブラリーから呼び出されんぞ

522 ：

High Performance Fortran Frameworkな
書くの面倒だったから余計な分コピペしてもうた

523 ：

英語圏における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 ：

所詮Fotran世代ってことでしょうな。
あの頃の用語は間違っていると。

525 ：

>>523
Scriptを技術的な用語として検索すると、
アプリケーション制御用の意味合いで使われる事が多いぞ。

526 ：

>>524
日本海じゃない東海ニダ

527 ：

自分が書いたコードを呼び出すのがフレームワークならイベントドリブンなAPIはことごとく
フレームワークになっちゃうな。SAX系のXMLパーサもフレームワーク。

528 ：

>>515
使っている人がいるなら別だが、使われることがないものに
フレームワークと名付けられても。

529 ：

MFCなんて当初だれもFrameworkなんて呼んでなかったのにな
今でもFrameworkなんて言われると違和感がある

530 ：

>>520-521
>>519をもう一回読んでくれ
ライブラリがフレームワークを呼び出すなんてまったく書いてない

531 ：

>>530
じゃ何が呼び出すんですかねぇ？
High Performance Fortran Frameworkなんて呼び出される要素が全然見当たらないんですが

532 ：

>>531
High Performance Fortran Frameworkを呼び出す貴方がフレームワークなんですよw
所詮制御の反転なんて関心の分離を実現する一手法にすぎないのに。
「自分が書いたコードを呼び出すのがフレームワーク」なんて良くある特徴と定義をごっちゃにしただけ。

533 ：

となるとHigh Performance Fortran Frameworkは自分で書いたコードという事になるのですか？トム

534 ：

>>533
High Performance Fortran Frameworkの気持ちになれば解る。
High Performance Fortran Frameworkというワタクシを優しく呼び出す貴方は
High Performance Fortran Frameworkにとって間違いなくフレームワーク。

535 ：

ソフトウェアフレームワーク - Wikipedia
ソフトウェアフレームワークとは、プログラミングにおいて一般的な機能をもつ共通コードをユーザーが選択的に上書きしたり特化させたりすることで、ある特定の機能をもたせようとする抽象概念のことである。
ソフトウェアフレームワークは、はっきり定義されたAPIを持ち、コードを再利用可能な形で隠蔽しているという点でライブラリとよく似ている。
しかし、ライブラリでは呼び出し側がプログラム全体の制御構造を指定できないが、フレームワークでは可能である。
Preeによれば、ソフトウェアフレームワークには「凍った部分 (frozen spot)」と「熱い部分 (hot spot)」がある。
「凍った部分」はソフトウェアシステム全体のアーキテクチャ（基本コンポーネント群とそれらの相互関係）を定義する。
それらはそのフレームワークを使って何を実装した場合でも常に変化しない。
一方、「熱い部分」はプログラマがプロジェクト固有の機能に対応したコードを追加できる部分である。
ソフトウェアフレームワークには、ソフトウェアアーキテクチャ内でアプリケーションプログラマが特定の機能に対応したコードを置ける場所（すなわち「熱い部分」）が定義してある。

536 ：

>>535
>>477-481

537 ：

単純に新しく用語が定義されたってだけじゃん。
それまでの間は定義が確定されずフラフラしていただけ。
今の定義で語れば良い。

538 ：

今の定義って何？

539 ：

Railsとかがフレームワークってことだよ。

540 ：

レスポンシブデザイン・フレームワークの「Foundation」に新版が登場。「モバイルファースト」を強化してZeptoを採用
http://jp.techcrunch.com/2013/03/02/20130228responsive-design-framework-foundation-4-launches/
FoundationなのかFrameworkなのかもうワケワカメ
そのうちFrameworkの次はFoundationとか原点回帰していくんだろうな
Application Service ProviderとSaaSみたいなもんか

541 ：

>>539
.Net FrameworkはFrameworkだけどFrameworkじゃないとか？

542 ：

Java Collection Frameworkも多分オワコンで、Java Collection Frameworkという
Frameworkじゃ何かになるんだな。

543 ：

そのFoundationは特定のフレームワーク名では？
Ruby on RailsとかSeasideのような

544 ：

Seasideって実行環境だけど、あれもFrameworkなんか。

545 ：

なんつうかアレだろ、宇宙の起源はフレームワークだとかそんな感じだろ

546 ：

いやDXとかの方が近いだろ
マツコDXと桃鉄DXみたいに、
DXとついてるものには共通点がない
ただDXがついてるためになんとなく
一体感がある

547 ：

>>472 がすべてを語ってる気がする。

548 ：

>>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 ：

ぶっちゃけFrameworkには枠組み(骨組み)以外の意味はないから、
これは、Frameworkだなんて成り立たないんだよ。厳格な用語じゃない。

550 ：

フレームワークの意味について話し合うスレッドになってるな。
静的型付けも動的型付けもどっちもどっちという一定の結論がでたということでいいんだろ。
ちゃんとテストすることが前提ならどっちでもいんだけど、テストする時間が惜しいときがある。
そういうときはコンパイル段階でタイプミスを除去できるから静的型付けの方がいい。
じゃあ静的型付けが現時点で最強ということでいいな。

551 ：

フレームワークの意味について話し合うスレッドになってるな。
静的型付けも動的型付けもどっちもどっちという一定の結論がでたということでいいんだろ。
ちゃんとテストすることが前提ならどっちでもいんだけど、全体が完成するまで待つ時間が惜しいときがある。
そういうときは部分的実装の段階で実行できるから動的型付けの方がいい。
じゃあ動的型付けが現時点で最強ということでいいな。

552 ：

コンパイルエラーをテストで見つけるという考え方が
そもそもおかしいんだと思う。
コードの動きが正しいかどうかはテストがないと判定できないけど
コンパイルエラーは明らかに間違いってわかるもの。
そのためにテストを使うっていうのは
単体テストで不具合を見つけるべきものを
統合テストで見つけているようなものだと思う。

553 ：

構文の間違いを翻訳時に見つけられる動的型付言語はあるでがな。
Objecitve-Cとか。

554 ：

Objecitve-Cで見つけられる場合はあるけど
静的に決められるところだけであって
そもそも静的な範囲がすごく狭い。
つまり見つけられる場合が少ない。

555 ：

ちなみに、Objective-CでMessageに対応するMethodが見つからないのは、
実行時の例外であって翻訳時に出来る構文の間違いじゃない。
なんせMessageの宛先は別Processかもしれないし、Socketの
向こうに居るかもしれない。もしかしたらShared objectかもしれないからね(実はこれが本命)

556 ：

>>552
そうなんだよね。設計が先にあってその通りに組み上げるってんなら
あるていど許容できないでもないんだけど、プログラム書きながら
こういうやり方でいけるんじゃないかみたいにしてプロトタイプを作るときなんか
設計上の落ち度に起因するようなエラーとタイプミスとが同じレベルで通達されてくるって
いうのがどうにも嫌だ。

557 ：

>>554
静的じゃないのはMethodが存在するかしないかだけだよ。
それ以外は全て翻訳時に確認される。

558 ：

Objective-Cで実行時にMethodが見つからず例外が発生した時って、
WinAPIでSendMessage使いまくって異常が発生してる時よりDebugがマシだよ。

559 ：

そもそもコンパイルエラー全てを単体テストで
見つけられるのか？という問題がある。
実は単体テストに通ってもプロダクションコードは
正しく動かない場合が存在する。

560 ：

そんなん静的型付でも同じじゃん。Type *concrete = dynamic_cast<Type*>( abstract );を
網羅しきれるかってのと同じだろ。

561 ：

>>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 ：

>>560
テストを流せば、静的型付け言語のコンパイルチェックで
見つけられるエラーは全てわかると言ってる人がいるだろ？
それが間違いということ。
あとdynamic_castは危険だからあまり使わないようにするという風潮がある

563 ：

見つけられるバグの数
（静的型付け言語＋コンパイルチェック＋テスト）　＞　（動的型付け言語＋テスト）

564 ：

>>562
Javaはdynamic_castだらけじゃん。Objectで返すMember関数多すぎ。

565 ：

>>560 >>561
それテスト書いてないじゃんｗ
テスト書いても不具合が見つからない事がある
でも静的型付け言語なら見つけられる。
って話をしてるのにｗ

566 ：

>>565
>WinAPIつかってた時代はバグだらけでマトモなプログラムは書けなかったと？
この意味分かってる？

567 ：

>>566
開発コストがかかるって事でしょう？
そりゃそうですよ。テストがなくても人力テストが完璧なら
バグはありませんよ。
でもね。今はより早くバグを検出することが求められています。
昔の開発効率が悪い時代の例を持ってこられても困りますねぇｗ

568 ：

>>565
どんな不具合がみつかんの？

569 ：

>>568
型チェックエラー
動的型付け言語なら型がないから、型チェックエラーにはならず、
プロダクションコードは間違った答えを返すが一応動作し
単体テストコードは問題なく書かれている。
単体テストコードがあれば型チェックは不要というのが
間違いである例が存在する。しかも別に特殊な例ではない。

570 ：

>>567
全体の開発コストで言えば、Android向けにJavaで作るより、
iOS向けにObjective-Cで作ったほうが安くすんでるな。
期間もJavaで作った時の概ね2/3ぐらいで済む。
Emulatorが糞なのもあるが、Methodが見つかるからない事が
原因で問題が発生した事がまず無い。
自分たちでiPhone使ってて異常終了しやすいAppとか
殆ど見ないだろ。作ってる側としても実際そこが見つけにくい
問題になる事が無いんだ。

571 ：

> 全体の開発コストで言えば、Android向けにJavaで作るより、
> iOS向けにObjective-Cで作ったほうが安くすんでるな。
統計情報があれば信じるよ :P

572 ：

統計ねぇどっかにあるのかねぇ。
まぁ、うちは4本Releaseしてるけど、全般的に2/3ぐらいだったよ。
結局開発工程全体でMethodの有無が占める問題は極めて小さい。
一番重要なのは如何に俺実装を書かないか。その差が一番でかくなる。
俺実装が増えれば増えるほどバグの発生箇所が増えるわけだかね。

573 ：

つまり、俺実装を書かないというのが
安くすんでる理由なわけで、
全然Javaとか動的型付け言語とか関係ないといったも同然。

574 ：

strictモードみたいな機能がある言語だと
みんなたいていONにしてコンパイルチェックの
恩恵を受けようとしてるじゃないか？

575 ：

関係ないわけではないんだが、JavaはinterfaceとかProxyに投げれば済んだのに態々
classを書かなきゃいけないとか、Objective-Cでは書かずに済んだ
俺実装が増えやすいわけだし。

576 ：

>>574
誰がしてて、その人は成果を出せてるの？

577 ：

>>576
同じ人がstrictモードON/OFFで調べないと比較にならんだろｗ
誰がを聞く意味がわからん。
で、殆どの人がstrictモードONを選んでいる。
その人にstrictモードOFFを強要したら成果は下がるだろうね。

578 ：

>>575
あなたが書かずに済ます方法を知らないだけでしょう？
よくいるのが言語標準機能にないからと
毎回同じコードを書く人。
一回書けばいいだけなのにコピペをする。
そいうのはその人の問題。

579 ：

>>577
だろうね。じゃなくてどのぐらい下がったかじゃないと意味無いでしょ。

580 ：

>>578
JavaにSelector名を指定してEventを拾う方法はありますか？

581 ：

>>580
HTMLの話？
Selector名っていうのはHTML/XMLのタグを取得するものだとして、
http://jsoup.org/ セレクタであればこんなのが見つかったが
Eventってなんだ？ 誰がEventを発行するんだ？

582 ：

AndoroidならWebKit + Javaの開発環境を
Googleが用意してるけど？

583 ：

面倒くさいから
Objective-CでSelector名を指定してEventを拾う方法を
聞けばいいんじゃね？

584 ：

>>578
あと、Messageの遅延送信(簡易的なlambda式)はできましたか？
ButtonのEventHandlerに対し親Viewのclassが生成した局所変数を渡すことができましたか？

585 ：

>>584
お前、手段と目的が反対になってるぞ。

586 ：

>>581
セレクターつったら、object.XXXXってあった時のXXXXの事だろ、
特定の言語に限らずセレクターと呼ぶはずだが。

587 ：

>>586
それはお前の視野が狭すぎるｗ
Ruby セレクター
PHP セレクター
JavaScript セレクター
なんでもいいから検索してみなよ。
特定の言語でしか使われてない用語だから。
（お前の知ってる数少ない言語以外にはない概念なんだろ？当然だって気づかないかな？）

588 ：

言語マニア（言語を作るのではなく、言語の研究が目的となってる奴）なんだろうなぁ。

589 ：

間違ったｗ
言語マニア（言語を使ってアプリを作るのではなく、言語の機能の研究が目的となってる奴）なんだろうなぁ。

590 ：

>>585
>>575が書かずに済ます方法があったらしいといったので、
Javaで書いた時冗長になって気になった事を書いたんですけど。
何か気になりましたか？

591 ：

× >>575
○>>578

592 ：

>>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 ：

>>590
さっき書いただろ？
お前は手段と目的が反対になってるって
言語に特定の機能がなければ別の方法で実現すればいいだけだよ。
それが冗長になるのなら、簡単に書けるような仕組みかライブラリを
探すか一回だけ書けばいい。
さっきも書いたけど、お前は
よくいるのが言語標準機能にないからと
毎回同じコードを書く人。
一回書けばいいだけなのにコピペをする。
ってやつだろ？
どうだ図星だろう。

594 ：

ここの人たち頭いいね
ぜんぜんついていけないや
俺みたいに深くわかってないやつがいるから
業界がよくならんのかもね

595 ：

>>593
いいえ。私は無駄なものは書かない主義ですよ。
今上げた疑問はObjective-Cなら殆ど書かずに済んだ話です。
それにあなたはJavaだと書かないで済む回避策を提示できませんでしたよね。
それに疑問を上げた点は実際の開発で頻繁に使う機能ですよ。

596 ：

> それにあなたはJavaだと書かないで済む回避策を提示できませんでしたよね。
万能の回避策
コードジェネレータ
冗長でも書けるのであれば、回避策になる。
はい論破

597 ：

>>593
>言語に特定の機能がなければ別の方法で実現すればいいだけだよ。
>それが冗長になるのなら、簡単に書けるような仕組みかライブラリを
>探すか一回だけ書けばいい。
そもそも、ここの話がおかしな話。Javaだと上記の事をしなきゃいけないから
冗長だといってるんですが、話をねじ曲げてませんか？

598 ：

>>596
コードジェネレーターを使わないで済む言語の方が開発効率は良いですが。

599 ：

ある言語で書かなくて済んだ事を、ある言語だと書かなきゃいけない、ライブラリーを探さなきゃいけない
何らかの別の方法を探さなきゃいけない。なにか一手間必要になる。それは全て開発効率が
悪いってことなんですがわからないんですかね？それに、一手間加えたものは全て必要なかった
何らかの管理コストが発生する。実際開発したことあれば普通解る話なんですがねぇ。

600 ：

自前で実装する→作成の手間がかかる・保守の手間がかかる
非標準ライブラリーを使用する→メンバーへの学習コストが大きく増える・バグ管理が分散した分コストがかかる・バージョン管理のコストが増える
コードジェネレーター→正直論外・コードジェネレーター自体の管理コストが増える・生成元のコードの管理コストが増える・
　　　　　　　　　　　　　　バグ発生時のデバッグ時間が爆増する・開発時に前処理が増える分のコストが増える

601 ：

>>593
>>596
目的を履き違えてんのはお前だろ
なんでライブラリー追加したり、コードジェネレーター
つかってまでJava使うんだよJavaを使うのが目的になってるじゃねぇか

602 ：

>>601
自分で言語選べない会社やプロジェクトもある
察してやれ

603 ：

そりゃJavaの方が実績のあるライブラリ等が揃っている分野はJava使うでしょ。
言語機能だけで使う言語は普通決めない。

604 ：

>>559
では静的型付けならば
単体テストさえ通ればプロダクションコードが確実に動作する
と言えるのかといえば、全然そんなことないよね。
でも単体テストで「多くのバグを」発見できるから、
静的型付けでも単体テストをやってる。
単体テストはコンパイル時型検査の完全な代替にはならないが、
「多くのバグを」発見できるというのは経験上正しい。
一方の「多くのバグを」が有効で、他方の「多くのバグを」が誇張だというのは
よほど定量的なデータで裏付けないと正当化できないと思うが？

605 ：

動的は静的へ変換できるだろ。
たとえば可能な型をすべて持っているクラスを用意してそれにスイッチ、フラグを付ける。
ユーザー定義の型は実行までに確認、取得しておく。

606 ：

動的型言語ではコンパイル時に何も検査していない
かのようなことを言うような粗すぎる論理の人が
はたして静的型システムを使いこなせるのだろうか？

607 ：

Javaと静的にも動的にも書けるGroovyの両方を使った開発を会社でやっているけれども、
Groovyで書くコードも公開メソッドは型付きで書くようにチームで徹底している。
理由は幾つかあるけれども、とりあえず引数や返り値の型については動的だろうが静的
だろうが結局ドキュメンテーションの際に明記することになるのであまり手間じゃない。
中身はそれぞれ静的に書いたり動的に書いたりしている。
単体テストの打率はそんなに変わらない感じ。テスト対象となるメソッド等々は個人個人で
見通しがきく大きさだし。ただ統合テスト時など他人の書いた部分を叩く際の凡ミスや仕様
変更の見落としは確実に少なくなる印象。同様にGroovyからJava側のAPIを呼び出す時も
基本的には型付きなど、要所要所の界面で型を利用して依存関係を追跡し易くする方針。
界面でいえば社内用にGroovyで書いていたREST APIを顧客向けにテスト公開する際には
Javaで全部書き直した。リソースクラスのメソッドについた引数の型やクラス定義などを
読んで入出力のJSONモデルも含めたREST APIのドキュメントやテスト用のWeb UIを自動
生成するツールがJava側には幾つかあったので。移行は手間だったけれども移行後はドキュ
メント管理などが格段に楽になった。
要所要所で使えば凄く便利だと思うけれどもね、型。
Python3.0の関数アノテーションみたいにAPIの部分に型情報をつけるのは御利益も大きいよ。

608 ：

>>607
>単体テストの打率はそんなに変わらない感じ。テスト対象となるメソッド等々は個人個人で
>見通しがきく大きさだし。
この辺りは自分の経験とも合致していて同意。
> ただ統合テスト時など他人の書いた部分を叩く際の凡ミスや仕様
>変更の見落としは確実に少なくなる印象。
モジュール単位での開発+結合テスト なスタイルだと、オレの経験でも同じ。
CI重視で各モジュール単位の開発中にも継続的に結合テスト相当も単体テストと一緒にやるスタイルだとどうだろう、という興味がある。
そういうスタイルは自分では動的型言語での経験しかない。
CI重視だと動的型言語でもモジュール間結合の問題も十分早期にバグを発見できる。
コード書きながらパラレルにxUnit動かすから、コードをsaveした数秒〜数十秒後には単純な型不整合は発見できる。
つまり、事実上コンパイルと同じ早さ。
静的型言語ではそれより効果が出るのか興味ある。

609 ：

>>608
結合テストの自動化って何使ってるの？

610 ：

>>608
> コードをsaveした数秒〜数十秒後には単純な型不整合は発見できる。
それだとどれくらいの間隔でsaveするかだな。
静的型付け言語だとIDEの機能ではあるが
コードを書いた直後に発見できる。

611 ：

>>604
私の身近で起こるバグは圧倒的にflagの1と0を逆に考えていた的なもので、
コンパイルテストで発見できたことなんてないけどな。

612 ：

>>610
Smalltalkの場合、数行のメソッド書く毎にsaveすることが多いから
事実上コードを書いた時点で発見できる。

613 ：

>>612
saveっていうかコンパイルな。Smalltalkのコンパイルは原則メソッド単位。
作業の流れの雰囲気はこんな感じ。http://vimeo.com/43740225

614 ：

>>611
そりゃそうだろｗ
コンパイルはテストじゃない。チェック。構文チェック。
構文上明らかにおかしいものを検出するもの

615 ：

>>612
またSmalltalkかｗ
なんか、動的型付け言語でも問題ないというよりか
Smalltaklなら問題ないって話に見えてきた。
今度からSmalltalkはちゃんと明記しないか？

616 ：

>>613
やっぱりSmalltalkだけ特別な世界だわｗ
君、Smalltalkでどんなの作ったことある？
一番大きいプロジェクトが聞きたいな

617 ：

>>608
そうありたいというか、今まさにテストのイテレーションの遅さが問題になっていて環境改善の
真っ最中なのでw
型付きで型付きのAPIを呼び出したときは確かに凡ミスは即座に解る。便利。でもそっちよりも
色々な単位でテストを素早く繰り返し行える環境の方が遙かに便利な感じで、静的云々はあまり
関係無いような気もする。
ただ呼び出しの不整合等々は各ブランチ内での開発中よりもむしろマージ段階で起こるケースが
厄介だと思う。マージ後の検証は大抵大きな単位でテストを走らせる必要があるので、その前に
静的に見つけられるものは見つけられた方が嬉しい。延々と走らせたテストが凡ミスでこけると
かなり切ないので。
あとは上にも書いたけれども界面を型付きで書くとファイルやプロジェクトをまたがった依存性
をかなりカッチリ把握できるので、何をするにしても影響範囲などを事前に把握しやすい分析面
での御利益は大きい。
蛇足ながらEclipseでGroovyを書くと静的に型を確定できない変数アクセスやメソッド呼び出し
は黒地のイタリックにアンダーラインという、見た目的にかなりイヤンなスタイルで表示される
ので、見た目の改善のため自ずと型を書いてしまうと言う副次的効果はある。個人的に。

618 ：

> 延々と走らせたテストが凡ミスでこけるとかなり切ないので。
まさにこれなんだよなぁ。
人間である以上ミスは避けられない。
そんなつまらないミスで時間とられることが
苦痛じゃないのかって思うわけだけど。

619 ：

だから苦痛じゃない人って
コードもプロジェクト全部で数千行程度
単体テストも数秒で終わるものしか
やってないんじゃないの？って思う
大規模だと単体テストでも全部やれば数分かかるんだよ。

620 ：

動的型の議論でSmalltalkだけ特別な世界だから議論から除外するなら、
静的型の議論で関数型は特別な世界だから議論から除外すれば？
あほらしw

621 ：

どうして単体テスト全部を動かすとかいうのかねー
改変部分に直接関与する分のケースを動かせばいいだけなのに
そしてそんなことは簡単にできるのに
あまりにも原始的すぎねーか？

622 ：

動的型付け言語で、改変部分に影響するところってどうやってわかるの？
影響するファイルというのは、修正したファイルだけじゃないよ。
動的だから実行しないと影響するかわからないじゃない。
静的型付け言語なら、リンクするための
情報などから静的にわかるけどさ。

623 ：

>>620
除外しないでいいからSmalltalkですって書いとけや。
書いとかなかったら聞くけどｗ

624 ：

>>622
メッセージセレクタ。

625 ：

>>624
またSmalltalkの話ってことでいい？

626 ：

Smalltalkなら標準機能だけで簡単だけど
Smalltalk以外でも簡単にフィルタ書けると思うけど？
ツールも一切合切用意されてないと何もできないタイプ？

627 ：

>>616
自分が関わったことのある比較的大きめのプロダクトだと
ざっと2000クラス、45000メソッドくらいだったかな。w

628 ：

自分が知らないものは除外したがる不勉強な奴がいて困る。
それに別にSmalltalkは動的型言語としては何も特殊なことは
やっていないんだがな。単にシステムとして、動的性をちょっと
追求しすぎちゃった感があるってだけで。

629 ：

> それに別にSmalltalkは動的型言語としては何も特殊なことは
> やっていないんだがな。
動画見ても十分やってるじゃん。
他の言語で、あんなエディタ使ってるか？
普通テキストエディタで書くんだよ。

630 ：

>>628
> 自分が知らないものは除外したがる不勉強な奴がいて困る。
全くだ。Smalltalk以外の
動的言語使ってる奴はどうした？
その話が全く出てないぞ。
知らないのかな？

631 ：

>>629
Smalltalkのチート感は半端ない

632 ：

> Smalltalkのコンパイルは原則メソッド単位。
それが特殊って気づかないのかな？

633 ：

Smalltalkが環境として特殊なのは第一にイメージベースなところだが
それは動的型であることと密接な関係にある。
Smalltalkのチートさは動的型のメリットのわかりやすい実例だな。

634 ：

だから他の動的型言語には、
適用できない技術なのかな。

635 ：

>>633
イメージってったって要はナンチャッテOODBだろ？
OODBに永続化されたデータで処理系を作って動かしたという点は
特殊かもしれないけれど、
それは動的型であることとはさほど関係ないように思うのだが
アラン・ケイだってもっと賢い型システムがあれば動的型にはこだわらない
って言っているわけだし。
http://d.hatena.ne.jp/nishiohirokazu/20100919/1284885238

636 ：

イメージベースで可能なことは、ファイルベースでも可能ではあるよ。
単にツールを充実させるモチベーションの問題だと思う。
ファイルベースだと、>>629が書くように、エディタ使えばいいという発想になる。
だからEclipseスゲーとか思って満足してしまう。
イメージベースだと、汎用エディタでプログラミングできるわけじゃない。
Smalltalkのブラウザはテキストエディタの拡張じゃなくて、クラスのUIなんだ。
だからより良い対話を実現するためにコードコンプリーションやリファクタリングブラウザが発明される。
ライブラリとのより良い対話を実現するためにSUnitが発明され、xUnitに発展する。

637 ：

>>635
そのOODBがGemStoneならばYES、ObjectStoreならばNOだな。
オブジェクトが永続化されていることが重要なんじゃない。
オブジェクトを動かすメタ情報や実行コンテキストがオブジェクトメモリ内で永続化されることが重要なんだ。

638 ：

ちと興味があるのできくのだけれども、SmalltalkでXML-Objectバインディングとか
JSONマッピングとの相互変換ってどうやるのだろう?

639 ：

>JSONマッピングとの相互変換ってどうやるのだろう?
なんだこりゃ。単にJSONマッピングね。

640 ：

>>638
ん？　なんか特殊なことしないといかんの？

641 ：

いや、Jaxbとかだと最低限のアノテーションをつければあとは規約で型情報を読みとって
XMLへのシリアライザデシリアライザを自動生成するけど、その辺り動的型ではどういう
方法が一般的なんだろうかなと。

642 ：

テキストへのシリアライズ/デシリアライズなら
Smalltalkの場合シリアライズしたいオブジェクトにstoreOn:というメッセージを投げれば自分自身を構築するスクリプトを出力する。
デシリアライズはそれをevalすればいいだけ。

643 ：

>>642
いや、XMLとかJSONとか。他言語を相手としたやりとりに使うフォーマットの部分。

644 ：

>>643
動的言語で一般的なわけではないけれど、多くのSmalltalk処理系では
プラグマが使えるからそれ使うだけ。ただプラグマはメソッドにしか
付けられないからプロパティのマッピングとかに使うにはアクセッサを
介するとかちょっと工夫がいるけど。
http://www.cincomsmalltalk.com/present/XML2Object.pdf の14ページ

645 ：

これは・・・面倒です。全部名前付けしていくんだ・・・

646 ：

やっぱりSmalltalkだけ特別だな。

647 ：

>>644
最近はプラグマなんかいちいち書かんでもGUIで表の穴埋めするだけだけどな。

648 ：

GUIで表の穴埋めする
動的型付け言語って他に何かある？
つくづくSmalltalkに限った話ばかり続くね。

649 ：

JAXBだと頭に@XmlRootElementとアノテーションつけるだけで大体のたたき台は出来るよね。
後は規約を外れて細かく変更したいところをいじるだけ。

650 ：

はじめからXMLだとかJSONだとかいっているのにいきなりSmalltalk同士でしか使えないシリアライズの
話を持ち出す辺りにんともかんとも。

651 ：

ぶっちゃけマニアックな言語だと、簡潔に書けるって言われても
どれくらい簡潔なのかイメージが湧かないので、
次の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 ：

マッピングの話なのに・・・

653 ：

マッピングの方法を知りたいんじゃなくて
動的型を叩くネタを知りたいだけだからじゃね？

654 ：

静的型(ていうかJava)のほうが圧倒的に冗長になりそうな例だが...

655 ：

言われてみればDOMを使って手続き的にXMLを読んだりシコシコ手作りする機会がめっきり減ったな。
大抵は宣言的なXMLバインディング。SAXの方がまだ特殊用途で出番があるぐらい。

656 ：

つーかXMLなんて喜んで使ってるアホはJavaドカタだけだろ
XML地獄で多少は懲りたみたいだが

657 ：

Java使いはXML地獄が嫌なのでアノテーション地獄に移行したよ

658 ：

ジェイソン地獄大好きｗ

659 ：

動的型付け言語は静的型付け言語でコンパイル時に自動的に行われる
型チェックの代わりに分岐網羅率100%のテストコードを書かなきゃ
いけないんでしょ。それってめんどくさくない？

660 ：

LLはYAML地獄からJSON地獄へ移行済み。

661 ：

>>659
へー、なんでC0ではなくC1なんだい？

662 ：

>>661
じゃあ逆に聞くけどなんでC0じゃなくてC1なわけ？おん？

663 ：

>>661
同じコードでも入っているオブジェクトによって
成功する場合と失敗する場合があるから

664 ：

>>662
C1が必要だと言ったのはオマエじゃないかw

665 ：

どんなオブジェクトが入るかってのは
結合時の話になるから、単体テストでは
テストできず、結合テストが必要になるんだよね。

666 ：

>>663
へー、じゃあC1では全く不十分だねえ。
C4が必要だねえ。
どうしてC1で十分だと思ったんだろうねえw

667 ：

>>666
C1って言い出したのはお前じゃないのか？
じゃあ ”お前の指摘通り正しく” 言い直すよ。
動的型付け言語は静的型付け言語でコンパイル時に自動的に行われる
型チェックの代わりに分岐網羅率100%のテストコードを書かなきゃ
いけないんでしょ。
つまり、C4が必要。
それってめんどくさくない？

668 ：

>>667
C1と言い出したのは>>659だろ？

669 ：

>>666
C4なんてないだろ。プラスチック爆薬のことか？爆発しろと言ってるのか？
お前は俺に爆発しろといってるのか？おん？
俺はお前がうらやむようなリア充であることを否定しないけどな。
あえて否定しないけどな。
>>668
俺だわ。完全に俺が言い出してたわ。反省はしないし間違ってるとも思ってない。

670 ：

>>667
はっきり言うと、あんた、網羅率の分類すらわかってないわけよ。
C1=分岐網羅率
C4=経路網羅率
出直してこい

671 ：

>>670
誰かと間違ってるだろｗ
まあいい、出直してきたよ。
今、出直してきたよ

672 ：

>>669
C1が100%でも引数として渡されるオブジェクトの種類を網羅できないだろ。
少なくともC4でないと。
で、C4が相手となると、動的型では100%達成どころか、計測することすら困難なわけだ。
結論としては、動的型では型安全をテストで「検証」することはできない。

673 ：

例えばこんなミスがあるから
動的型付け言語では、C1テストが必要になる。
var obj; // 本来はAと互換性があるものしか入れてはいけない。
if(cond) {
　obj = new A();
} else {
　obj = new B();
}
//AとBに互換性はない。
foo(obj); //fooの引数はAと互換性があるものしか想定していない。

674 ：

なんだか私とは別世界の人だらけらしいが、皆さんテスト屋さん？

675 ：

>>673
それはC0で検出可能だアホw

676 ：

wikipedia読んで勉強してきた。俺間違ってた。
if (condition1 || condition2) {
}
C1だとこういうとき条件式を全部チェックできないんだって。
それをやるのがC2。だから最低でもC2 100%にしなきゃいけない。

677 ：

違う、そうじゃない。
タイプミスをチェックするだけなら組み合わせなんてどうだっていい。C0だ。
C0でいい。

678 ：

静的型ではコンパイルエラーになってしまうコードも
動的型では正しいコードでありうる（ゆえに表現能力が高い）ということが
分からないかぎり、議論は永遠に平行線だな

679 ：

>>678
議論の主題は開発の生産性。表現力が高いことがわかっても
そのことが開発の生産性とどう関連するのかわからなかったら
意味がないと思うのよ。表現能力が高いことってどういうこと？
表現能力が高いことは開発の生産性が高いことにつながるの？

680 ：

Javaエバンジェリストの人は、
コード行数や必要なクラス数が減ると
開発生産性が向上するって力説してたよ
ttp://www.flickr.com/photos/33583790@N00/7465233960/

681 ：

>>679
表現力が低いと、顧客やQA屋からのフィードバックを反映させる時に
設計レベルから修正しなければならない可能性が増加するんだよ。
表現力が高いということは、そんな時に実装レベルでやりくりが出来るということだよ。
設計レベルでの修正を繰り返すのと、実装レベルのやりくりを繰り返すのと、
最終的にどちらがよいかは、案件の特性による。

682 ：

表現力の違いと影響範囲の違いの関連がよく解らない。

683 ：

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 ：

>>680
そりゃ同じ言語での場合の話だ。
特に静的型付け言語と動的型付け言語では
コードに含まれる情報量が違うので
一概に比較はできん

685 ：

>>683
いや、それ邪悪じゃんｗ
標準ライブラリの内部コードが変更されたらどうする。
ラップしたライブラリを作って作るか、
標準機能にパッチを取り込ませるのが
正しい対応方法だよ。

686 ：

モンキーパッチも選択肢の1つだということが理解できない静的脳

687 ：

ドカタには存在しない選択肢だから仕方ないね

688 ：

マトモなプログラマの潜在開発生産性はドカタの100倍

689 ：

現実的にはJava土方の1000人月=まともなプログラマの50-100人月くらいだけどな。

690 ：

流石に基本クラスを書き換えるようなことはしないけど、ユーザクラスに対して
実行時にホットパッチを当てるのはJavaでも全然珍しくないし、その場合も大抵
はClassLoaderを分けて影響範囲を制限するけれどもね。

691 ：

>>690
> 流石に基本クラスを書き換えるようなことはしないけど
書き換えることまでは出来ないけど、ではなく？

692 ：

>>691
書き換え出来るよ。java.lang.Stringにパッチをあてるとか。
ただ基本クラスはルートのクラスローダーで読まれるので扱いは静的で、他のユーザー
クラスのように実行コンテキスト毎に異なるクラス実装を使用したりも出来ない。
あとライセンスの関係で配布が出来ない。

693 ：

ウンコレベルに冗長だけど、可能ではあるね

694 ：

冗長ではない。
LOC的に生産性が高いのだ！

695 ：

> 実行時にホットパッチを当てるのはJavaでも全然珍しくないし、
うんうん、全然珍しく無いよね。
だからそういうコードが「より簡潔に」書ける言語が良いってわけだ。

696 ：

いや、普通やらないだろ。
そんなことすると互換性の問題が発生する。
となるとやっぱり不要ってなるわけだが？

697 ：

>>696
ベースライブラリへのモンキーパッチでどう互換性の問題が発生するんだい？
具体的に言ってごらん？

698 ：

基本クラスにモンキーパッチ当てないと使えないようなものは他の物と組み合わせてつかい
にくいと思うのだけど。他のコンポーネントへの副作用とか出てくるでしょ。
prototype.jsがまさに基本クラス拡張型だったな。その教訓を受けてかjQueryはラッパー型で、
DOMのエレメントやそのprototypeをいじって拡張することは殆どない。

699 ：

全然具体的じゃなくてワロタwww

700 ：

>>697
>Python のランタイムは、モジュール、クラス、そして関数に至るまで、 ほとんどのオブジェクトに
>ついて実行時に編集することを許しています。 これは一般的にはとーっても悪いやり方です。
>「暗黙の副作用」を作り出し、 問題が発生した時にデバッグするのを非常に難しくするからです。

701 ：

>>700
>>699

702 ：

>>697
> ベースライブラリへのモンキーパッチでどう互換性の問題が発生するんだい？
ベースライブラリはモンキーパッチを当てると、
ベースライブラリの挙動が変わる。
その結果、他のライブラリの挙動が変わる。
また、ベースライブラリ自体がバージョンアップした時、
そのような結果が起きるか想像できない。
いいことは何も起こらない。

703 ：

Prototype.jsが廃れていった原因の一つも
ベースライブラリへのモンキーパッチ。
そのせいでPrototype.js以外のライブラリが
正しく動かなくなるなどの問題が起きた。
Prototype.jsを組み込んで大丈夫か検証する必要があった。

704 ：

prototype.jsよりJqueryの方が書き易くて人気があって、
両方ともグローバル変数$を使ってたため共存が少し面倒だった
だからprototype.jsが廃れただけ

705 ：

ベースライブラリを書き換えなかったから、
jQueryの方が書きやすくなった。

706 ：

へーwww
じゃあソース書いて比較してみ？
「ここはベースクラスを書き換えてないから、こういう書きやすい書き方になった」って説明付きで
まあ、どうせできないだろうが

707 ：

一応、Prototype.jsの開発者もダメだったことは認めてて、
http://perfectionkills.com/whats-wrong-with-extending-the-dom/

要約すると
・決まった仕様が無く、DOM extensionに全てのブラウザが対応してるとは限らない（特にモバイル）
・IE 6,7やsafari 2.x などには特別の実装を用意して回避できるが、パフォーマンスが悪い
・ブラウザにバグがあり、思ったように動かないケースがある

Javascriptは古いブラウザも含む様々な処理系で動かす必要があるから、事情が特殊だよ
他の言語処理系と同じようには議論できない

708 ：

>>702
> その結果、他のライブラリの挙動が変わる。
まさに、それを目的としてパッチをあてるんだが
> また、ベースライブラリ自体がバージョンアップした時、
> そのような結果が起きるか想像できない。
パッチを当てなくても同じじゃん

709 ：

>>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 ：

RubyですらRails等サードパーティライブラリの互換性を壊さないように
気を使って機能追加してるのに、Javascriptは本当に終わってるなw

711 ：

終わってるのは、モンキーパッチだろｗ

712 ：

Java土方とかJavascript土方ってモンキーパッチも使いこなせないのか……
所詮はドカタか……

713 ：

バカは限度を知らないからな

714 ：

> PrototypeはあらゆるJavaScriptオブジェクトを変更する機能で有名でした。
強力な機能だからこそ、ここぞという所で使うんだよ。
でも馬鹿には0と1しか無いんだよね。
使うか使わないかの二択より難しいことは考えられない。

715 ：

で、どういうときにモンキーパッチ使うんだい？
それによる影響がないと確認するにはどうするんだい？
予知能力が必要になるな。

716 ：

もう上のほうで利用例が出てたと思うけど、
ドカタには縁がないから、君はそのままで良いよ
底辺は底辺らしくしてれば良いよ

717 ：

利用例が無理やりすぎ。
モンキーパッチを使わないで
正攻法を使ったほうがいい。
モンキーパッチは不具合の元。

718 ：

モンキーパッチはいざという時に取れる選択肢の一つだが
誰でも彼でも土方でもやっていいものではない。

719 ：

>>717
sockscap

720 ：

確かに、他に方法がなくてどうしようもない時だけだな。

721 ：

このスレって延々と論争してるけど、
結局のところ想定してるプログラマ像が違いすぎるのが原因だから
「ドカタに使わせるにはどんな言語が良いか」
というテーマなら速やかに合意に達すると思う

722 ：

Java一択、で話が終わってしまうんだが？

723 ：

COBOL もあるぜ
まあ、Javaは21世紀のCOBOLだけどな

724 ：

VBのことも忘れないで！

725 ：

>>709
なるほどー。JavaScriptはとくに絶賛成長中の言語だからな。
短期的にはよい結果をもたらすけれども、それが裏目にでることになるわけね。
なるほどー。

726 ：

>>721
なんでいつも職業プログラマを
目の敵にしてるの？

727 ：

Javaに +1

728 ：

ドカタならJava+eclipse+checkstyleでガチガチにするしかないな

729 ：

>>725
概してモンチーパッチの類を使うと将来の変化に弱くなる。
パッチを当てる相手(prototype.jsの場合はJavaScript)の変化に応じてパッチも更新する
必要があるし、パッチを当てた上に構築した成果物を将来拡張する場合も新たに導入する
ライブラリ等がパッチを当てた環境上でも動くか検証する手間が出てくる。

730 ：

そうそう、だからパッチを当てるのが不可能か、
難しい言語を使うのが望ましい
Javaとか

そう、ドカタはね

731 ：

局所的なスコープでだけパッチが有効になる仕組みについては
色々アプローチはあるんだけど、
どれもドカタには使いこなせないからなぁ……

732 ：

>>730
ヒント　ドカタって言う奴がドカタ

733 ：

ところで動的言語が遅いというのは都市伝説、性的言語より速くなりうると言ってた人たちって
型情報与えたらいきなり数倍速になったasm.jsをどう思ってるん

734 ：

だいたいこの1年くらいJavaScriptの速度の伸び完全に止まってるし
やれること全部やっちまったみたいな

735 ：

>>733
asm.jsってJavaScriptのサブセットだよ。
JavaScriptから動的型付け言語の性質を抜き去った
命令だけを使うことで速くできる。
asm.jsで書くと動的型付け言語のメリットがないのだから
やっぱり静的型付け言語の方が速いねという結論にしかならないよ。

736 ：

静的のほうが速いのはまず間違いない。ここは議論の余地なし。
静的の問題は開発環境が重く開発効率も非常に悪いこと。

737 ：

開発環境が重いと言ったって雀の涙程度の違いだし、
その重さ＝開発サポートのおかげで快適に開発できるし、
開発効率が悪いと思ってるのは
お前がテキストエディタで書こうとしてるからだ。

738 ：

テキストエディタで書けないから重いんだよ
むしろテキストエディタで書きたいぐらいだが
ビルドとか考えたら現実的じゃないしな

739 ：

なぜテキストエディタで書くのかわからない。
優秀な道具を使えよ。

740 ：

vimは超優秀

741 ：

静的言語はIDE使った方が便利なのはそうだけどビルドはあまり関係無いような気がするなぁ。
大きなプロジェクトほど依存性管理やビルドはIDE非依存でできるようにすると思うけど。
でないとCIとかやりにくい。

742 ：

JavaはEclipseでないとコンパイル出来ないドカタが山程居る
誇張じゃなく

743 ：

まあMavenだな。IDE使わずともビルドやテストはコマンド一発なのでテキストエディタ使用の
ドカタでも全然大丈夫。
ドカタがMavenプロジェクトを作れるかはまた別問題w MakeやAntよりは遙かに簡単だけど。

744 ：

コード少し直しただけでantだのmavenだの面倒くさすぎる
だから開発効率が悪い

745 ：

>>742
Javaは人間じゃないです。
なんで人間の問題なのに
Javaって言語の問題かのように言い方をするの？

746 ：

>>744
あんたantやmavenわかってないんじゃない？
あれはシステムrailsみたいに用意して少し設定すれば
勝手に裏でやってくれるもの
コード少し直した程度じゃ、何も触るところはない。

747 ：

面倒なのは間違いない。普段からJavaやってない人には初っ端からやる気を削ぐ。

748 ：

>>746
たとえ自動でもビルドとホットデプロイがかかるだろ
あれが面倒なんだよ
PHPやRubyならサクサク作れる

749 ：

>>748
おかげでRubyバグだらけじゃん

750 ：

RubyもRubyで互換性すぐ消えるし、互換性消えまくるから、バージョン違いのRubyを大量に管理する必要があって、
その為に管理ツールとかあるんだけど、その管理ツールすら互換性消えまくって、RVMはオワコンでこれからはrbenvの時代だなんだと際限なく学習を強いられる。

751 ：

互換性と型付けが関係あるとでも？

752 ：

そういや型付けがない言語のほうが
互換性低い気がする。
なんでだろう？

753 ：

D言語とSmalltalkを知ってると、とてもそうは思えないが……

754 ：

D言語とSmalltalkは単に使われてないだけかと。

755 ：

JavaもJarのバージョンの衝突は毎度悩まされるところだけど。

756 ：

pythonで後方互換性なくなったのは3kぐらいなものだと思うけど？

757 ：

iPhoneアプリ. Windowsアプリを売って生き残れ Ver 1.7 リンク数61
Hｔｔｐ:／／qr.　net/kh4y

758 ：

型システムのスレが無くてこんなスレしか無いとか2ch終わりやね

759 ：

>>758
先進なんだろう。

760 ：

>>754
Dはそこらのスクリプト以上に互換性が酷いからな…

761 ：

Dは動的バージョン付け言語だからな

762 ：

「主流」としか言えないことが悲しいな
なんで全てにおいて高性能なのに全てで使われないんだろうな
使い分けができないゴミには一生わからない問題だろうなあ

763 ：

主流？

764 ：

生産性は動的言語
保守性が静的言語

765 ：

>>764
今時のツールやフレームワーク、特にテスト関係や静的解析、IDEの補完機能や
他の色々な便利機能を考えると動的言語の方が生産性高いとは言えない。
一人で数十行程度の本来のスクリプトの用途で考えるならまだ動的言語の方が
高いかもしれないけどね。

766 ：

人にとっての使用感は圧倒的に動的言語
最終的には動的言語で静的言語のようなサポートができるようになるし
今もその方向で爆進している。静的言語が良いというのは機械の都合でしかない

767 ：

ついでに人間が書かなくても機械が勝手にプログラミングしてくれるようになるしな

768 ：

そこまでは無理だけど、もうJavaやC#のようなゴミ言語では
到底たどり着けないレベルまで動的言語の生産性は高まってる

769 ：

話の内容が全然具体的でないな。
まあ、いつものことだが (w

770 ：

まあ、コードの生産性だけなら動的が勝ってるわな
つーか、そこに特化したのが動的だし、それしか勝ってないんだけど

771 ：

ひとつの言語しか使えない低能を除くと、
適材適所で使い分けるのが最強という結論になる

772 ：

だな

773 ：

無理して一つの言語に固執せんでもってこったな
複雑な処理が必要だが今すぐぱっと答えが欲しい時、
あまりにも変化が激しすぎて開発速度が何よりも重要な時、
動的型付け言語の使い処はこんなところだよね

774 ：

設計どおりに作って一切のエラー発生させないのを理想とするウォーターフォールモデルで頭が固まった人にはわからないだろうが。
静的型付け言語はエラーをわざと発生させてそこを直していくという作業で
プログラムを構築することができる。慣れるとそれが結構効率的だったりする。
エラーとか例外とかいうからいけないんだな。そうじゃなくて開発手法として整理すべきと思う。

775 ：

>>774
言いたい事はわかるし、真意を汲めばこそ突っ込みたくは無いのだが…
「わざとエラーにする」ってのは日本語がおかしいぞ

776 ：

「わざとエラーにする」って誰が言ったの?

777 ：

わかりずらくてすまないな。主にコンパイルエラー。
実行時エラー(例外)を発生させるのは追いかけるのが大変だが一応ある。

778 ：

>>776
「エラーをわざと発生させる」って>>774が。
あの文脈だと「わざとエラーにする」と読める。
もちろん真意は、
間違えて組んだら、コンパイルエラーとなるように、意図的に仕込んでおく、
という事だと思うんだけどね。

779 ：

上流企業と底辺企業と一般人で、
カースト作りたいから変なもんを推す
PHP､JAVAとかマジでそれ
中には本気でそのゴミ使いやすいとかいっちゃうやついるから困る
企業戦略にハマりすぎてて見てて泣ける

780 ：

ほらわかりやすい釣りですよ。

781 ：

そういうことにしとけ
気づいてしまうと
今まで自分の足元にあった巨大なものと戦わなきゃなる

782 ：

わかるー

783 ：

まさかMS

784 ：

動的型付けだとデータが違っててたまたまうまく動作したのか、
データが正しくてうまく動作したのかわからないと思うの。
だから静的型付け言語の方が手戻りがすくなくてとっても生産性が高いと思うの。

785 ：

むしろ、その「たまたま上手く動いちゃう」を
最大限に使ってくのが動的型かと思う、だから設計も結構違うかと
静的なら最低限のものを用意して組み合わせさせたり
必要になったら、別の手段で出来ないか確認してから書くけど
動的型なら、テキトーに書いてもある程度動くように
どっさりと色んなアプローチを用意する形で書いてるわ
たまたま動いちゃうなら、そこはたまたまが正常に動いちゃうように書く感じ
(正常に見える、ではなく正常に動く、ね)
反対側と同じように書こうとすると上手くいかないと思うし
生産性も上がらないと思う

786 ：

機動性に優れているのが一番
一戸建て住宅　　　＝　静的型付け
キャンピングカー　＝　動的型付け

787 ：

>>785
正常に見えると正常に動くは相互に排他的である、ということではないのじゃないかな？
どうやって判断するの？

788 ：

テストを実行して引数が間違ってたけどたまたまパスしました。
正常に見えます。正常に動くことと区別することできないっすよね。

789 ：

なんだよ、たまたま動くとかテストに漏れがあるとか
静的、動的関係ないじゃんか。
静的が凄いのは、その名の通り静的であるということ。
コードが定義でできてる。
コードを動かすことなく決まるから、
実行させなくても、いろんな解析ができるということ。
実行時間0（解析時間だけ）で情報が得られる。
実行させればわかるというが、実行させるには時間がかかる。
実行しなければ状態が確定しないということは、
変数によって状態がいろいろ変わることがあるということ。
規模が大きくなればなるほど、いろんな状態によって
答えが変わる動的言語は、解析とテストが大変になる。

790 ：

>>789
静的型付けと動的型付けの比較をしてるんだから、
型付けによって改善できることを話してるんだって
読み取って欲しかったです。

791 ：

まあ、適材適所だね

792 ：

オレの感覚的には、20%の労力で80%の成果を得るのが動的
対して静的は80%の苦労で95%を得るものだな
勿論、どちらが絶対的に優れているというモノでは無いよね

793 ：

静的+自動型解析や動的+アノテーション辺りが一番良いと思ってる。

794 ：

>>792
その計算には、プロジェクトの規模が含まれてないだろ？
小さいものを作るときはいいかもしれんが、
数人以上で数ヶ月、ファイル・クラス数十個なんて
ものを作るとき、保守性が悪いのが動的言語だよ。

795 ：

>>794
そんな当たり前のことをレスされても

796 ：

>>795
それが当たり前なら対価の割合なんて一概に言えないじゃないか

797 ：

効率を犠牲にしてわすかな完成度向上を絞りださざるを得ない
それが大規模プロジェクトの宿命
つまり >>791-792 でFA

798 ：

大規模プロジェクトと呼ばれるものの大半は
ゴミを集めて人数が膨れ上がったプロジェクトを意味する
ゴミだから動的な特性なんて使いこなせないし、テストも書かないので
静的型チェックによる僅かな品質向上に望みをかけるしか無い

799 ：

>>798
ワロタ
真実かもなw

800 ：

例えばJavaにはローカル変数は初期化しなくても良いが
初期化せずに参照するとコンパイルエラーで弾かれる特徴がある
この機能を活用することでバグの混入を未然に防げるのだけど
土方はとりあえず初期化しちゃうから後々デバッガで追いかけることになる

801 ：

>>800
つまり、Javaではローカル変数を初期化しないのがベストプラクティスで
あるということか？

802 ：

初期化のための初期化でゴミを入れるなってこと

803 ：

>>802
初期値が間違ってるってことねなるほど。
変数は必要になったときに宣言するようにすれば問題ない。

804 ：

>>801
文脈として初期値が必要なケースでなければね
例えば以下の例はエラーになる。
以下の例は例外が起きたら別の処理を行ってから再び例外を投げたいものとする。
String value;
try {
    value = ...
} catch (Exception ex) {
    doSomething();
}
AnyClass obj = new AnyClass(value);
...
これは仮に value を null で初期化してたら
コンパイラがやってくれるチェックを自分ですることになる。

805 ：

>>804
うーん？
間違った初期値を設定することが問題なんだよね？
だったら初期値なんか書くなと言うのは論点がおかしくないか？

806 ：

ローカル変数だけしかチェックできないウンコじゃん
静的型言語の面汚しだよね

807 ：

フィールドはdefaultで初期化されるからな

808 ：

>>805
初期化してないとコンパイラが止めるんだよ
その止めるという機能が恩恵にあずかっている機能
throw exで再度例外を投げればコンパイルエラーにはならない
つまり正常系のみ処理が進むことが保証される

809 ：

そのコードがどういう状況で到達可能なのかをJavaコンパイラはある程度理解している
到達不可能ケースで未初期化変数を参照してもコンパイラは無視するし問題にもならない

810 ：

>>807
ぬるぽですね

811 ：

どのみちオラクルの手に渡った時点でおわこんだよ

812 ：

オラコン

813 ：

預言者オワクル

814 ：

オリハルコン

815 ：

　
＼＼
＼＼＼
＼　 ∧＿∧
　 　（ ´・ω・）
　 　G　 　と）　ｶﾞｯ >>810
　 　 ヽ⌒)､ ＼人∧__∧
　 　　 ￣　（＿） >｀д´）')
　　　　　　　　 ∨つ　　 /

816 ：

F#の生産性が高すぎて人生が辛い(´・ω・｀)

817 ：

お前らバイトです
がんばってください
暑いならビール

818 ：

そんなにF#いいのん？

819 ：

すごいHaskell
もっとすごいF#

820 ：

言語的にはHaskellやLispの方がイイかもだけどC#よりははるかに上。
IDEとかライブラリ含めた総合力ではトップクラスだと思う

821 ：

>>820
HaskellとかLispのどこがいいんだよ

822 ：

Webサービスか
それともスクリプトから呼ばれるライブラリか

823 ：

F#は実行時に決まる部分が多すぎだろ。
.NETの呪縛から逃げ切れてない。

824 ：

だな、コンパイル終了の時点で要求メモリ量が分からないなんて、
大規模計算処理では使い物にならん
この条件を満たすのは COBOL/FORTRAN/C などで、
これらはどれも実世界の社会インフラを支える本物のプログラミング言語だ
JavaやらC#みたいな実行時にメモリを割り当て、
そのあげくに不要になったゴミ回収が必要になるなんて、
これらがお子様むけのオモチャ言語である証拠だ


こうですか？よくわかりません　........

825 ：

>>823
どのへん？OCamlだとその辺は良いもんなん？

826 ：

>>825
Ocamlは知らん。
F#は型の取り扱いがJavaみたいで面倒。

827 ：

Ocamlって岡村って人が作った言語ですか？

828 ：

そうです。
同様の言語にMTsumt(通称Ruby)があります。

829 ：

>>826
何がJavaみたいなんだか分からん。イイと思う言語とのひかくでよろ

830 ：

Lispはゴミ
いまどきLispなんて使っているバカは頭がクルクルパー

831 ：

Clojourならどうよ

832 ：

名前も覚えられないのに勧めるなんて

833 ：

一時期clojureのステマが酷かったけど
全然流行らなかったな

834 ：

>>832
ケツの穴のちいせぇ男だな( ´Д`)y━･~~
>>883
まぁアレは番人が使うものではないんじゃないか。使う人は使ってるでしょ。

835 ：

>>833
Lispが流行る(一般プログラマに受け入れられる)わけねーじゃん
あれはClojureのステマじゃなくてjvm言語ステマの一環です

836 ：2013/09/02

>>834
安価もまともに打てないのに勧めるなんて