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

276 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)