1001コメント355KB

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

レス数が1000を超えています。これ以上書き込みはできません。

0001デフォルトの名無しさん

2013/03/03(日) 18:17:29.51

人間がやっていたことを、コンピュータにやらせる。
これが生産性を上げる最大の方法。
コンピュータは間違わない、同じ事を何度も高速に行える。

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

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

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

0002デフォルトの名無しさん

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.

0003デフォルトの名無しさん

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.の戻り値が返される"

ね。簡単でしょ。

0004デフォルトの名無しさん

2013/03/03(日) 18:37:41.49

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

0005デフォルトの名無しさん

2013/03/03(日) 18:41:06.37

主張してる内容は真逆なのに、何故か同じ奴が立てたような気がしてならない
そんな低レベルなスレ

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

0006デフォルトの名無しさん

2013/03/03(日) 18:45:21.02

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

0007デフォルトの名無しさん

2013/03/03(日) 18:47:01.43

いいよココが隔離スレで

0008デフォルトの名無しさん

2013/03/03(日) 18:48:15.22

前スレ

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

0009デフォルトの名無しさん

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/

0010デフォルトの名無しさん

2013/03/03(日) 19:09:20.53

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

0011デフォルトの名無しさん

2013/03/03(日) 19:33:07.93

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

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

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

0012デフォルトの名無しさん

2013/03/03(日) 20:30:04.87

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

0013デフォルトの名無しさん

2013/03/03(日) 21:50:03.33

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

0014デフォルトの名無しさん

2013/03/04(月) 03:52:56.47

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

0015デフォルトの名無しさん

2013/03/04(月) 11:03:43.44

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

0016デフォルトの名無しさん

2013/03/04(月) 19:19:35.72

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

0017デフォルトの名無しさん

2013/03/05(火) 13:31:49.84

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

0018デフォルトの名無しさん

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
}

0019デフォルトの名無しさん

2013/03/05(火) 21:51:40.59

行の並び替えは、出来る場合と出来ない場合がある。
実はコンパイラの最適化ではこのような行の入れ替えが行われている。

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

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

0020デフォルトの名無しさん

2013/03/06(水) 00:19:57.55

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

0021デフォルトの名無しさん

2013/03/06(水) 02:29:41.97

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

0022デフォルトの名無しさん

2013/03/06(水) 03:36:21.75

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

0023デフォルトの名無しさん

2013/03/06(水) 16:54:29.20

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

0024デフォルトの名無しさん

2013/03/06(水) 19:14:01.69

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

0025デフォルトの名無しさん

2013/03/07(木) 08:48:36.37

動的言語の時代ｸﾙ━━━━━━(ﾟ∀ﾟ)━━━━━━ !?
って展開は確かにあったけど、結局性的言語持ちこたえてんじゃん。
http://www.tiobe.com/content/paperinfo/tpci/images/history_paradigm_type%20system.png

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

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

0026デフォルトの名無しさん

2013/03/07(木) 12:31:27.70

言っちゃ悪いけどPerl云々で始まった型についての記事なんて
最終的に自分の好みと自分の狭い世界での経験を話しをしてるばかりで
読み物としても大した参考にならんかったわ

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

0027デフォルトの名無しさん

2013/03/07(木) 12:34:26.57

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

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

0028デフォルトの名無しさん

2013/03/07(木) 18:42:33.27

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

0029デフォルトの名無しさん

2013/03/07(木) 20:21:43.04

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

0030デフォルトの名無しさん

2013/03/10(日) 03:38:11.26

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

0031デフォルトの名無しさん

2013/03/10(日) 05:55:02.66

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

0032デフォルトの名無しさん

2013/03/10(日) 06:30:25.98

型に拘るメリットが多いのが大規模で、
拘るメリットが少ないのが小規模ってことだよ。

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

0033デフォルトの名無しさん

2013/03/10(日) 06:37:51.01

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

003433

2013/03/10(日) 06:45:36.36

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

0035デフォルトの名無しさん

2013/03/10(日) 07:11:01.16

>>34で訂正している気がするがまあ無視するとしてｗ

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

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

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

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

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

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

0036デフォルトの名無しさん

2013/03/10(日) 07:27:22.87

小規模だと、書く（タイプする）速度が重要になるが、
大規模だと、読む（理解する）速度のほうが重要なんだよね。

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

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

0037デフォルトの名無しさん

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());
}

0038デフォルトの名無しさん

2013/03/10(日) 09:11:07.14

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

0039デフォルトの名無しさん

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が
タコと言うだけであって静的型とはあまり関係がないと思う。

0040デフォルトの名無しさん

2013/03/10(日) 12:54:22.31

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

0041デフォルトの名無しさん

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

0042デフォルトの名無しさん

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)}
}

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

0043デフォルトの名無しさん

2013/03/10(日) 17:14:30.02

勝手に>>42付け加えるなら、記述量と読みやすさはあまり関係がない。

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

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

0044デフォルトの名無しさん

2013/03/10(日) 17:15:42.47

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

0045デフォルトの名無しさん

2013/03/10(日) 17:20:01.54

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

0046デフォルトの名無しさん

2013/03/10(日) 17:22:08.92

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

0047デフォルトの名無しさん

2013/03/10(日) 17:25:06.61

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

0048デフォルトの名無しさん

2013/03/10(日) 17:36:24.43

型を含めた定義部分は、じっくり読むようなところじゃないってこと。
ちらっと見て、脳の短期記憶領域にさっと入れれば終わり。

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

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

0049デフォルトの名無しさん

2013/03/10(日) 17:42:14.18

>>45
Grooby2.0からクラスやメソッド単位で静的な型チェックを強制できるようになった
ので、クロージャの引数や返り値も静的に検証させたり推測させたり出来るよ。

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

ようするに、ActionScript3さいこ～

0050デフォルトの名無しさん

2013/03/10(日) 21:21:41.33

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

0051デフォルトの名無しさん

2013/03/10(日) 21:52:10.06

>>50
>敢えて動的型付を使う理由はない。

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

0052デフォルトの名無しさん

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

0053デフォルトの名無しさん

2013/03/10(日) 22:30:52.59

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

0054デフォルトの名無しさん

2013/03/10(日) 22:50:15.85

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

0055デフォルトの名無しさん

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())

0056デフォルトの名無しさん

2013/03/10(日) 23:17:57.78

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

0057デフォルトの名無しさん

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]

0058デフォルトの名無しさん

2013/03/10(日) 23:25:10.63

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

0059デフォルトの名無しさん

2013/03/10(日) 23:28:44.50

突然の Python3 vs Squeak Smalltalk ！

0060デフォルトの名無しさん

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())

0061デフォルトの名無しさん

2013/03/10(日) 23:30:13.75

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

0062デフォルトの名無しさん

2013/03/10(日) 23:41:20.07

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

0063デフォルトの名無しさん

2013/03/10(日) 23:50:59.76

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

0064デフォルトの名無しさん

2013/03/11(月) 00:24:00.19

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

0065デフォルトの名無しさん

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.''

0066デフォルトの名無しさん

2013/03/11(月) 00:41:30.53

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

0067デフォルトの名無しさん

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();

0068デフォルトの名無しさん

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(" "))}

0069デフォルトの名無しさん

2013/03/11(月) 01:08:18.73

>>66
おいおい、どこのバカに教わったか知らんが勝手に無くすなよ！ｗ
ファイルの扱いなんざSmalltalk-80の前身のそのまた前身のSmalltalk-72から普通にあるぞ。

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

0070デフォルトの名無しさん

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
　"固有処理"

0071デフォルトの名無しさん

2013/03/11(月) 01:12:54.53

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

0072デフォルトの名無しさん

2013/03/11(月) 01:43:33.68

>.70
Javaで委譲ってかったるい？

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

0073デフォルトの名無しさん

2013/03/11(月) 01:50:35.72

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

0074デフォルトの名無しさん

2013/03/11(月) 01:52:28.19

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

0075デフォルトの名無しさん

2013/03/11(月) 01:55:18.87

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

0076デフォルトの名無しさん

2013/03/11(月) 01:59:44.37

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

0077デフォルトの名無しさん

2013/03/11(月) 02:09:33.75

JavaBeanswww

0078デフォルトの名無しさん

2013/03/11(月) 02:13:03.54

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

0079デフォルトの名無しさん

2013/03/11(月) 03:22:27.56

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

0080デフォルトの名無しさん

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"

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

0081デフォルトの名無しさん

2013/03/11(月) 04:56:10.55

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

0082デフォルトの名無しさん

2013/03/11(月) 04:57:10.40

ただの慣れだろｗ

0083デフォルトの名無しさん

2013/03/11(月) 04:57:54.94

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

0084デフォルトの名無しさん

2013/03/11(月) 05:53:12.61

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

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

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

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

0085デフォルトの名無しさん

2013/03/11(月) 05:54:57.90

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

0086デフォルトの名無しさん

2013/03/11(月) 06:00:05.97

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

0087デフォルトの名無しさん

2013/03/11(月) 06:01:33.19

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

0088デフォルトの名無しさん

2013/03/11(月) 06:02:05.47

>>81
どの辺が具体的にノイズだろう? 委譲自体は基本的に次の一行で簡潔していて、Thinという
インターフェイスに定義されたJavaで言うところのメソッドの扱いがthinに委譲されている。

@Delegate private Thin thin;

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

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

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

0089デフォルトの名無しさん

2013/03/11(月) 06:03:56.58

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

0090デフォルトの名無しさん

2013/03/11(月) 06:19:53.95

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

0091デフォルトの名無しさん

2013/03/11(月) 06:27:34.29

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

0092デフォルトの名無しさん

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()の実装だけ持っている。

0093デフォルトの名無しさん

2013/03/11(月) 06:41:03.58

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

0094デフォルトの名無しさん

2013/03/11(月) 06:56:35.08

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

0095デフォルトの名無しさん

2013/03/11(月) 07:01:56.53

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

0096デフォルトの名無しさん

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

0097デフォルトの名無しさん

2013/03/11(月) 07:13:57.99

委譲先に変更があってもインターフェイスが変わらない限り変更があった委譲先だけの
再コンパイルだし、委譲する側に変更があっても委譲先の再コンパイルは必要ないよ。

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

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

0098デフォルトの名無しさん

2013/03/11(月) 07:22:44.46

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

0099デフォルトの名無しさん

2013/03/11(月) 07:55:19.21

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

0100デフォルトの名無しさん

2013/03/11(月) 07:57:47.03

>>84
Java

http://ideone.com/yEqYUC

0101デフォルトの名無しさん

2013/03/11(月) 08:13:15.63

普通にJavaが最強の件

0102デフォルトの名無しさん

2013/03/11(月) 08:53:20.04

>>99
>新しいinterface間同士の委譲が必要になったら、
>その都度class作ってSelectorDを書かなきゃならんのか？

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

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

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

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

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

0103デフォルトの名無しさん

2013/03/11(月) 13:01:01.87

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

0104デフォルトの名無しさん

2013/03/11(月) 13:03:46.85

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

0105デフォルトの名無しさん

2013/03/11(月) 14:18:12.86

>>86
Common Lisp (SBCL)
Intel(R) Celeron(R) CPU 867 @ 1.30GHz

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

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

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

$ time ./pi
3.1412177

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

0106デフォルトの名無しさん

2013/03/11(月) 15:53:26.37

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

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

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

てのがあったら、

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

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

0107デフォルトの名無しさん

2013/03/11(月) 22:07:18.91

>>99
それってさ、重要なところは

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

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

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

0108デフォルトの名無しさん

2013/03/11(月) 22:36:20.93

>>84
VisualWorks Smalltalk, 3.95s, 2.4GHz Core i7
（同環境での>>100のJavaは 1.53s）

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

0109デフォルトの名無しさん

2013/03/12(火) 08:27:53.86

>>107
今一言ってることが判らないからJava方式のinterfaceに
追加できないって問題だけに答えてみる。
JavaやってるならJTextFieldとJFrameって知ってるよね
あれのsetTextって動作同じなのにinterface共有してないから
JTextFieldとJFrameをおなじ関数で処理できないんだ。かと言ってJTextFieldとJFrameに別のinterface追加したり、
既に実装しているinterfaceに関数追加できないのは解るでしょ。
Beansでも使うか新たにinterfacesを実装した派生classを作るとか
面倒なことしなきゃいけない。

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

0110デフォルトの名無しさん

2013/03/12(火) 08:37:34.53

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

0111デフォルトの名無しさん

2013/03/12(火) 08:48:45.98

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

0112デフォルトの名無しさん

2013/03/12(火) 12:42:09.28

>>110
それ結論でいいよ

0113デフォルトの名無しさん

2013/03/12(火) 12:57:05.69

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

0114デフォルトの名無しさん

2013/03/12(火) 22:03:55.39

>>109
> あれのsetTextって動作同じなのにinterface共有してないから
> JTextFieldとJFrameをおなじ関数で処理できないんだ。

それは一長一短でしょ？

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

0115デフォルトの名無しさん

2013/03/12(火) 22:09:55.37

>>109
> あれのsetTextって動作同じなのにinterface共有してないから
> JTextFieldとJFrameをおなじ関数で処理できないんだ。かと言ってJTextFieldとJFrameに別のinterface追加したり、

１．オーバーロードを使う。
２．Object型を使う。
３．GenericsでJTextFieldまたはJFrame用の関数を生成する
４．Adapter パターンを使う

0116デフォルトの名無しさん

2013/03/12(火) 22:15:41.57

同じsetTextだからって同じ動作をするとは限らないからねぇ。

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

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

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

0117デフォルトの名無しさん

2013/03/12(火) 22:20:49.19

実はVB6がこの問題をうまく解決している。
（継承はできないという問題はあるけれど）

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

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

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

0118デフォルトの名無しさん

2013/03/12(火) 22:36:30.87

DuckTypeが使えるRhinoつかうとすげぇ楽だった

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

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

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

0119デフォルトの名無しさん

2013/03/12(火) 22:38:11.07

>>115他の言語ならせずに済むそんな事をせにゃならんのがめんどくせぇ。

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

0120デフォルトの名無しさん

2013/03/12(火) 22:39:11.20

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

0121デフォルトの名無しさん

2013/03/12(火) 22:49:22.50

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

0122デフォルトの名無しさん

2013/03/12(火) 22:53:10.58

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

0123デフォルトの名無しさん

2013/03/12(火) 22:56:07.88

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

0124デフォルトの名無しさん

2013/03/12(火) 22:56:57.74

やっぱり>>110でFA

012533

2013/03/12(火) 23:09:20.08

>>124
ALGOLのことだね。

0126デフォルトの名無しさん

2013/03/13(水) 00:28:38.48

>>117
下策じゃん。

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

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

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

0127デフォルトの名無しさん

2013/03/13(水) 06:04:18.45

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

0128デフォルトの名無しさん

2013/03/13(水) 08:53:09.78

>>126
マシじゃないよ。

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

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

foo.setText
bar.setText

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

0129デフォルトの名無しさん

2013/03/13(水) 09:10:14.38

VB6だと
TextWithLabel text = ラベル付きテキスト

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

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

実にスッキリ

0130デフォルトの名無しさん

2013/03/13(水) 13:46:38.13

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

0131デフォルトの名無しさん

2013/03/13(水) 15:11:36.55

Duck typingとStructual typeは区別するべきだと思うのね。

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

0132デフォルトの名無しさん

2013/03/13(水) 21:05:36.43

>>130
本当にどんな型でも扱えるクラスってのは他のオブジェクトを
格納するだけのコンテナぐらいしかない。たいていは特定の型でしか動かないコードになってる。
人間が型を意識しているのに型を書かないなんてただの手抜きだよ。

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

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

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

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

0133デフォルトの名無しさん

2013/03/13(水) 22:33:43.25

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

0134デフォルトの名無しさん

2013/03/13(水) 23:05:30.37

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

0135デフォルトの名無しさん

2013/03/13(水) 23:13:53.93

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

0136デフォルトの名無しさん

2013/03/13(水) 23:21:21.23

>>135
autoやvarは関数の引数には使えないでしょ？

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

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

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

0137デフォルトの名無しさん

2013/03/13(水) 23:24:03.30

function foo(value) {
　value.hoge();
　bar(value);
　value.hage();
}

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

0138デフォルトの名無しさん

2013/03/13(水) 23:26:37.73

>>136
ライブラリ側の事を言ってるの？
実装にジェネリクスが使えるなら、使わない理由はないし、
使う方も、ジェネリクスなら型を明示する必要はあまりないと思うよ。
また、できる限りそうあるべきだと、俺は思う。

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

0139デフォルトの名無しさん

2013/03/13(水) 23:51:08.23

メソッド名が被るとか、見ても分からないとかナンセンスすぎ
他と被りようがない一意な名前を付ければ良いじゃない
例えば

IterativeDeepeningAlphaBetaSearchUsingKillerMoveOrderingAndTranpositionTableSimpleMaterialAndPositionalEvaluationChooseRandomlyBetweenBestMovesStrategy

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

0140デフォルトの名無しさん

2013/03/14(木) 00:07:28.79

>>139
賛成。

0141デフォルトの名無しさん

2013/03/14(木) 00:31:11.75

>>139
満足した？

0142デフォルトの名無しさん

2013/03/14(木) 06:47:24.14

Javaってウンコだね

0143デフォルトの名無しさん

2013/03/14(木) 06:57:30.13

いまさら言うまでもない

0144デフォルトの名無しさん

2013/03/14(木) 07:32:26.38

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

0145デフォルトの名無しさん

2013/03/14(木) 07:52:31.90

ググったらJavaのコードだったから
Java使いなら分かるんだろう

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

0146デフォルトの名無しさん

2013/03/14(木) 08:49:49.31

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

0147デフォルトの名無しさん

2013/03/14(木) 09:17:01.64

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

0148デフォルトの名無しさん

2013/03/14(木) 09:20:03.70

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

014933

2013/03/14(木) 11:41:07.51

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

015033

2013/03/14(木) 11:49:42.53

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

0151デフォルトの名無しさん

2013/03/14(木) 18:08:29.45

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

0152デフォルトの名無しさん

2013/03/14(木) 21:31:29.44

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

0153デフォルトの名無しさん

2013/03/14(木) 21:52:23.81

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

0154デフォルトの名無しさん

2013/03/14(木) 21:53:32.66

同じぐらいの人数でやったら
型がない言語のほうがもっとデスマになるね。

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

0155デフォルトの名無しさん

2013/03/14(木) 21:58:40.61

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

0156デフォルトの名無しさん

2013/03/14(木) 22:03:15.09

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

0157デフォルトの名無しさん

2013/03/14(木) 22:36:18.27

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

0158デフォルトの名無しさん

2013/03/14(木) 22:45:59.80

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

0159デフォルトの名無しさん

2013/03/14(木) 22:59:30.76

動的型付け言語にインターフェースが
ないと思ってるの？

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

0160デフォルトの名無しさん

2013/03/14(木) 23:24:58.98

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

0161デフォルトの名無しさん

2013/03/14(木) 23:59:16.06

>>160
実行時に型チェックするぐらいなら
実行前に型チェックすればいいじゃないか。

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

0162デフォルトの名無しさん

2013/03/15(金) 04:50:08.65

>>161
ぷ

0163デフォルトの名無しさん

2013/03/15(金) 04:53:18.10

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

0164デフォルトの名無しさん

2013/03/15(金) 07:41:31.39

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

0165デフォルトの名無しさん

2013/03/15(金) 08:33:43.67

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

0166デフォルトの名無しさん

2013/03/15(金) 16:07:41.54

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

0167デフォルトの名無しさん

2013/03/15(金) 22:21:00.97

型とかあんま難しく考えなくていいんだよ。
あんなのコメントと一緒。

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

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

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

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

0168デフォルトの名無しさん

2013/03/16(土) 04:30:42.77

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

0169デフォルトの名無しさん

2013/03/16(土) 05:22:17.54

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

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

0170デフォルトの名無しさん

2013/03/16(土) 12:26:45.35

>>169
型チェックが走るかどうかが問題なのではなくて、
それがいつ走るかが問題なのでは？

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

0171デフォルトの名無しさん

2013/03/16(土) 14:15:58.49

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

0172デフォルトの名無しさん

2013/03/16(土) 15:48:35.32

>>170
型チェックはそれだけではテストとして不十分なので
自動テストを走らせる必要がある

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

0173デフォルトの名無しさん

2013/03/16(土) 15:58:28.46

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

0174デフォルトの名無しさん

2013/03/16(土) 16:04:44.21

>>172
自動テストって自分で書かないといけないものってわかってないのかな？
自分で書く以上、ミスは生じるものだよね。

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

0175デフォルトの名無しさん

2013/03/16(土) 16:05:27.92

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

0176デフォルトの名無しさん

2013/03/16(土) 16:07:24.91

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

0177デフォルトの名無しさん

2013/03/16(土) 16:08:04.43

テストってのは仕様とあっているかを調べるもの。
だから仕様と違っていたとしても、プログラムは動く。
動くから、人間がテストを書かないといけない。

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

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

0178デフォルトの名無しさん

2013/03/16(土) 16:08:42.11

>>175
見つけられるタイポがあるだけ。

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

0179デフォルトの名無しさん

2013/03/16(土) 16:10:29.31

>>176
> 型チェックは不完全なものなので、型だけ厳密でも意味ないんだわ

いや、当たり前だろ。

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

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

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

0180デフォルトの名無しさん

2013/03/16(土) 16:11:03.80

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

0181デフォルトの名無しさん

2013/03/16(土) 16:12:05.41

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

0182デフォルトの名無しさん

2013/03/16(土) 16:14:03.28

コンパイルチェックをテストだと思うからダメなんだわ。

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

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

0183デフォルトの名無しさん

2013/03/16(土) 16:15:16.77

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

0184デフォルトの名無しさん

2013/03/16(土) 16:15:46.91

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

0185デフォルトの名無しさん

2013/03/16(土) 16:17:51.11

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

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

0186デフォルトの名無しさん

2013/03/16(土) 16:18:08.39

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

簡単に図式化してみた。

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

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

0187デフォルトの名無しさん

2013/03/16(土) 16:19:45.54

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

0188デフォルトの名無しさん

2013/03/16(土) 16:20:37.15

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

0189デフォルトの名無しさん

2013/03/16(土) 16:21:06.99

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

0190デフォルトの名無しさん

2013/03/16(土) 16:22:09.79

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

0191デフォルトの名無しさん

2013/03/16(土) 16:23:51.48

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

0192デフォルトの名無しさん

2013/03/16(土) 16:26:35.52

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

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

0193デフォルトの名無しさん

2013/03/16(土) 16:27:33.78

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

0194デフォルトの名無しさん

2013/03/16(土) 16:30:34.06

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

0195デフォルトの名無しさん

2013/03/16(土) 16:35:48.15

>>187
中身は関数型でも動的型でも何でも良い。ただライブラリを書く人間は外面のAPIはちゃんと
型付きで厳格な形で提供して欲しい。

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

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

0196デフォルトの名無しさん

2013/03/16(土) 16:39:34.93

ユニットテストっていうのは、間違いを見つけるのは簡単だけど、
その間違いを修正するデバッグ行為は楽ではないんだよ。

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

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

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

0197デフォルトの名無しさん

2013/03/16(土) 16:40:12.87

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

0198デフォルトの名無しさん

2013/03/16(土) 16:42:42.26

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

0199デフォルトの名無しさん

2013/03/16(土) 16:43:22.01

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

0200デフォルトの名無しさん

2013/03/16(土) 16:45:17.79

http://nodejs.jp/nodejs.org_ja/docs/v0.4/api/repl.html

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

0201デフォルトの名無しさん

2013/03/16(土) 16:47:02.86

http://labs.timedia.co.jp/2011/12/rubyist-should-use-pry.html

簡易デバッガとして使う

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

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

0202デフォルトの名無しさん

2013/03/16(土) 16:53:14.96

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

0203デフォルトの名無しさん

2013/03/16(土) 16:56:02.10

どうでもいいけど、ソフトウェアの開発っていうのは
0から作ることはほとんどなくて、
既存の何かの修正なんだよね。

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

0204デフォルトの名無しさん

2013/03/16(土) 17:03:08.09

どうでもいいけど、Javaドカタの言う「ちゃんとした開発」ってのは
ネットからサンプルコードをコピってきて
フレームワークの穴埋めするだけなんだよね

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

0205デフォルトの名無しさん

2013/03/16(土) 17:03:42.76

>>202
そうだね。

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

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

0206デフォルトの名無しさん

2013/03/16(土) 17:08:12.75

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

0207デフォルトの名無しさん

2013/03/16(土) 17:13:19.10

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

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

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

0208デフォルトの名無しさん

2013/03/16(土) 18:11:45.68

>>205
> Cで書かれたライブラリを使うのにSWIGを使うとは言え言語ごとにラッパー書くのは
> 未だに面倒だし、

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

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

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

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

0209デフォルトの名無しさん

2013/03/16(土) 18:16:15.02

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

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

0210デフォルトの名無しさん

2013/03/16(土) 19:41:54.38

>>178
え？今時メソッドのタイポも見つけられないIDEがあるの？

具体的に挙げてみてよ

0211デフォルトの名無しさん

2013/03/16(土) 19:44:08.15

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

0212デフォルトの名無しさん

2013/03/16(土) 19:51:49.41

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

0213デフォルトの名無しさん

2013/03/16(土) 19:52:46.93

間違えた>>202だった

0214デフォルトの名無しさん

2013/03/16(土) 20:22:05.66

SmalltalkはJVMや.NET、UNIX等の
エコシステムから取り残された箱庭言語

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

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

0215デフォルトの名無しさん

2013/03/16(土) 21:10:32.97

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

0216デフォルトの名無しさん

2013/03/16(土) 21:11:53.33

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

0217デフォルトの名無しさん

2013/03/16(土) 21:15:48.25

>>208
ただ最近は意識しないで使っていたライブラリもソース引っ張ってきて開けてみればscala
でしたってパターンも多い。

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

0218デフォルトの名無しさん

2013/03/16(土) 21:33:41.32

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

0219デフォルトの名無しさん

2013/03/16(土) 21:38:12.10

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

0220デフォルトの名無しさん

2013/03/16(土) 21:46:06.33

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

0221デフォルトの名無しさん

2013/03/16(土) 22:07:51.46

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

0222デフォルトの名無しさん

2013/03/16(土) 22:20:21.94

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

0223デフォルトの名無しさん

2013/03/16(土) 22:35:12.88

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

0224デフォルトの名無しさん

2013/03/16(土) 22:59:09.63

>>223
う～んとね。何に驚いたかというと言語混在モジュールので(あとメインの担当は
Javaなので)Eclipse上にプロジェクト作ってJava、C、Pythonと全部突っ込んで
開発したのだけれども(Erlangは他の人の担当)、言い方は悪いけれども普通に
使えたのに驚いた。

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

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

0225デフォルトの名無しさん

2013/03/16(土) 23:01:12.30

> 代入時の行を見て型もある
> 程度推測してくれる。名前変更程度のリファクタリングも小さいプロジェクト内で
> あれば実用的な範囲で出来る。

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

0226デフォルトの名無しさん

2013/03/16(土) 23:09:12.65

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

0227デフォルトの名無しさん

2013/03/16(土) 23:17:31.31

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

0228デフォルトの名無しさん

2013/03/16(土) 23:45:00.92

>>226
ローカルでもレキシカルでもいいけど、
範囲が狭いなら、それは人力でもなんとかなるんだよね。

問題は広い範囲。

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

0229デフォルトの名無しさん

2013/03/17(日) 00:24:21.46

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

0230デフォルトの名無しさん

2013/03/17(日) 00:34:55.85

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

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

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

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

0231デフォルトの名無しさん

2013/03/17(日) 00:40:27.30

>>230
レキシカルスコープの対比がファイルスコープかよ。
馬鹿すぎて卒倒しそうだわ。

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

0232デフォルトの名無しさん

2013/03/17(日) 00:41:34.20

>>229
> ローカルでもレキシカルでもどっちでもいいって、ホントにプログラマの発言かよ。

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

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

0233デフォルトの名無しさん

2013/03/17(日) 00:42:33.90

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

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

0234デフォルトの名無しさん

2013/03/17(日) 00:48:22.88

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

0235デフォルトの名無しさん

2013/03/17(日) 01:01:18.58

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

0236デフォルトの名無しさん

2013/03/17(日) 01:25:42.35

> ローカルでもレキシカルでもいいけど、
> 範囲が狭いなら、それは人力でもなんとかなるんだよね。

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

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

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

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

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

0237デフォルトの名無しさん

2013/03/17(日) 01:56:38.77

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

0238デフォルトの名無しさん

2013/03/17(日) 02:30:58.24

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

0239デフォルトの名無しさん

2013/03/17(日) 02:33:07.85

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

0240デフォルトの名無しさん

2013/03/17(日) 02:50:57.96

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

0241デフォルトの名無しさん

2013/03/17(日) 02:55:33.37

Ruby、PHP、Perlあたりだな。

0242デフォルトの名無しさん

2013/03/17(日) 06:46:01.54

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

0243デフォルトの名無しさん

2013/03/17(日) 08:05:36.52

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

0244デフォルトの名無しさん

2013/03/17(日) 13:07:35.32

静的有効範囲( Lexical scope, also Static scope )
http://whatis.techtarget.com/definition/lexical-scoping-static-scoping

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

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

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

0245デフォルトの名無しさん

2013/03/17(日) 13:13:03.09

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

0246デフォルトの名無しさん

2013/03/17(日) 13:21:07.42

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

0247デフォルトの名無しさん

2013/03/17(日) 13:22:15.64

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

0248デフォルトの名無しさん

2013/03/17(日) 13:26:29.26

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

0249デフォルトの名無しさん

2013/03/17(日) 13:27:33.07

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

0250デフォルトの名無しさん

2013/03/17(日) 13:28:26.15

>>247

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

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

0251デフォルトの名無しさん

2013/03/17(日) 13:29:18.48

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

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

0252デフォルトの名無しさん

2013/03/17(日) 13:30:36.04

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

0253デフォルトの名無しさん

2013/03/17(日) 13:31:39.73

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

0254デフォルトの名無しさん

2013/03/17(日) 13:31:49.24

>>252

foo(KURASU1)
foo(KURASU2)

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

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

0255デフォルトの名無しさん

2013/03/17(日) 13:33:03.40

foo(KURASU1)
foo(KURASU2)

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

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

0256デフォルトの名無しさん

2013/03/17(日) 13:33:59.41

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

0257デフォルトの名無しさん

2013/03/17(日) 13:35:20.67

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

0258デフォルトの名無しさん

2013/03/17(日) 13:35:28.91

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

0259デフォルトの名無しさん

2013/03/17(日) 13:36:09.88

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

0260デフォルトの名無しさん

2013/03/17(日) 13:37:48.45

>>259
じゃあやってみせてよｗ

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

0261デフォルトの名無しさん

2013/03/17(日) 13:38:59.48

>>256
ばか？
コード補完に信頼性がないんじゃなくて
実際言語仕様的にそういうコードがvalidであり得るのだが？

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

0262デフォルトの名無しさん

2013/03/17(日) 13:39:16.35

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

0263デフォルトの名無しさん

2013/03/17(日) 13:39:20.96

くっそ何も反論できない。
こうなったら！

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

（そんなの無いけどねｗ）

0264デフォルトの名無しさん

2013/03/17(日) 13:40:10.14

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

0265デフォルトの名無しさん

2013/03/17(日) 13:40:33.86

>>262
それテンプレートじゃんｗ

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

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

0266デフォルトの名無しさん

2013/03/17(日) 13:40:43.65

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

0267デフォルトの名無しさん

2013/03/17(日) 13:41:06.17

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

0268デフォルトの名無しさん

2013/03/17(日) 13:42:21.04

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

0269デフォルトの名無しさん

2013/03/17(日) 13:43:51.89

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

0270デフォルトの名無しさん

2013/03/17(日) 13:43:55.41

ていうか、ここのKURASU君（良い名前だw）に
動的型言語でinvalidなコードを書いてみて貰ったら良いんじゃないか？

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

0271デフォルトの名無しさん

2013/03/17(日) 13:43:58.40

> 動的型のマトモな環境使ったことないの？
ふいたｗ

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

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

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

0272デフォルトの名無しさん

2013/03/17(日) 13:44:17.44

-(void)withString:(*NSString) value // 動的型付
{
　　puts( [value UTF8String] );//補完できる
}

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

0273デフォルトの名無しさん

2013/03/17(日) 13:44:35.91

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

それは違う。

0274デフォルトの名無しさん

2013/03/17(日) 13:45:14.50

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

0275デフォルトの名無しさん

2013/03/17(日) 13:45:21.42

>>265
詭弁だねぇ

0276デフォルトの名無しさん

2013/03/17(日) 13:46:15.83

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

0277デフォルトの名無しさん

2013/03/17(日) 13:46:36.03

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

0278デフォルトの名無しさん

2013/03/17(日) 13:47:02.82

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

0279デフォルトの名無しさん

2013/03/17(日) 13:47:54.76

>>271
で、Smalltalk環境でできることが他の動的言語ではできない理由は？

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

0280デフォルトの名無しさん

2013/03/17(日) 13:48:13.56

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

0281デフォルトの名無しさん

2013/03/17(日) 13:48:22.20

>>277
テンプレートってのは雛形。
コードそのものではなく、
コード生成機

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

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

0282デフォルトの名無しさん

2013/03/17(日) 13:48:34.10

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

0283デフォルトの名無しさん

2013/03/17(日) 13:48:43.16

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

0284デフォルトの名無しさん

2013/03/17(日) 13:49:10.42

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

0285デフォルトの名無しさん

2013/03/17(日) 13:49:29.24

>>279
それは悪魔の証明だな。

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

0286デフォルトの名無しさん

2013/03/17(日) 13:50:06.86

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

0287デフォルトの名無しさん

2013/03/17(日) 13:51:41.78

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

0288デフォルトの名無しさん

2013/03/17(日) 13:51:43.72

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

0289デフォルトの名無しさん

2013/03/17(日) 13:51:59.28

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

0290デフォルトの名無しさん

2013/03/17(日) 13:52:15.05

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

0291デフォルトの名無しさん

2013/03/17(日) 13:52:59.35

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

0292デフォルトの名無しさん

2013/03/17(日) 13:53:08.05

>>289
いや、無いの証明をするのは難しいっていうのが
悪魔の証明ってやつだから。

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

0293デフォルトの名無しさん

2013/03/17(日) 13:53:12.70

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

0294デフォルトの名無しさん

2013/03/17(日) 13:54:59.83

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

0295デフォルトの名無しさん

2013/03/17(日) 13:55:42.28

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

だぞ？

0296デフォルトの名無しさん

2013/03/17(日) 13:57:15.07

>>295
落ちにワロタｗ

0297デフォルトの名無しさん

2013/03/17(日) 13:59:10.26

Pythonならこんなモノがある。

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

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

0298デフォルトの名無しさん

2013/03/17(日) 13:59:22.13

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

0299デフォルトの名無しさん

2013/03/17(日) 13:59:23.98

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

0300デフォルトの名無しさん

2013/03/17(日) 14:01:31.95

>>299
だからこういうことになるわけですね

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

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

0301デフォルトの名無しさん

2013/03/17(日) 14:01:49.61

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

0302デフォルトの名無しさん

2013/03/17(日) 14:02:41.59

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

0303デフォルトの名無しさん

2013/03/17(日) 14:03:01.84

>>301
その下読んだ？

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

0304デフォルトの名無しさん

2013/03/17(日) 14:03:09.92

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

0305デフォルトの名無しさん

2013/03/17(日) 14:04:23.09

つーか、型定義がある時点で静的型付けでしょ？

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

0306デフォルトの名無しさん

2013/03/17(日) 14:04:26.25

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

0307デフォルトの名無しさん

2013/03/17(日) 14:05:25.16

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

0308デフォルトの名無しさん

2013/03/17(日) 14:05:48.31

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

0309デフォルトの名無しさん

2013/03/17(日) 14:05:49.92

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

馬鹿すぎ

0310デフォルトの名無しさん

2013/03/17(日) 14:08:25.16

>>307
>>297

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

0311デフォルトの名無しさん

2013/03/17(日) 14:10:21.78

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

0312デフォルトの名無しさん

2013/03/17(日) 14:11:34.76

0313デフォルトの名無しさん

2013/03/17(日) 14:12:42.95

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

0314デフォルトの名無しさん

2013/03/17(日) 14:15:38.65

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

0315デフォルトの名無しさん

2013/03/17(日) 14:20:02.04

動的型付け言語でも型定義があれば補完できる。

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

0316デフォルトの名無しさん

2013/03/17(日) 14:20:41.39

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

0317デフォルトの名無しさん

2013/03/17(日) 14:20:58.35

>>314
それは仕様通りに動くという意味じゃないだろう？

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

0318デフォルトの名無しさん

2013/03/17(日) 14:21:54.35

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

0319デフォルトの名無しさん

2013/03/17(日) 14:23:07.37

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

0320デフォルトの名無しさん

2013/03/17(日) 14:23:37.00

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

0321デフォルトの名無しさん

2013/03/17(日) 14:24:15.99

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

0322デフォルトの名無しさん

2013/03/17(日) 14:24:48.30

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

0323デフォルトの名無しさん

2013/03/17(日) 14:25:11.89

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

0324デフォルトの名無しさん

2013/03/17(日) 14:26:09.03

こんなかんじでどうだ？

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

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

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

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

0325デフォルトの名無しさん

2013/03/17(日) 14:27:19.38

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

0326デフォルトの名無しさん

2013/03/17(日) 14:27:54.86

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

0327デフォルトの名無しさん

2013/03/17(日) 14:28:07.01

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

0328デフォルトの名無しさん

2013/03/17(日) 14:28:16.63

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

0329デフォルトの名無しさん

2013/03/17(日) 14:29:04.99

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

0330デフォルトの名無しさん

2013/03/17(日) 14:29:33.25

Active Recordは設計がおかしい。

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

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

0331デフォルトの名無しさん

2013/03/17(日) 14:30:05.95

>>328
LazyKも入れよう

0332デフォルトの名無しさん

2013/03/17(日) 14:30:47.90

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

0333デフォルトの名無しさん

2013/03/17(日) 14:31:28.15

>>330

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

0334デフォルトの名無しさん

2013/03/17(日) 14:31:51.06

変数に型定義がないっていうのは

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

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

0335デフォルトの名無しさん

2013/03/17(日) 14:32:37.66

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

0336デフォルトの名無しさん

2013/03/17(日) 14:33:06.40

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

0337デフォルトの名無しさん

2013/03/17(日) 14:33:24.68

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

0338デフォルトの名無しさん

2013/03/17(日) 14:33:43.44

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

0339デフォルトの名無しさん

2013/03/17(日) 14:33:46.27

おまんこ

0340デフォルトの名無しさん

2013/03/17(日) 14:35:12.08

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

0341デフォルトの名無しさん

2013/03/17(日) 14:35:53.76

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

0342デフォルトの名無しさん

2013/03/17(日) 14:36:16.41

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

0343デフォルトの名無しさん

2013/03/17(日) 14:37:16.49

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

0344デフォルトの名無しさん

2013/03/17(日) 14:39:50.43

>>338
http://blog.remarkablelabs.com/2012/12/activemodel-model-rails-4-countdown-to-2013
> ActiveModel::Model is a module mixin that allows Ruby objects to work with Action Pack.
> What this means is you can now include ActiveModel::Model in a plain old Ruby class,

plain old Ruby class

いや楽しいねｗ

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

0345デフォルトの名無しさん

2013/03/17(日) 14:41:07.19

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

0346デフォルトの名無しさん

2013/03/17(日) 14:42:44.16

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

0347デフォルトの名無しさん

2013/03/17(日) 14:44:29.54

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

0348デフォルトの名無しさん

2013/03/17(日) 14:44:33.80

>>338
これまでこう書いてたのを

class Foo < ActiveRecord::Base
end

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

class Foo
include ActiveRecord::Model
end

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

0349デフォルトの名無しさん

2013/03/17(日) 14:44:36.79

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

0350デフォルトの名無しさん

2013/03/17(日) 14:45:44.23

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

0351デフォルトの名無しさん

2013/03/17(日) 14:46:27.86

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

0352デフォルトの名無しさん

2013/03/17(日) 14:49:08.98

>>350
でもvalueはFunctionを持っている必要が有ることは
コードをみれば明らかじゃん？

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

0353デフォルトの名無しさん

2013/03/17(日) 14:50:20.82

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

これがJava脳か……

0354デフォルトの名無しさん

2013/03/17(日) 14:51:17.73

>>348
こう書こうってだけで終わらないことを祈るよ。

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

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

0355デフォルトの名無しさん

2013/03/17(日) 14:52:36.10

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

0356デフォルトの名無しさん

2013/03/17(日) 14:56:53.29

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

0357デフォルトの名無しさん

2013/03/17(日) 14:58:01.10

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

0358デフォルトの名無しさん

2013/03/17(日) 14:59:42.59

いい話よのう。まるでJavaの歴史をなぞっているかのようだ。

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

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

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

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

== コメント ==

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

0359デフォルトの名無しさん

2013/03/17(日) 15:00:55.43

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

0360デフォルトの名無しさん

2013/03/17(日) 15:02:59.66

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

0361デフォルトの名無しさん

2013/03/17(日) 15:03:55.00

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

0362デフォルトの名無しさん

2013/03/17(日) 15:06:03.54

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

0363デフォルトの名無しさん

2013/03/17(日) 15:06:55.72

Java厨が早速反応している

0364デフォルトの名無しさん

2013/03/17(日) 15:12:51.06

お前が反応したｗ

0365デフォルトの名無しさん

2013/03/17(日) 15:27:38.38

結局、Javaと同じ言語仕様が正解で
Javaと違うのは間違い、と言いたいんだろう？

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

0366デフォルトの名無しさん

2013/03/17(日) 15:34:13.33

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

0367デフォルトの名無しさん

2013/03/17(日) 15:38:45.53

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

0368デフォルトの名無しさん

2013/03/17(日) 15:42:03.85

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

0369デフォルトの名無しさん

2013/03/17(日) 15:53:55.07

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

0370デフォルトの名無しさん

2013/03/17(日) 15:59:49.60

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

0371デフォルトの名無しさん

2013/03/17(日) 16:05:51.65

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

0372デフォルトの名無しさん

2013/03/17(日) 16:07:19.22

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

0373デフォルトの名無しさん

2013/03/17(日) 16:34:44.29

>>371
> 不要なものを書かなければ生産性は上がるのは当然。

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

0374デフォルトの名無しさん

2013/03/17(日) 16:36:35.24

プログラミングって、書く時よりも、
コードを読む時のほうが
時間が多くかかるって知ってる？

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

0375デフォルトの名無しさん

2013/03/17(日) 16:42:00.06

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

0376デフォルトの名無しさん

2013/03/17(日) 16:52:01.90

>>373
言い換えになってない

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

国語から学び直せ

0377デフォルトの名無しさん

2013/03/17(日) 16:55:45.67

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

0378デフォルトの名無しさん

2013/03/17(日) 16:57:33.57

面倒なんで先読みしてレスするわｗ

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

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

0379デフォルトの名無しさん

2013/03/17(日) 17:00:55.66

>>374
Graphviz使うような場面だから、静的型動的型関係ねぇなぁ

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

0380デフォルトの名無しさん

2013/03/17(日) 17:05:55.35

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

0381デフォルトの名無しさん

2013/03/17(日) 17:15:04.03

>>118がいい例だよな

0382デフォルトの名無しさん

2013/03/17(日) 17:57:54.33

JLabelとJTextFieldのメソッドが名寄せできる程度で生産性云々を誇られても。
JLabelとJTextFieldに関してはそもそも名寄せが必要な場面って殆ど無いし。

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

0383デフォルトの名無しさん

2013/03/17(日) 18:20:16.62

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

0384デフォルトの名無しさん

2013/03/17(日) 18:55:29.48

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

0385デフォルトの名無しさん

2013/03/17(日) 18:57:01.45

え、あんな馬鹿が何人もいるの？

そらすげえな()

0386デフォルトの名無しさん

2013/03/17(日) 19:17:10.72

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

0387デフォルトの名無しさん

2013/03/17(日) 19:19:24.30

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

0388デフォルトの名無しさん

2013/03/17(日) 19:19:33.58

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

0389デフォルトの名無しさん

2013/03/17(日) 19:22:17.63

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

0390デフォルトの名無しさん

2013/03/17(日) 19:23:23.39

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

0391デフォルトの名無しさん

2013/03/17(日) 19:24:04.05

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

0392デフォルトの名無しさん

2013/03/17(日) 19:36:24.11

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

0393デフォルトの名無しさん

2013/03/17(日) 19:37:56.88

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

0394デフォルトの名無しさん

2013/03/17(日) 19:55:48.80

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

0395デフォルトの名無しさん

2013/03/17(日) 19:57:39.64

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

0396デフォルトの名無しさん

2013/03/17(日) 20:01:18.86

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

0397デフォルトの名無しさん

2013/03/17(日) 20:01:57.24

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

0398デフォルトの名無しさん

2013/03/17(日) 20:17:31.17

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

0399デフォルトの名無しさん

2013/03/17(日) 20:26:55.88

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

0400デフォルトの名無しさん

2013/03/17(日) 20:30:19.91

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

0401デフォルトの名無しさん

2013/03/17(日) 20:42:45.87

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

0402デフォルトの名無しさん

2013/03/17(日) 20:50:01.34

　　　　　　　　 ,-､　　　　　　　　　　　　,.-､
　　　　　　　 ./:::::＼　　　　　　　　　／::::::ヽ
　　　　　　　/::::::::::::;ゝ--──-- ､._/::::::::::::::|
　　　　　　 /,.-‐''"´ 　　　　　　　　＼:::::::::::|
　　　　　／　　　　　　　　　　　　　　　ヽ､::::|
　　　　/　　　　　　　　　　　　　　　　　　　ヽ|
　　　 l　　　　　　　　　　　　　　　　　 l
　　　 .|　　　 ●　　　　　　　　　　　　　　　　|　　　　んーとね・・
　　　l　　, , ,　　　　　　　　　　　●　　　　 l
　　　　` ､　　　　　　(_人__丿　　　　､､､　 /
　　　　　　`ｰ､__　　　　　　　　　　　　／
　　　　　　　　　/`'''ｰ‐‐──‐‐‐┬'''""´

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

0403デフォルトの名無しさん

2013/03/17(日) 21:14:09.95

>>401
ご託は良いからMVCにGUIコンポーネントの名寄せやDuckTypingが必要なケースを(ry

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

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

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

public class FruitListViewModel{
　List<Fruit> fruitList;
}

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

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

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

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

0404デフォルトの名無しさん

2013/03/17(日) 21:16:18.13

「名寄せ」だってw

0405デフォルトの名無しさん

2013/03/17(日) 21:44:19.13

>>403
JLabelとJTextFieldってさ、setTextは共有してるのに
インターフェースを共有してないから、setTextを呼び出すコードを
JLabelとJTextFieldで別々に容易しなきゃダメって話じゃないの？

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

0406デフォルトの名無しさん

2013/03/17(日) 21:57:01.88

>>405
さあ？
>>387がJavaでMVCするにはそれ(メソッド名の名寄せ)をするしかないと書いているから
んなわけね～と書いたまでだけど。

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

0407デフォルトの名無しさん

2013/03/17(日) 22:00:21.14

>>403
だれもViewModelのなんてやれっつってねぇよ。
純粋なMVCやれ、別にPluggableMVCでもいいぞ。

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

0408デフォルトの名無しさん

2013/03/17(日) 22:15:57.59

>>407
は？純粋なMVCだが。どこが不純か詳しく。

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

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

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

0409デフォルトの名無しさん

2013/03/17(日) 22:17:32.31

現実的にRhinoで実装すっとこんな感じか。
Javaより格段無駄がなくてすっきりするな。

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

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

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

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

0410デフォルトの名無しさん

2013/03/17(日) 22:19:51.01

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

0411デフォルトの名無しさん

2013/03/17(日) 22:26:29.98

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

0412デフォルトの名無しさん

2013/03/17(日) 22:29:32.34

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

0413デフォルトの名無しさん

2013/03/17(日) 22:30:49.29

>>409
テキストをポリゴン表示するど派手なラベル部品を使いたいんだが、テキスト表示するメソッド名
がrenderTextだったらど～する。

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

0414デフォルトの名無しさん

2013/03/17(日) 22:36:39.17

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

0415デフォルトの名無しさん

2013/03/17(日) 22:45:25.91

Contoroller忘れてたのと重要なとこ忘れてたんで修正
var TextModel = function()
{
　　this = new java.beans.PropertyChangeSupport( this );
　　var text = "";

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

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

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

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

0416デフォルトの名無しさん

2013/03/17(日) 22:48:22.31

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

0417デフォルトの名無しさん

2013/03/17(日) 22:51:03.06

間違えたんで細部修正
var TextModel = function()
{
　　this = new java.beans.PropertyChangeSupport( this );
　　var text = "";

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

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

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

0418デフォルトの名無しさん

2013/03/17(日) 23:01:55.51

ところで、標準ライブラリのOutputStreamとDataOutputの関係はどうなの？
こんな感じのコードを別々に書くことに合理性はあるの？

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

0419デフォルトの名無しさん

2013/03/17(日) 23:25:34.95

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

0420デフォルトの名無しさん

2013/03/17(日) 23:46:27.06

>>419
View定義
public interface FruitView{
　void displayFruit(Fruit fruit);
}

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

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

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

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

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

0421デフォルトの名無しさん

2013/03/18(月) 00:01:23.38

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

0422デフォルトの名無しさん

2013/03/18(月) 00:14:29.92

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

0423デフォルトの名無しさん

2013/03/18(月) 02:24:53.23

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

0424デフォルトの名無しさん

2013/03/18(月) 02:29:23.18

どのJavaにこてんぱんにされてるｗ

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

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

0425デフォルトの名無しさん

2013/03/18(月) 02:31:20.52

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

0426デフォルトの名無しさん

2013/03/18(月) 02:37:08.62

>>418
> ところで、標準ライブラリのOutputStreamとDataOutputの関係はどうなの？
別に問題ない。抽象化することで拡張性が得られている。

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

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

0427デフォルトの名無しさん

2013/03/18(月) 02:43:45.32

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

0428デフォルトの名無しさん

2013/03/18(月) 02:46:41.70

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

0429デフォルトの名無しさん

2013/03/18(月) 02:48:40.03

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

0430デフォルトの名無しさん

2013/03/18(月) 02:52:59.27

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

0431デフォルトの名無しさん

2013/03/18(月) 07:13:08.74

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

0432デフォルトの名無しさん

2013/03/18(月) 07:16:48.58

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

0433デフォルトの名無しさん

2013/03/18(月) 07:23:07.75

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

0434デフォルトの名無しさん

2013/03/18(月) 08:09:46.09

>>431
フレームワークが扱うべきなのはこの例の範囲で言うならMV間のオブザーバーパターンの実装。
これは全てのModelで共有すべき実装であって具象Modelの実装に立ち現れるのは良くない。
抽象クラスで実装するなり別のオブジェクトに委譲すべきだし、それはJavaでも簡単。

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

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

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

0435デフォルトの名無しさん

2013/03/18(月) 08:37:13.31

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

0436デフォルトの名無しさん

2013/03/18(月) 08:48:48.78

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

0437デフォルトの名無しさん

2013/03/18(月) 17:50:24.43

言葉よりもコードが雄弁に語ってるね
Javaが冗長でオワコンだと

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

0438デフォルトの名無しさん

2013/03/18(月) 18:54:10.72

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

0439デフォルトの名無しさん

2013/03/18(月) 21:02:54.47

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

0440デフォルトの名無しさん

2013/03/18(月) 21:05:47.92

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

0441デフォルトの名無しさん

2013/03/18(月) 22:06:47.75

お前らいつまで書く時の話ばっかり見てるんだ？
コードは書くより読むほうが何倍も多いんだぞ。

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

0442デフォルトの名無しさん

2013/03/18(月) 22:11:51.17

なんかMVCパターンわかってない奴がいるみたいだね。

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

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

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

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

0443デフォルトの名無しさん

2013/03/18(月) 22:14:58.38

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

0444デフォルトの名無しさん

2013/03/18(月) 22:16:39.55

それよりもWeb系の偽MVCと
GUI系の本物のMVCをごっちゃにしている奴がいそうだ。

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

0445デフォルトの名無しさん

2013/03/18(月) 22:27:16.72

>>442
>>440

0446デフォルトの名無しさん

2013/03/18(月) 22:31:59.97

>>445
JavaScriptのMVCフレームワークを考えればいい。

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

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

0447デフォルトの名無しさん

2013/03/18(月) 22:41:24.90

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

0448デフォルトの名無しさん

2013/03/18(月) 22:50:29.38

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

0449デフォルトの名無しさん

2013/03/18(月) 22:55:11.04

ラベルとテキストフィールドに
機能的互換性があるかというと
ないよな。

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

0450デフォルトの名無しさん

2013/03/18(月) 22:59:20.20

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

0451デフォルトの名無しさん

2013/03/18(月) 23:02:12.31

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

0452デフォルトの名無しさん

2013/03/19(火) 04:51:09.39

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

0453デフォルトの名無しさん

2013/03/19(火) 06:59:37.44

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

0454デフォルトの名無しさん

2013/03/19(火) 07:16:04.12

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

0455デフォルトの名無しさん

2013/03/19(火) 07:16:03.82

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

0456デフォルトの名無しさん

2013/03/19(火) 07:25:08.39

結論。Javaは糞。

0457デフォルトの名無しさん

2013/03/19(火) 10:17:46.80

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

0458デフォルトの名無しさん

2013/03/19(火) 16:07:24.58

0459デフォルトの名無しさん

2013/03/19(火) 18:57:55.49

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

0460デフォルトの名無しさん

2013/03/19(火) 21:23:52.56

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

0461デフォルトの名無しさん

2013/03/20(水) 00:36:54.25

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

0462デフォルトの名無しさん

2013/03/20(水) 01:15:45.31

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

0463デフォルトの名無しさん

2013/03/20(水) 06:38:58.11

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

0464デフォルトの名無しさん

2013/03/20(水) 12:29:35.00

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

0465デフォルトの名無しさん

2013/03/20(水) 12:33:36.40

Smalltalk系とかググらんでもだいたいわかるけど、
Javaはググらにゃ判らん事が多すぎる。
APIなんかググること前提だろ。

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

0466デフォルトの名無しさん

2013/03/20(水) 12:35:46.74

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

0467デフォルトの名無しさん

2013/03/20(水) 12:38:36.35

>>466
フレームワークとは何だ？

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

0468デフォルトの名無しさん

2013/03/20(水) 12:38:56.94

List of buzzwords
http://en.wikipedia.org/wiki/List_of_buzzwords

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

0469デフォルトの名無しさん

2013/03/20(水) 12:40:10.31

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

0470デフォルトの名無しさん

2013/03/20(水) 12:41:12.69

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

0471デフォルトの名無しさん

2013/03/20(水) 12:43:52.31

>>469
話ずれてるよ。

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

0472デフォルトの名無しさん

2013/03/20(水) 12:43:56.10

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

0473デフォルトの名無しさん

2013/03/20(水) 12:44:56.69

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

0474デフォルトの名無しさん

2013/03/20(水) 12:44:58.70

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

0475デフォルトの名無しさん

2013/03/20(水) 12:45:32.62

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

0476デフォルトの名無しさん

2013/03/20(水) 12:46:53.27

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

0477デフォルトの名無しさん

2013/03/20(水) 12:47:02.17

フレームワークの説明なんてwikipediaに任せればいいじゃん。はい終了。
http://ja.wikipedia.org/wiki/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%83%95%E3%83%AC%E3%83%BC%E3%83%A0%E3%83%AF%E3%83%BC%E3%82%AF

0478デフォルトの名無しさん

2013/03/20(水) 12:48:03.98

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

0479デフォルトの名無しさん

2013/03/20(水) 12:48:35.62

>>476
出典ってこれかい？お前こそ読んだ？

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

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

0480デフォルトの名無しさん

2013/03/20(水) 12:50:00.85

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

0481デフォルトの名無しさん

2013/03/20(水) 12:56:28.02

>>480
>This article needs additional citations for verification. Please help improve this article by adding
>citations to reliable sources. Unsourced material may be challenged and removed. (April 2011)

Wikipedia以外で

0482デフォルトの名無しさん

2013/03/20(水) 13:03:11.43

>>468
おい、英語のWikipediaもダメらしいぞｗ

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

0483デフォルトの名無しさん

2013/03/20(水) 13:05:17.16

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

0484デフォルトの名無しさん

2013/03/20(水) 13:07:09.95

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

0485デフォルトの名無しさん

2013/03/20(水) 13:08:07.48

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

0486デフォルトの名無しさん

2013/03/20(水) 13:17:05.97

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

0487デフォルトの名無しさん

2013/03/20(水) 13:18:02.88

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

0488デフォルトの名無しさん

2013/03/20(水) 13:18:26.50

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

0489デフォルトの名無しさん

2013/03/20(水) 13:19:14.47

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

0490デフォルトの名無しさん

2013/03/20(水) 13:20:55.19

もう意味がよく判らんしTogetherでもいいんじゃね
多分それでも十分通じると思う。

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

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

464 名前：デフォルトの名無しさん [sage]： 2013/03/20(水) 12:29:35.00
一体どの言語ならトゥゲダーが不要になるのだろうか？

0491デフォルトの名無しさん

2013/03/20(水) 13:22:00.01

>>490
全くわからんｗ

0492デフォルトの名無しさん

2013/03/20(水) 13:24:22.54

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

0493デフォルトの名無しさん

2013/03/20(水) 13:27:28.35

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

0494デフォルトの名無しさん

2013/03/20(水) 13:28:09.31

>>490
マクドナルド的にはチキンタツタの方がいい

462 名前：デフォルトの名無しさん [sage]： 2013/03/20(水) 01:15:45.31
チキンタツタ接続、チキンタツタ入出力、外部チキンタツタ使用、
何をやるにもチキンタツタは冗長で可読性最悪。
言い訳は「そんなの書かなくてもチキンタツタがやってくれるし！」

463 名前：デフォルトの名無しさん [sage]： 2013/03/20(水) 06:38:58.11
まあチキンタツタやチキンタツタといったチキンタツタチキンタツタ無しでチキンタツタを使う意味は無いわな。

464 名前：デフォルトの名無しさん [sage]： 2013/03/20(水) 12:29:35.00
一体どの言語ならチキンタツタが不要になるのだろうか？

0495デフォルトの名無しさん

2013/03/20(水) 13:29:08.25

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

0496デフォルトの名無しさん

2013/03/20(水) 13:30:05.51

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

0497デフォルトの名無しさん

2013/03/20(水) 13:30:19.24

http://e-words.jp/w/E38395E383ACE383BCE383A0E383AFE383BCE382AF.html

フレームワーク【framework】

▼ 分野
▼ 文中の用語
枠組み、下部構造、構造、組織という意味の英単語。

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

0498デフォルトの名無しさん

2013/03/20(水) 13:31:51.39

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

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

はい論破

0499デフォルトの名無しさん

2013/03/20(水) 13:32:57.24

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

0500デフォルトの名無しさん

2013/03/20(水) 13:37:35.23

コンパイラ言語
http://e-words.jp/w/E382B3E383B3E38391E382A4E383A9E8A880E8AA9E.html
>同じプログラミング言語にコンパイラとインタプリタの両方が用意され、必要に応じて使い分けられるようになっている言語も多い。

支離滅裂な辞典だな
「コンパイラ言語」なんてくくりの言語存在しないだろ

0501デフォルトの名無しさん

2013/03/20(水) 13:39:38.66

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

0502デフォルトの名無しさん

2013/03/20(水) 13:58:24.01

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

0503デフォルトの名無しさん

2013/03/20(水) 14:04:08.99

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

0504デフォルトの名無しさん

2013/03/20(水) 14:13:25.88

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

0505デフォルトの名無しさん

2013/03/20(水) 14:15:07.12

>>502
たしかにそのとおりだ。
だからフレームワークがある言語を言おう

Java、JavaScript、Ruby、PHP、Perl、Python

0506デフォルトの名無しさん

2013/03/20(水) 14:16:30.87

Smalltalk (Seaside)

0507デフォルトの名無しさん

2013/03/20(水) 14:17:39.29

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

0508デフォルトの名無しさん

2013/03/20(水) 14:21:18.86

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

0509デフォルトの名無しさん

2013/03/20(水) 14:23:00.27

>>508
FORTRAN とか

0510デフォルトの名無しさん

2013/03/20(水) 14:23:02.58

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

0511デフォルトの名無しさん

2013/03/20(水) 14:25:22.37

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

0512デフォルトの名無しさん

2013/03/20(水) 14:27:30.19

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

0513デフォルトの名無しさん

2013/03/20(水) 14:42:48.13

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

0514デフォルトの名無しさん

2013/03/20(水) 14:44:39.68

んなわけねーだろw

0515デフォルトの名無しさん

2013/03/20(水) 14:48:25.54

>>513がLispやPrologにはあるのか？って質問に見えたので

http://clacklisp.org/tutorial/01-introduction.html
Clack is a web aplication environment for Common Lisp,

http://prospear.sourceforge.net/
Welcome to the home page of Prosper, a framework for developing Prolog web applications.

0516デフォルトの名無しさん

2013/03/20(水) 15:35:20.32

Frameworkと名の付くものならCOBOLにだってあるよな
Frameworkと名が付くものが無いのはBrain Fuckとか
White spaceとかマイナー言語ぐらいになるじゃないか？

>>506
定義のらんFrameworkとやらと同列に語ってほしくない

0517デフォルトの名無しさん

2013/03/20(水) 15:36:05.69

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

0518デフォルトの名無しさん

2013/03/20(水) 15:38:04.67

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

0519デフォルトの名無しさん

2013/03/20(水) 15:38:12.86

おまえらはバカだな
自分が書いたコードから呼び出すのがライブラリ、
自分が書いたコードを呼び出すのがフレームワークだよ

PHP、Ruby、Pythonのフレームワークは
総じて軽いから問題にならない
Javaのは…、まあおまえらが知っての通りだw

0520デフォルトの名無しさん

2013/03/20(水) 15:39:22.66

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

0521デフォルトの名無しさん

2013/03/20(水) 15:41:35.86

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

0522デフォルトの名無しさん

2013/03/20(水) 15:47:15.90

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

0523デフォルトの名無しさん

2013/03/20(水) 15:54:23.13

英語圏におけるLightweight programming language

英語版Wikipediaによれば、Lightweight programming languageは計算機
リソースを多くは消費しないという意味で軽量（Lightweight）であり、
C言語などが例としてあげられている。つまり、プログラマ負担の軽い言語を意味しない。
また、1997年に書かれたLightweight Languages as Software Engineering Toolsでは、
プログラミング言語内で補助的に使われる、正規表現やSQL、GLSLを、Lightweight Languagesと呼んでいる。
よって、日本における軽量プログラミング言語と欧米におけるLightweight programming languageは、
その「軽量」の意味においてまったく異なるものであるため注意が必要である。
英語でPerlやJavaScript、PHPを指し示す場合は、Scripting languageと表現するのが妥当である。

0524デフォルトの名無しさん

2013/03/20(水) 15:55:48.37

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

0525デフォルトの名無しさん

2013/03/20(水) 16:03:39.79

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

0526デフォルトの名無しさん

2013/03/20(水) 16:05:27.32

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

0527デフォルトの名無しさん

2013/03/20(水) 16:05:30.41

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

0528デフォルトの名無しさん

2013/03/20(水) 16:06:02.35

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

0529デフォルトの名無しさん

2013/03/20(水) 16:08:31.54

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

0530デフォルトの名無しさん

2013/03/20(水) 16:09:55.97

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

0531デフォルトの名無しさん

2013/03/20(水) 16:12:23.93

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

0532デフォルトの名無しさん

2013/03/20(水) 16:19:26.79

>>531
High Performance Fortran Frameworkを呼び出す貴方がフレームワークなんですよw

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

0533デフォルトの名無しさん

2013/03/20(水) 16:24:23.27

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

0534デフォルトの名無しさん

2013/03/20(水) 16:28:44.75

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

0535デフォルトの名無しさん

2013/03/20(水) 16:32:27.93

ソフトウェアフレームワーク - Wikipedia
ソフトウェアフレームワークとは、プログラミングにおいて一般的な機能をもつ共通コードをユーザーが選択的に上書きしたり特化させたりすることで、ある特定の機能をもたせようとする抽象概念のことである。
ソフトウェアフレームワークは、はっきり定義されたAPIを持ち、コードを再利用可能な形で隠蔽しているという点でライブラリとよく似ている。
しかし、ライブラリでは呼び出し側がプログラム全体の制御構造を指定できないが、フレームワークでは可能である。

Preeによれば、ソフトウェアフレームワークには「凍った部分 (frozen spot)」と「熱い部分 (hot spot)」がある。
「凍った部分」はソフトウェアシステム全体のアーキテクチャ（基本コンポーネント群とそれらの相互関係）を定義する。
それらはそのフレームワークを使って何を実装した場合でも常に変化しない。
一方、「熱い部分」はプログラマがプロジェクト固有の機能に対応したコードを追加できる部分である。
ソフトウェアフレームワークには、ソフトウェアアーキテクチャ内でアプリケーションプログラマが特定の機能に対応したコードを置ける場所（すなわち「熱い部分」）が定義してある。

0536デフォルトの名無しさん

2013/03/20(水) 16:35:57.80

>>535

>>477-481

0537デフォルトの名無しさん

2013/03/20(水) 17:15:32.33

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

今の定義で語れば良い。

0538デフォルトの名無しさん

2013/03/20(水) 17:24:51.29

今の定義って何？

0539デフォルトの名無しさん

2013/03/20(水) 17:29:05.21

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

0540デフォルトの名無しさん

2013/03/20(水) 17:32:57.39

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

0541デフォルトの名無しさん

2013/03/20(水) 17:33:33.08

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

0542デフォルトの名無しさん

2013/03/20(水) 17:35:32.66

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

0543デフォルトの名無しさん

2013/03/20(水) 17:35:49.97

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

0544デフォルトの名無しさん

2013/03/20(水) 17:38:25.13

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

0545デフォルトの名無しさん

2013/03/20(水) 17:39:19.54

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

0546デフォルトの名無しさん

2013/03/20(水) 17:46:02.12

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

0547デフォルトの名無しさん

2013/03/20(水) 17:49:50.95

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

0548デフォルトの名無しさん

2013/03/20(水) 17:50:38.81

>>544
厳密な定義が無い用語だからね

http://en.wikipedia.org/wiki/Seaside_(software)
> Seaside is a free and open source web application framework for developing web applications in Smalltalk.

http://sourceforge.jp/magazine/10/09/14/0429222
> Smalltalk向けWebフレームワークの最新版「Seaside 3.0」リリース

0549デフォルトの名無しさん

2013/03/20(水) 18:43:10.39

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

0550デフォルトの名無しさん

2013/03/20(水) 21:20:26.05

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

0551デフォルトの名無しさん

2013/03/20(水) 21:34:44.10

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

0552デフォルトの名無しさん

2013/03/20(水) 21:41:27.03

コンパイルエラーをテストで見つけるという考え方が
そもそもおかしいんだと思う。

コードの動きが正しいかどうかはテストがないと判定できないけど
コンパイルエラーは明らかに間違いってわかるもの。

そのためにテストを使うっていうのは
単体テストで不具合を見つけるべきものを
統合テストで見つけているようなものだと思う。

0553デフォルトの名無しさん

2013/03/20(水) 21:56:44.21

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

0554デフォルトの名無しさん

2013/03/20(水) 21:58:14.16

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

0555デフォルトの名無しさん

2013/03/20(水) 22:02:32.93

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

0556デフォルトの名無しさん

2013/03/20(水) 22:05:05.21

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

0557デフォルトの名無しさん

2013/03/20(水) 22:06:06.55

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

0558デフォルトの名無しさん

2013/03/20(水) 22:12:49.81

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

0559デフォルトの名無しさん

2013/03/20(水) 22:31:54.45

そもそもコンパイルエラー全てを単体テストで
見つけられるのか？という問題がある。

実は単体テストに通ってもプロダクションコードは
正しく動かない場合が存在する。

0560デフォルトの名無しさん

2013/03/20(水) 22:36:59.44

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

0561デフォルトの名無しさん

2013/03/20(水) 22:40:52.52

>>559
HWND window = CreateWindowEx(・・・);
SendMessage( window, UM_XXXX, yyy, zzz );
SendMessage( window, UM_XXXX, yyy, zzz );
SendMessage( window, UM_XXXX, yyy, zzz );
SendMessage( window, UM_XXXX, yyy, zzz );
SendMessage( window, UM_XXXX, yyy, zzz );
SendMessage( window, UM_XXXX, yyy, zzz );

WinAPIつかってた時代はバグだらけでマトモなプログラムは書けなかったと？

0562デフォルトの名無しさん

2013/03/20(水) 22:41:51.92

>>560
テストを流せば、静的型付け言語のコンパイルチェックで
見つけられるエラーは全てわかると言ってる人がいるだろ？

それが間違いということ。

あとdynamic_castは危険だからあまり使わないようにするという風潮がある

0563デフォルトの名無しさん

2013/03/20(水) 22:42:57.74

見つけられるバグの数

（静的型付け言語＋コンパイルチェック＋テスト）　＞　（動的型付け言語＋テスト）

0564デフォルトの名無しさん

2013/03/20(水) 22:43:49.19

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

0565デフォルトの名無しさん

2013/03/20(水) 22:43:55.88

>>560 >>561
それテスト書いてないじゃんｗ

テスト書いても不具合が見つからない事がある
でも静的型付け言語なら見つけられる。

って話をしてるのにｗ

0566デフォルトの名無しさん

2013/03/20(水) 22:45:23.08

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

0567デフォルトの名無しさん

2013/03/20(水) 22:46:49.13

>>566
開発コストがかかるって事でしょう？
そりゃそうですよ。テストがなくても人力テストが完璧なら
バグはありませんよ。

でもね。今はより早くバグを検出することが求められています。
昔の開発効率が悪い時代の例を持ってこられても困りますねぇｗ

0568デフォルトの名無しさん

2013/03/20(水) 22:47:03.92

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

0569デフォルトの名無しさん

2013/03/20(水) 22:51:00.11

>>568
型チェックエラー

動的型付け言語なら型がないから、型チェックエラーにはならず、
プロダクションコードは間違った答えを返すが一応動作し
単体テストコードは問題なく書かれている。

単体テストコードがあれば型チェックは不要というのが
間違いである例が存在する。しかも別に特殊な例ではない。

0570デフォルトの名無しさん

2013/03/20(水) 22:55:24.46

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

0571デフォルトの名無しさん

2013/03/20(水) 22:56:44.94

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

0572デフォルトの名無しさん

2013/03/20(水) 23:02:21.81

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

0573デフォルトの名無しさん

2013/03/20(水) 23:03:39.00

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

0574デフォルトの名無しさん

2013/03/20(水) 23:08:11.43

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

0575デフォルトの名無しさん

2013/03/20(水) 23:08:39.50

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

0576デフォルトの名無しさん

2013/03/20(水) 23:10:00.21

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

0577デフォルトの名無しさん

2013/03/20(水) 23:12:44.05

>>576
同じ人がstrictモードON/OFFで調べないと比較にならんだろｗ
誰がを聞く意味がわからん。

で、殆どの人がstrictモードONを選んでいる。
その人にstrictモードOFFを強要したら成果は下がるだろうね。

0578デフォルトの名無しさん

2013/03/20(水) 23:14:18.66

>>575
あなたが書かずに済ます方法を知らないだけでしょう？

よくいるのが言語標準機能にないからと
毎回同じコードを書く人。
一回書けばいいだけなのにコピペをする。

そいうのはその人の問題。

0579デフォルトの名無しさん

2013/03/20(水) 23:14:30.86

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

0580デフォルトの名無しさん

2013/03/20(水) 23:16:10.35

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

0581デフォルトの名無しさん

2013/03/20(水) 23:21:01.19

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

Eventってなんだ？誰がEventを発行するんだ？

0582デフォルトの名無しさん

2013/03/20(水) 23:22:18.45

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

0583デフォルトの名無しさん

2013/03/20(水) 23:23:46.26

面倒くさいから

Objective-CでSelector名を指定してEventを拾う方法を

聞けばいいんじゃね？

0584デフォルトの名無しさん

2013/03/20(水) 23:25:58.87

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

0585デフォルトの名無しさん

2013/03/20(水) 23:27:57.79

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

0586デフォルトの名無しさん

2013/03/20(水) 23:28:21.85

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

0587デフォルトの名無しさん

2013/03/20(水) 23:30:14.58

>>586
それはお前の視野が狭すぎるｗ

Ruby セレクター
PHP セレクター
JavaScript セレクター

なんでもいいから検索してみなよ。
特定の言語でしか使われてない用語だから。

（お前の知ってる数少ない言語以外にはない概念なんだろ？当然だって気づかないかな？）

0588デフォルトの名無しさん

2013/03/20(水) 23:33:43.83

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

0589デフォルトの名無しさん

2013/03/20(水) 23:34:51.66

間違ったｗ

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

0590デフォルトの名無しさん

2013/03/20(水) 23:47:19.93

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

0591590

2013/03/20(水) 23:48:43.79

× >>575
○>>578

0592デフォルトの名無しさん

2013/03/20(水) 23:51:25.42

>>587

Squeak
>message selector and argument names
http://wiki.squeak.org/squeak/671

Go
http://golang.jp/go_spec#Selectors
>セレクタは次の形式の基本式です。このxはパッケージ名ではありません

Objective-C
https://developer.apple.com/jp/devcenter/ios/library/documentation/ObjC.pdf
>メソッドとセレクタ

Java
http://docs.oracle.com/javase/specs/jls/se7/jls7.pdf
PrefixOp Expression3
( (Expression | Type) ) Expression3
Primary { Selector } { PostfixOp }

確かに多数派というわけではないわな。

0593デフォルトの名無しさん

2013/03/20(水) 23:53:44.76

>>590
さっき書いただろ？

お前は手段と目的が反対になってるって
言語に特定の機能がなければ別の方法で実現すればいいだけだよ。

それが冗長になるのなら、簡単に書けるような仕組みかライブラリを
探すか一回だけ書けばいい。

さっきも書いたけど、お前は
よくいるのが言語標準機能にないからと
毎回同じコードを書く人。
一回書けばいいだけなのにコピペをする。
ってやつだろ？

どうだ図星だろう。

0594デフォルトの名無しさん

2013/03/20(水) 23:56:04.56

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

0595デフォルトの名無しさん

2013/03/20(水) 23:58:45.13

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

0596デフォルトの名無しさん

2013/03/20(水) 23:59:40.53

> それにあなたはJavaだと書かないで済む回避策を提示できませんでしたよね。

万能の回避策
コードジェネレータ

冗長でも書けるのであれば、回避策になる。
はい論破

0597デフォルトの名無しさん

2013/03/21(木) 00:04:01.17

>>593
>言語に特定の機能がなければ別の方法で実現すればいいだけだよ。

>それが冗長になるのなら、簡単に書けるような仕組みかライブラリを
>探すか一回だけ書けばいい。

そもそも、ここの話がおかしな話。Javaだと上記の事をしなきゃいけないから
冗長だといってるんですが、話をねじ曲げてませんか？

0598デフォルトの名無しさん

2013/03/21(木) 00:05:42.20

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

0599デフォルトの名無しさん

2013/03/21(木) 00:09:28.31

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

0600デフォルトの名無しさん

2013/03/21(木) 00:18:05.12

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

0601デフォルトの名無しさん

2013/03/21(木) 00:24:41.35

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

0602デフォルトの名無しさん

2013/03/21(木) 00:36:07.92

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

0603デフォルトの名無しさん

2013/03/21(木) 02:10:24.93

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

0604デフォルトの名無しさん

2013/03/21(木) 06:06:29.61

>>559
では静的型付けならば
単体テストさえ通ればプロダクションコードが確実に動作する
と言えるのかといえば、全然そんなことないよね。
でも単体テストで「多くのバグを」発見できるから、
静的型付けでも単体テストをやってる。

単体テストはコンパイル時型検査の完全な代替にはならないが、
「多くのバグを」発見できるというのは経験上正しい。

一方の「多くのバグを」が有効で、他方の「多くのバグを」が誇張だというのは
よほど定量的なデータで裏付けないと正当化できないと思うが？

0605デフォルトの名無しさん

2013/03/21(木) 06:37:02.83

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

0606デフォルトの名無しさん

2013/03/21(木) 06:44:47.69

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

0607デフォルトの名無しさん

2013/03/21(木) 08:04:18.44

Javaと静的にも動的にも書けるGroovyの両方を使った開発を会社でやっているけれども、
Groovyで書くコードも公開メソッドは型付きで書くようにチームで徹底している。

理由は幾つかあるけれども、とりあえず引数や返り値の型については動的だろうが静的
だろうが結局ドキュメンテーションの際に明記することになるのであまり手間じゃない。
中身はそれぞれ静的に書いたり動的に書いたりしている。

単体テストの打率はそんなに変わらない感じ。テスト対象となるメソッド等々は個人個人で
見通しがきく大きさだし。ただ統合テスト時など他人の書いた部分を叩く際の凡ミスや仕様
変更の見落としは確実に少なくなる印象。同様にGroovyからJava側のAPIを呼び出す時も
基本的には型付きなど、要所要所の界面で型を利用して依存関係を追跡し易くする方針。

界面でいえば社内用にGroovyで書いていたREST APIを顧客向けにテスト公開する際には
Javaで全部書き直した。リソースクラスのメソッドについた引数の型やクラス定義などを
読んで入出力のJSONモデルも含めたREST APIのドキュメントやテスト用のWeb UIを自動
生成するツールがJava側には幾つかあったので。移行は手間だったけれども移行後はドキュ
メント管理などが格段に楽になった。

要所要所で使えば凄く便利だと思うけれどもね、型。
Python3.0の関数アノテーションみたいにAPIの部分に型情報をつけるのは御利益も大きいよ。

0608デフォルトの名無しさん

2013/03/21(木) 09:11:44.31

>>607
>単体テストの打率はそんなに変わらない感じ。テスト対象となるメソッド等々は個人個人で
>見通しがきく大きさだし。

この辺りは自分の経験とも合致していて同意。

> ただ統合テスト時など他人の書いた部分を叩く際の凡ミスや仕様
>変更の見落としは確実に少なくなる印象。

モジュール単位での開発+結合テストなスタイルだと、オレの経験でも同じ。

CI重視で各モジュール単位の開発中にも継続的に結合テスト相当も単体テストと一緒にやるスタイルだとどうだろう、という興味がある。
そういうスタイルは自分では動的型言語での経験しかない。
CI重視だと動的型言語でもモジュール間結合の問題も十分早期にバグを発見できる。
コード書きながらパラレルにxUnit動かすから、コードをsaveした数秒～数十秒後には単純な型不整合は発見できる。
つまり、事実上コンパイルと同じ早さ。
静的型言語ではそれより効果が出るのか興味ある。

0609デフォルトの名無しさん

2013/03/21(木) 09:56:21.73

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

0610デフォルトの名無しさん

2013/03/21(木) 10:02:19.57

>>608
> コードをsaveした数秒～数十秒後には単純な型不整合は発見できる。

それだとどれくらいの間隔でsaveするかだな。
静的型付け言語だとIDEの機能ではあるが
コードを書いた直後に発見できる。

0611デフォルトの名無しさん

2013/03/21(木) 10:09:13.64

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

0612デフォルトの名無しさん

2013/03/21(木) 10:14:19.67

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

0613デフォルトの名無しさん

2013/03/21(木) 10:26:24.25

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

0614デフォルトの名無しさん

2013/03/21(木) 10:33:16.12

>>611
そりゃそうだろｗ

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

0615デフォルトの名無しさん

2013/03/21(木) 10:35:26.72

>>612
またSmalltalkかｗ

なんか、動的型付け言語でも問題ないというよりか
Smalltaklなら問題ないって話に見えてきた。

今度からSmalltalkはちゃんと明記しないか？

0616デフォルトの名無しさん

2013/03/21(木) 10:38:05.84

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

0617デフォルトの名無しさん

2013/03/21(木) 10:44:20.37

>>608
そうありたいというか、今まさにテストのイテレーションの遅さが問題になっていて環境改善の
真っ最中なのでw
型付きで型付きのAPIを呼び出したときは確かに凡ミスは即座に解る。便利。でもそっちよりも
色々な単位でテストを素早く繰り返し行える環境の方が遙かに便利な感じで、静的云々はあまり
関係無いような気もする。

ただ呼び出しの不整合等々は各ブランチ内での開発中よりもむしろマージ段階で起こるケースが
厄介だと思う。マージ後の検証は大抵大きな単位でテストを走らせる必要があるので、その前に
静的に見つけられるものは見つけられた方が嬉しい。延々と走らせたテストが凡ミスでこけると
かなり切ないので。

あとは上にも書いたけれども界面を型付きで書くとファイルやプロジェクトをまたがった依存性
をかなりカッチリ把握できるので、何をするにしても影響範囲などを事前に把握しやすい分析面
での御利益は大きい。

蛇足ながらEclipseでGroovyを書くと静的に型を確定できない変数アクセスやメソッド呼び出し
は黒地のイタリックにアンダーラインという、見た目的にかなりイヤンなスタイルで表示される
ので、見た目の改善のため自ずと型を書いてしまうと言う副次的効果はある。個人的に。

0618デフォルトの名無しさん

2013/03/21(木) 11:07:07.06

> 延々と走らせたテストが凡ミスでこけるとかなり切ないので。

まさにこれなんだよなぁ。
人間である以上ミスは避けられない。
そんなつまらないミスで時間とられることが
苦痛じゃないのかって思うわけだけど。

0619デフォルトの名無しさん

2013/03/21(木) 11:10:49.77

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

大規模だと単体テストでも全部やれば数分かかるんだよ。

0620デフォルトの名無しさん

2013/03/21(木) 11:13:03.24

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

あほらしw

0621デフォルトの名無しさん

2013/03/21(木) 11:15:03.11

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

あまりにも原始的すぎねーか？

0622デフォルトの名無しさん

2013/03/21(木) 11:40:13.76

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

静的型付け言語なら、リンクするための
情報などから静的にわかるけどさ。

0623デフォルトの名無しさん

2013/03/21(木) 11:41:06.48

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

0624デフォルトの名無しさん

2013/03/21(木) 12:14:13.04

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

0625デフォルトの名無しさん

2013/03/21(木) 12:17:50.11

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

0626デフォルトの名無しさん

2013/03/21(木) 12:20:02.38

Smalltalkなら標準機能だけで簡単だけど
Smalltalk以外でも簡単にフィルタ書けると思うけど？

ツールも一切合切用意されてないと何もできないタイプ？

0627デフォルトの名無しさん

2013/03/21(木) 12:28:37.06

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

0628デフォルトの名無しさん

2013/03/21(木) 12:40:28.00

自分が知らないものは除外したがる不勉強な奴がいて困る。

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

0629デフォルトの名無しさん

2013/03/21(木) 13:20:29.95

> それに別にSmalltalkは動的型言語としては何も特殊なことは
> やっていないんだがな。

動画見ても十分やってるじゃん。

他の言語で、あんなエディタ使ってるか？
普通テキストエディタで書くんだよ。

0630デフォルトの名無しさん

2013/03/21(木) 13:21:53.99

>>628
> 自分が知らないものは除外したがる不勉強な奴がいて困る。

全くだ。Smalltalk以外の
動的言語使ってる奴はどうした？
その話が全く出てないぞ。
知らないのかな？

0631デフォルトの名無しさん

2013/03/21(木) 13:55:28.17

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

0632デフォルトの名無しさん

2013/03/21(木) 13:57:46.99

> Smalltalkのコンパイルは原則メソッド単位。

それが特殊って気づかないのかな？

0633デフォルトの名無しさん

2013/03/21(木) 15:49:08.09

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

0634デフォルトの名無しさん

2013/03/21(木) 16:11:37.83

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

0635デフォルトの名無しさん

2013/03/21(木) 16:57:25.77

>>633
イメージってったって要はナンチャッテOODBだろ？
OODBに永続化されたデータで処理系を作って動かしたという点は
特殊かもしれないけれど、
それは動的型であることとはさほど関係ないように思うのだが

アラン・ケイだってもっと賢い型システムがあれば動的型にはこだわらない
って言っているわけだし。
http://d.hatena.ne.jp/nishiohirokazu/20100919/1284885238

0636デフォルトの名無しさん

2013/03/21(木) 17:05:24.47

イメージベースで可能なことは、ファイルベースでも可能ではあるよ。
単にツールを充実させるモチベーションの問題だと思う。

ファイルベースだと、>>629が書くように、エディタ使えばいいという発想になる。
だからEclipseスゲーとか思って満足してしまう。

イメージベースだと、汎用エディタでプログラミングできるわけじゃない。
Smalltalkのブラウザはテキストエディタの拡張じゃなくて、クラスのUIなんだ。
だからより良い対話を実現するためにコードコンプリーションやリファクタリングブラウザが発明される。
ライブラリとのより良い対話を実現するためにSUnitが発明され、xUnitに発展する。

0637デフォルトの名無しさん

2013/03/21(木) 17:11:06.33

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

0638デフォルトの名無しさん

2013/03/21(木) 17:27:21.39

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

0639デフォルトの名無しさん

2013/03/21(木) 17:28:22.50

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

0640デフォルトの名無しさん

2013/03/21(木) 17:45:52.14

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

0641デフォルトの名無しさん

2013/03/21(木) 17:53:21.36

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

0642デフォルトの名無しさん

2013/03/21(木) 18:03:38.07

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

0643デフォルトの名無しさん

2013/03/21(木) 18:06:13.06

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

0644デフォルトの名無しさん

2013/03/21(木) 18:51:08.30

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

http://www.cincomsmalltalk.com/present/XML2Object.pdf の14ページ

0645デフォルトの名無しさん

2013/03/21(木) 19:45:52.52

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

0646デフォルトの名無しさん

2013/03/21(木) 20:59:50.27

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

0647デフォルトの名無しさん

2013/03/22(金) 00:46:13.82

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

0648デフォルトの名無しさん

2013/03/22(金) 00:47:50.26

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

0649デフォルトの名無しさん

2013/03/22(金) 00:54:53.45

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

0650デフォルトの名無しさん

2013/03/22(金) 02:23:48.26

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

0651デフォルトの名無しさん

2013/03/22(金) 03:24:46.27

ぶっちゃけマニアックな言語だと、簡潔に書けるって言われても
どれくらい簡潔なのかイメージが湧かないので、
次のXMLをデシリアライズして、
・x, y, zがdoubleとintとstringになってることを示して、
・次にdoubleとintは+1して、stringには'test'を足して、
最後にシリアライズするコード書いてみて欲しい。

<root xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";>
<x xsi:type="xsd:double">1</x>
<y xsi:type="xsd:int">1</y>
<z xsi:type="xsd:string">1</z>
</root>

0652デフォルトの名無しさん

2013/03/22(金) 04:00:46.00

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

0653デフォルトの名無しさん

2013/03/22(金) 05:24:55.30

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

0654デフォルトの名無しさん

2013/03/22(金) 06:33:02.16

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

0655デフォルトの名無しさん

2013/03/22(金) 07:37:02.60

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

0656デフォルトの名無しさん

2013/03/22(金) 20:25:31.67

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

0657デフォルトの名無しさん

2013/03/22(金) 23:26:50.20

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

0658デフォルトの名無しさん

2013/03/22(金) 23:35:23.66

ジェイソン地獄大好きｗ

0659デフォルトの名無しさん

2013/03/23(土) 04:33:05.96

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

0660デフォルトの名無しさん

2013/03/23(土) 05:09:35.40

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

0661デフォルトの名無しさん

2013/03/23(土) 06:02:16.84

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

0662659

2013/03/23(土) 06:05:50.45

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

0663デフォルトの名無しさん

2013/03/23(土) 06:06:44.88

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

0664デフォルトの名無しさん

2013/03/23(土) 06:08:06.20

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

0665デフォルトの名無しさん

2013/03/23(土) 06:08:15.53

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

0666デフォルトの名無しさん

2013/03/23(土) 06:10:53.72

>>663
へー、じゃあC1では全く不十分だねえ。
C4が必要だねえ。

どうしてC1で十分だと思ったんだろうねえw

0667デフォルトの名無しさん

2013/03/23(土) 06:14:13.51

>>666
C1って言い出したのはお前じゃないのか？

じゃあ ”お前の指摘通り正しく” 言い直すよ。

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

つまり、C4が必要。

それってめんどくさくない？

0668デフォルトの名無しさん

2013/03/23(土) 06:18:55.23

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

0669659

2013/03/23(土) 06:21:36.61

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

>>668
俺だわ。完全に俺が言い出してたわ。反省はしないし間違ってるとも思ってない。

0670デフォルトの名無しさん

2013/03/23(土) 06:22:13.57

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

0671デフォルトの名無しさん

2013/03/23(土) 06:23:39.53

>>670
誰かと間違ってるだろｗ

まあいい、出直してきたよ。
今、出直してきたよ

0672デフォルトの名無しさん

2013/03/23(土) 06:26:05.56

>>669
C1が100%でも引数として渡されるオブジェクトの種類を網羅できないだろ。
少なくともC4でないと。

で、C4が相手となると、動的型では100%達成どころか、計測することすら困難なわけだ。
結論としては、動的型では型安全をテストで「検証」することはできない。

0673デフォルトの名無しさん

2013/03/23(土) 06:26:56.49

例えばこんなミスがあるから
動的型付け言語では、C1テストが必要になる。

var obj; // 本来はAと互換性があるものしか入れてはいけない。
if(cond) {
　obj = new A();
} else {
　obj = new B();
}

//AとBに互換性はない。

foo(obj); //fooの引数はAと互換性があるものしか想定していない。

0674デフォルトの名無しさん

2013/03/23(土) 06:51:13.63

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

0675デフォルトの名無しさん

2013/03/23(土) 07:04:14.39

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

0676659

2013/03/23(土) 07:17:01.76

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

0677659

2013/03/23(土) 07:39:06.44

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

0678デフォルトの名無しさん

2013/03/23(土) 08:15:58.54

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

0679デフォルトの名無しさん

2013/03/23(土) 08:41:35.91

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

0680デフォルトの名無しさん

2013/03/23(土) 08:44:21.13

Javaエバンジェリストの人は、
コード行数や必要なクラス数が減ると
開発生産性が向上するって力説してたよ

ttp://www.flickr.com/photos/33583790@N00/7465233960/

0681デフォルトの名無しさん

2013/03/23(土) 08:54:09.71

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

設計レベルでの修正を繰り返すのと、実装レベルのやりくりを繰り返すのと、
最終的にどちらがよいかは、案件の特性による。

0682デフォルトの名無しさん

2013/03/23(土) 08:59:53.08

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

0683デフォルトの名無しさん

2013/03/23(土) 09:03:22.35

Pythonの邪悪な非同期IOライブラリgeventは
標準のsocket, ssl, threading, selectなどにモンキーパッチを当てる事で
多くのブロックするシステムコールを協調的に動作するように変更できる。

http://methane.github.com/gevent-tutorial-ja/

> 例えば、 Redis の Python バインディングは通常の TCP ソケットを使って
> redis-server インスタンスと通信します。 gevent.monkey.patch_all() を実行するだけで、
> redis バインディングは協調的にリクエストをするようになり、
> その他の gevent のスタックと一緒に動くようになります。

> モンキーパッチを使えば、そのままでは gevent で動作しないライブラリを
> 1行のコードを書くだけで統合できるようになります。モンキーパッチは邪悪ですが、この場合は必要悪です。

0684デフォルトの名無しさん

2013/03/23(土) 15:09:50.46

>>680
そりゃ同じ言語での場合の話だ。

特に静的型付け言語と動的型付け言語では
コードに含まれる情報量が違うので
一概に比較はできん

0685デフォルトの名無しさん

2013/03/23(土) 15:13:00.28

>>683
いや、それ邪悪じゃんｗ
標準ライブラリの内部コードが変更されたらどうする。

ラップしたライブラリを作って作るか、
標準機能にパッチを取り込ませるのが
正しい対応方法だよ。

0686デフォルトの名無しさん

2013/03/23(土) 19:00:49.36

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

0687デフォルトの名無しさん

2013/03/23(土) 20:00:10.51

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

0688デフォルトの名無しさん

2013/03/23(土) 20:12:09.43

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

0689デフォルトの名無しさん

2013/03/23(土) 20:43:46.94

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

0690デフォルトの名無しさん

2013/03/23(土) 21:36:33.84

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

0691デフォルトの名無しさん

2013/03/23(土) 22:46:17.26

>>690
> 流石に基本クラスを書き換えるようなことはしないけど

書き換えることまでは出来ないけど、ではなく？

0692デフォルトの名無しさん

2013/03/23(土) 23:10:28.32

>>691
書き換え出来るよ。java.lang.Stringにパッチをあてるとか。

ただ基本クラスはルートのクラスローダーで読まれるので扱いは静的で、他のユーザー
クラスのように実行コンテキスト毎に異なるクラス実装を使用したりも出来ない。
あとライセンスの関係で配布が出来ない。

0693デフォルトの名無しさん

2013/03/24(日) 07:15:09.45

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

0694デフォルトの名無しさん

2013/03/24(日) 07:24:22.42

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

0695デフォルトの名無しさん

2013/03/24(日) 07:57:19.43

> 実行時にホットパッチを当てるのはJavaでも全然珍しくないし、

うんうん、全然珍しく無いよね。
だからそういうコードが「より簡潔に」書ける言語が良いってわけだ。

0696デフォルトの名無しさん

2013/03/24(日) 08:34:05.10

いや、普通やらないだろ。
そんなことすると互換性の問題が発生する。

となるとやっぱり不要ってなるわけだが？

0697デフォルトの名無しさん

2013/03/24(日) 08:37:37.69

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

0698デフォルトの名無しさん

2013/03/24(日) 08:47:03.50

基本クラスにモンキーパッチ当てないと使えないようなものは他の物と組み合わせてつかい
にくいと思うのだけど。他のコンポーネントへの副作用とか出てくるでしょ。

prototype.jsがまさに基本クラス拡張型だったな。その教訓を受けてかjQueryはラッパー型で、
DOMのエレメントやそのprototypeをいじって拡張することは殆どない。

0699デフォルトの名無しさん

2013/03/24(日) 08:48:16.69

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

0700デフォルトの名無しさん

2013/03/24(日) 09:03:04.09

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

0701デフォルトの名無しさん

2013/03/24(日) 09:04:38.90

>>700
>>699

0702デフォルトの名無しさん

2013/03/24(日) 10:47:19.21

>>697
> ベースライブラリへのモンキーパッチでどう互換性の問題が発生するんだい？

ベースライブラリはモンキーパッチを当てると、
ベースライブラリの挙動が変わる。

その結果、他のライブラリの挙動が変わる。
また、ベースライブラリ自体がバージョンアップした時、
そのような結果が起きるか想像できない。
いいことは何も起こらない。

0703デフォルトの名無しさん

2013/03/24(日) 10:49:51.01

Prototype.jsが廃れていった原因の一つも
ベースライブラリへのモンキーパッチ。

そのせいでPrototype.js以外のライブラリが
正しく動かなくなるなどの問題が起きた。
Prototype.jsを組み込んで大丈夫か検証する必要があった。

0704デフォルトの名無しさん

2013/03/24(日) 11:07:06.42

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

0705デフォルトの名無しさん

2013/03/24(日) 11:11:34.83

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

0706デフォルトの名無しさん

2013/03/24(日) 11:15:08.48

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

まあ、どうせできないだろうが

0707デフォルトの名無しさん

2013/03/24(日) 11:24:30.07

一応、Prototype.jsの開発者もダメだったことは認めてて、

http://perfectionkills.com/whats-wrong-with-extending-the-dom/

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

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

0708デフォルトの名無しさん

2013/03/24(日) 11:40:41.69

>>702
> その結果、他のライブラリの挙動が変わる。

まさに、それを目的としてパッチをあてるんだが

> また、ベースライブラリ自体がバージョンアップした時、
> そのような結果が起きるか想像できない。

パッチを当てなくても同じじゃん

0709デフォルトの名無しさん

2013/03/24(日) 11:53:45.29

>>706
Prototype JavaScriptライブラリの歴史を紐解いてみましょう。
PrototypeはあらゆるJavaScriptオブジェクトを変更する機能で有名でした。

バージョン1.6以前のPrototypeにはdocument.getElementsByClassName()と
いうメソッドが実装されていました。

Prototypeのdocument.getElementsByClassName()メソッドは、指定されたCSS
クラスを含む要素の配列を返しました。Prototypeでは配列にもメソッドが追加されていて
Array.Prototype.each()は配列に順にイテレートし、各項目に対して関数を実行しました。
この機能によって開発者は次のようなコードを書くようになりました。

　document.getElementsByClassName("selected").each(doSomething);

HTML5でこのメソッドが標準化され、これをブラウザがネイティブで実装するようになるまで
このコードが問題になることはありませんでした。

HTML5のdocument.getElementsByClassName()は配列を返さなかったで、each()メソッドは
存在しませんでした。

document.getElementsByClassName()は他のDOMメソッドと合わせるためにNodeListを返しました。

NodeListにはeach()メソッドがないので、document.getElementsByClassName()メソッドが
ネイティブで実装されているブラウザで実装すると、ネイティブでもPrototypeで追加された場合でも、
each()を使うとJavaScriptのエラーが発生しました。その結果としてPrototypeのユーザーは
ライブラリコードと自分のコードの両方をアップグレードしなければならず、メンテナンスが
悪夢になりました。

Prototpypeの失敗から学びましょう。JavaScriptが将来どのように変化するのか、正確な予測はできません。

『メンテナブルJavaScript』 P111 「11章所有していないオブジェクトを変更しない」より
一部抜粋

0710デフォルトの名無しさん

2013/03/24(日) 11:57:15.08

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

0711デフォルトの名無しさん

2013/03/24(日) 11:58:26.09

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

0712デフォルトの名無しさん

2013/03/24(日) 12:10:36.08

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

0713デフォルトの名無しさん

2013/03/24(日) 12:22:43.88

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

0714デフォルトの名無しさん

2013/03/24(日) 12:24:06.69

> PrototypeはあらゆるJavaScriptオブジェクトを変更する機能で有名でした。

強力な機能だからこそ、ここぞという所で使うんだよ。

でも馬鹿には0と1しか無いんだよね。
使うか使わないかの二択より難しいことは考えられない。

0715デフォルトの名無しさん

2013/03/24(日) 12:42:22.07

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

0716デフォルトの名無しさん

2013/03/24(日) 12:51:56.40

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

0717デフォルトの名無しさん

2013/03/24(日) 13:32:59.59

利用例が無理やりすぎ。

モンキーパッチを使わないで
正攻法を使ったほうがいい。

モンキーパッチは不具合の元。

0718デフォルトの名無しさん

2013/03/24(日) 13:35:13.06

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

0719デフォルトの名無しさん

2013/03/24(日) 14:45:53.59

>>717
sockscap

0720デフォルトの名無しさん

2013/03/25(月) 03:41:21.73

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

0721デフォルトの名無しさん

2013/03/25(月) 07:46:42.74

このスレって延々と論争してるけど、
結局のところ想定してるプログラマ像が違いすぎるのが原因だから

「ドカタに使わせるにはどんな言語が良いか」

というテーマなら速やかに合意に達すると思う

0722デフォルトの名無しさん

2013/03/25(月) 11:54:45.40

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

0723デフォルトの名無しさん

2013/03/25(月) 12:02:27.87

COBOL もあるぜ

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

0724デフォルトの名無しさん

2013/03/25(月) 20:17:05.82

VBのことも忘れないで！

0725桃白白

2013/03/25(月) 20:38:31.83

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

0726デフォルトの名無しさん

2013/03/25(月) 20:44:26.06

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

0727デフォルトの名無しさん

2013/03/25(月) 20:55:24.73

Javaに +1

0728デフォルトの名無しさん

2013/03/25(月) 21:35:57.38

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

0729デフォルトの名無しさん

2013/03/26(火) 06:06:42.72

>>725
概してモンチーパッチの類を使うと将来の変化に弱くなる。

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

0730デフォルトの名無しさん

2013/03/26(火) 06:08:07.12

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

そう、ドカタはね

0731デフォルトの名無しさん

2013/03/26(火) 06:43:13.21

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

0732デフォルトの名無しさん

2013/03/26(火) 09:10:30.48

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

0733デフォルトの名無しさん

2013/03/27(水) 21:47:26.36

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

0734デフォルトの名無しさん

2013/03/27(水) 21:48:17.16

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

0735デフォルトの名無しさん

2013/03/27(水) 23:43:31.51

>>733
asm.jsってJavaScriptのサブセットだよ。

JavaScriptから動的型付け言語の性質を抜き去った
命令だけを使うことで速くできる。

asm.jsで書くと動的型付け言語のメリットがないのだから
やっぱり静的型付け言語の方が速いねという結論にしかならないよ。

0736デフォルトの名無しさん

2013/03/28(木) 00:37:06.50

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

0737デフォルトの名無しさん

2013/03/28(木) 02:06:42.50

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

0738デフォルトの名無しさん

2013/03/28(木) 02:17:44.79

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

0739デフォルトの名無しさん

2013/03/28(木) 02:20:03.83

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

0740デフォルトの名無しさん

2013/03/28(木) 07:09:19.08

vimは超優秀

0741デフォルトの名無しさん

2013/03/28(木) 07:11:24.97

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

0742デフォルトの名無しさん

2013/03/28(木) 07:13:48.10

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

0743デフォルトの名無しさん

2013/03/28(木) 07:23:46.51

まあMavenだな。IDE使わずともビルドやテストはコマンド一発なのでテキストエディタ使用の
ドカタでも全然大丈夫。

ドカタがMavenプロジェクトを作れるかはまた別問題w MakeやAntよりは遙かに簡単だけど。

0744デフォルトの名無しさん

2013/03/28(木) 09:22:55.67

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

0745デフォルトの名無しさん

2013/03/28(木) 21:28:39.07

>>742
Javaは人間じゃないです。

なんで人間の問題なのに
Javaって言語の問題かのように言い方をするの？

0746デフォルトの名無しさん

2013/03/28(木) 21:29:57.07

>>744
あんたantやmavenわかってないんじゃない？

あれはシステムrailsみたいに用意して少し設定すれば
勝手に裏でやってくれるもの

コード少し直した程度じゃ、何も触るところはない。

0747デフォルトの名無しさん

2013/03/29(金) 14:36:11.49

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

0748デフォルトの名無しさん

2013/03/29(金) 14:52:59.38

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

0749デフォルトの名無しさん

2013/03/29(金) 14:58:27.68

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

0750デフォルトの名無しさん

2013/03/29(金) 20:02:14.80

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

0751デフォルトの名無しさん

2013/03/29(金) 22:29:45.65

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

0752デフォルトの名無しさん

2013/03/29(金) 22:32:31.95

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

0753デフォルトの名無しさん

2013/03/29(金) 23:09:27.01

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

0754デフォルトの名無しさん

2013/03/29(金) 23:41:29.24

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

0755デフォルトの名無しさん

2013/03/30(土) 00:33:14.96

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

0756デフォルトの名無しさん

2013/03/30(土) 07:11:13.96

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

0757デフォルトの名無しさん

2013/04/14(日) 20:43:46.28

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

0758デフォルトの名無しさん

2013/04/24(水) 14:48:37.98

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

0759デフォルトの名無しさん

2013/04/24(水) 15:15:34.42

>>758
先進なんだろう。

0760デフォルトの名無しさん

2013/05/20(月) 23:01:31.12

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

0761デフォルトの名無しさん

2013/05/23(木) 15:55:33.74

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

0762デフォルトの名無しさん

2013/05/25(土) 17:42:44.93

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

0763デフォルトの名無しさん

2013/05/25(土) 19:01:00.20

主流？

0764デフォルトの名無しさん

2013/07/07(日) NY:AN:NY.AN

生産性は動的言語

保守性が静的言語

0765デフォルトの名無しさん

2013/07/07(日) NY:AN:NY.AN

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

0766デフォルトの名無しさん

2013/07/07(日) NY:AN:NY.AN

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

0767デフォルトの名無しさん

2013/07/07(日) NY:AN:NY.AN

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

0768デフォルトの名無しさん

2013/07/07(日) NY:AN:NY.AN

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

0769デフォルトの名無しさん

2013/07/07(日) NY:AN:NY.AN

話の内容が全然具体的でないな。

まあ、いつものことだが (w

0770デフォルトの名無しさん

2013/07/07(日) NY:AN:NY.AN

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

0771デフォルトの名無しさん

2013/07/07(日) NY:AN:NY.AN

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

0772デフォルトの名無しさん

2013/07/07(日) NY:AN:NY.AN

だな

0773デフォルトの名無しさん

2013/07/07(日) NY:AN:NY.AN

無理して一つの言語に固執せんでもってこったな

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

0774デフォルトの名無しさん

2013/07/11(木) NY:AN:NY.AN

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

0775デフォルトの名無しさん

2013/07/11(木) NY:AN:NY.AN

>>774
言いたい事はわかるし、真意を汲めばこそ突っ込みたくは無いのだが…

「わざとエラーにする」ってのは日本語がおかしいぞ

0776デフォルトの名無しさん

2013/07/11(木) NY:AN:NY.AN

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

0777デフォルトの名無しさん

2013/07/11(木) NY:AN:NY.AN

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

0778デフォルトの名無しさん

2013/07/11(木) NY:AN:NY.AN

>>776
「エラーをわざと発生させる」って>>774が。
あの文脈だと「わざとエラーにする」と読める。

もちろん真意は、
間違えて組んだら、コンパイルエラーとなるように、意図的に仕込んでおく、
という事だと思うんだけどね。

0779デフォルトの名無しさん

2013/07/20(土) NY:AN:NY.AN

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

0780デフォルトの名無しさん

2013/07/20(土) NY:AN:NY.AN

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

0781デフォルトの名無しさん

2013/07/21(日) NY:AN:NY.AN

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

0782デフォルトの名無しさん

2013/07/22(月) NY:AN:NY.AN

わかるー

0783デフォルトの名無しさん

2013/07/22(月) NY:AN:NY.AN

まさかMS

0784デフォルトの名無しさん

2013/08/05(月) NY:AN:NY.AN

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

0785デフォルトの名無しさん

2013/08/05(月) NY:AN:NY.AN

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

反対側と同じように書こうとすると上手くいかないと思うし
生産性も上がらないと思う

0786デフォルトの名無しさん

2013/08/05(月) NY:AN:NY.AN

機動性に優れているのが一番

一戸建て住宅　　　＝　静的型付け
キャンピングカー　＝　動的型付け

0787デフォルトの名無しさん

2013/08/05(月) NY:AN:NY.AN

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

0788デフォルトの名無しさん

2013/08/05(月) NY:AN:NY.AN

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

0789デフォルトの名無しさん

2013/08/05(月) NY:AN:NY.AN

なんだよ、たまたま動くとかテストに漏れがあるとか
静的、動的関係ないじゃんか。

静的が凄いのは、その名の通り静的であるということ。
コードが定義でできてる。

コードを動かすことなく決まるから、
実行させなくても、いろんな解析ができるということ。
実行時間0（解析時間だけ）で情報が得られる。

実行させればわかるというが、実行させるには時間がかかる。
実行しなければ状態が確定しないということは、
変数によって状態がいろいろ変わることがあるということ。

規模が大きくなればなるほど、いろんな状態によって
答えが変わる動的言語は、解析とテストが大変になる。

0790デフォルトの名無しさん

2013/08/05(月) NY:AN:NY.AN

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

0791デフォルトの名無しさん

2013/08/06(火) NY:AN:NY.AN

まあ、適材適所だね

0792デフォルトの名無しさん

2013/08/06(火) NY:AN:NY.AN

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

0793デフォルトの名無しさん

2013/08/06(火) NY:AN:NY.AN

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

0794デフォルトの名無しさん

2013/08/06(火) NY:AN:NY.AN

>>792
その計算には、プロジェクトの規模が含まれてないだろ？

小さいものを作るときはいいかもしれんが、
数人以上で数ヶ月、ファイル・クラス数十個なんて
ものを作るとき、保守性が悪いのが動的言語だよ。

0795デフォルトの名無しさん

2013/08/06(火) NY:AN:NY.AN

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

0796デフォルトの名無しさん

2013/08/22(木) NY:AN:NY.AN

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

0797デフォルトの名無しさん

2013/08/23(金) NY:AN:NY.AN

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

0798デフォルトの名無しさん

2013/08/23(金) NY:AN:NY.AN

大規模プロジェクトと呼ばれるものの大半は
ゴミを集めて人数が膨れ上がったプロジェクトを意味する

ゴミだから動的な特性なんて使いこなせないし、テストも書かないので
静的型チェックによる僅かな品質向上に望みをかけるしか無い

0799デフォルトの名無しさん

2013/08/23(金) NY:AN:NY.AN

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

0800デフォルトの名無しさん

2013/08/25(日) NY:AN:NY.AN

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

0801デフォルトの名無しさん

2013/08/25(日) NY:AN:NY.AN

>>800
つまり、Javaではローカル変数を初期化しないのがベストプラクティスで
あるということか？

0802デフォルトの名無しさん

2013/08/25(日) NY:AN:NY.AN

初期化のための初期化でゴミを入れるなってこと

0803デフォルトの名無しさん

2013/08/25(日) NY:AN:NY.AN

>>802
初期値が間違ってるってことねなるほど。
変数は必要になったときに宣言するようにすれば問題ない。

0804デフォルトの名無しさん

2013/08/25(日) NY:AN:NY.AN

>>801
文脈として初期値が必要なケースでなければね

例えば以下の例はエラーになる。
以下の例は例外が起きたら別の処理を行ってから再び例外を投げたいものとする。

String value;
try {
value = ...
} catch (Exception ex) {
doSomething();
}
AnyClass obj = new AnyClass(value);
...

これは仮に value を null で初期化してたら
コンパイラがやってくれるチェックを自分ですることになる。

0805デフォルトの名無しさん

2013/08/25(日) NY:AN:NY.AN

>>804
うーん？
間違った初期値を設定することが問題なんだよね？
だったら初期値なんか書くなと言うのは論点がおかしくないか？

0806デフォルトの名無しさん

2013/08/25(日) NY:AN:NY.AN

ローカル変数だけしかチェックできないウンコじゃん
静的型言語の面汚しだよね

0807デフォルトの名無しさん

2013/08/25(日) NY:AN:NY.AN

フィールドはdefaultで初期化されるからな

0808デフォルトの名無しさん

2013/08/25(日) NY:AN:NY.AN

>>805
初期化してないとコンパイラが止めるんだよ
その止めるという機能が恩恵にあずかっている機能
throw exで再度例外を投げればコンパイルエラーにはならない
つまり正常系のみ処理が進むことが保証される

0809デフォルトの名無しさん

2013/08/25(日) NY:AN:NY.AN

そのコードがどういう状況で到達可能なのかをJavaコンパイラはある程度理解している
到達不可能ケースで未初期化変数を参照してもコンパイラは無視するし問題にもならない

0810デフォルトの名無しさん

2013/08/25(日) NY:AN:NY.AN

>>807
ぬるぽですね

0811デフォルトの名無しさん

2013/08/25(日) NY:AN:NY.AN

どのみちオラクルの手に渡った時点でおわこんだよ

0812デフォルトの名無しさん

2013/08/25(日) NY:AN:NY.AN

オラコン

0813デフォルトの名無しさん

2013/08/25(日) NY:AN:NY.AN

預言者オワクル

0814デフォルトの名無しさん

2013/08/26(月) NY:AN:NY.AN

オリハルコン

0815デフォルトの名無しさん

2013/08/26(月) NY:AN:NY.AN

　
＼＼
＼＼＼
＼　 ∧＿∧
　　（ ´・ω・）
　　G　　と）　ｶﾞｯ >>810
　　ヽ⌒)､＼人∧__∧
　　　￣　（＿） >｀д´）')
　　　　　　　　 ∨つ　　 /

0816デフォルトの名無しさん

2013/08/29(木) NY:AN:NY.AN

F#の生産性が高すぎて人生が辛い(´・ω・｀)

0817デフォルトの名無しさん

2013/08/30(金) NY:AN:NY.AN

お前らバイトです

がんばってください

暑いならビール

0818デフォルトの名無しさん

2013/08/30(金) NY:AN:NY.AN

そんなにF#いいのん？

0819デフォルトの名無しさん

2013/08/30(金) NY:AN:NY.AN

すごいHaskell
もっとすごいF#

0820デフォルトの名無しさん

2013/08/30(金) NY:AN:NY.AN

言語的にはHaskellやLispの方がイイかもだけどC#よりははるかに上。

IDEとかライブラリ含めた総合力ではトップクラスだと思う

0821デフォルトの名無しさん

2013/08/30(金) NY:AN:NY.AN

>>820
HaskellとかLispのどこがいいんだよ

0822デフォルトの名無しさん

2013/08/30(金) NY:AN:NY.AN

Webサービスか
それともスクリプトから呼ばれるライブラリか

0823デフォルトの名無しさん

2013/08/30(金) NY:AN:NY.AN

F#は実行時に決まる部分が多すぎだろ。
.NETの呪縛から逃げ切れてない。

0824デフォルトの名無しさん

2013/08/30(金) NY:AN:NY.AN

だな、コンパイル終了の時点で要求メモリ量が分からないなんて、
大規模計算処理では使い物にならん

この条件を満たすのは COBOL/FORTRAN/C などで、
これらはどれも実世界の社会インフラを支える本物のプログラミング言語だ

JavaやらC#みたいな実行時にメモリを割り当て、
そのあげくに不要になったゴミ回収が必要になるなんて、
これらがお子様むけのオモチャ言語である証拠だ

こうですか？よくわかりません　........

0825デフォルトの名無しさん

2013/08/30(金) NY:AN:NY.AN

>>823
どのへん？OCamlだとその辺は良いもんなん？

0826デフォルトの名無しさん

2013/08/30(金) NY:AN:NY.AN

>>825
Ocamlは知らん。
F#は型の取り扱いがJavaみたいで面倒。

0827デフォルトの名無しさん

2013/08/30(金) NY:AN:NY.AN

Ocamlって岡村って人が作った言語ですか？

0828デフォルトの名無しさん

2013/08/31(土) NY:AN:NY.AN

そうです。
同様の言語にMTsumt(通称Ruby)があります。

0829デフォルトの名無しさん

2013/08/31(土) NY:AN:NY.AN

>>826
何がJavaみたいなんだか分からん。イイと思う言語とのひかくでよろ

0830デフォルトの名無しさん

2013/08/31(土) NY:AN:NY.AN

Lispはゴミ
いまどきLispなんて使っているバカは頭がクルクルパー

0831デフォルトの名無しさん

2013/09/01(日) 09:01:26.40

Clojourならどうよ

0832デフォルトの名無しさん

2013/09/01(日) 10:40:31.79

名前も覚えられないのに勧めるなんて

0833デフォルトの名無しさん

2013/09/01(日) 11:13:49.94

一時期clojureのステマが酷かったけど
全然流行らなかったな

0834デフォルトの名無しさん

2013/09/02(月) 00:02:23.53

>>832
ケツの穴のちいせぇ男だな( ´Д`)y━･~~

>>883
まぁアレは番人が使うものではないんじゃないか。使う人は使ってるでしょ。

0835デフォルトの名無しさん

2013/09/02(月) 00:24:23.03

>>833
Lispが流行る(一般プログラマに受け入れられる)わけねーじゃん
あれはClojureのステマじゃなくてjvm言語ステマの一環です

0836デフォルトの名無しさん

2013/09/02(月) 23:46:49.93

>>834
安価もまともに打てないのに勧めるなんて

0837デフォルトの名無しさん

2013/10/02(水) 15:31:09.47

あれって、lisp周りの資産をそのままjavaで流用するためのものだろ
普通の業務開発のどんな場面でlisp資産を使うのか甚だ疑問
一般的な開発者には何の恩恵もないって。触るだけ時間の無駄

0838デフォルトの名無しさん

2013/10/02(水) 18:10:33.83

Lisp周りの資産をそのままJAVAで使うなら、ClojureではなくABCLを使うと思う。

0839デフォルトの名無しさん

2013/10/02(水) 19:39:56.19

>>837
開発対象がどうあれ生産性、保守性の高い言語を使うだけだろ。
まあ普通のプログラマはLispなんか使わず分相応のもの使ってればいいんじゃね？

0840デフォルトの名無しさん

2013/10/03(木) 02:28:55.83

今時のソフトウェアやシステム開発は言語単体もそうだけど、テストやデバッグ、
デプロイメント、ドキュメンテーションや運営等の周辺も色々含めての生産性に
なるんだけどね。使い捨てに近いコードを早く書けるってのだけじゃダメな段階に
なってきてる。

0841デフォルトの名無しさん

2013/10/03(木) 06:08:29.94

厳密性を取るなら関数型だが
これに柔軟性を加えるならJavaScriptのような
スクリプトLLしかありえない
工夫のない静的型付け言語はクソ

0842デフォルトの名無しさん

2013/10/03(木) 09:59:38.43

>>841
静的関数型では出来ない柔軟性ってどんなんよ。
でそれが必要な場面ってどんなんよ

0843デフォルトの名無しさん

2013/10/03(木) 10:26:56.39

できるできないじゃなくて潜在開発生産性は一番少ないってことだな。
至極当然。

0844デフォルトの名無しさん

2013/10/03(木) 11:43:38.17

だから、そう思う理由を尋ねられてんだろアホ

0845デフォルトの名無しさん

2013/10/03(木) 12:17:13.59

C#とF＃メインで使っていて、この間HTML5の技術検証でjavascript触ったけど生産性の低さにびっくりしたわ。
動かすまでわからないタイポ、イミフなスコープ、イミフなthis。このthisは何を指すかがクイズになるぐらいイミフw
メソッドヒョコヒョコ付け足したり便利なとこもあるかもだがそれを押しつぶすほどのイミフな仕様でもううんざりですよ(´・ω・｀)

0846デフォルトの名無しさん

2013/10/03(木) 12:39:06.87

>>845
そりゃよく知らない言語使えば生産性落ちるだろ
静的型付け言語なら言語仕様知らなくても生産性が高いっていう主張？
ていうかお前が言ってるのって、動的型付けっていうかJS固有の話だから

俺は静的型付け派だけど

0847デフォルトの名無しさん

2013/10/03(木) 14:28:15.39

>>845
そこら辺が安定していてバカでも書けるのが静的型付言語
Javaが典型的な例で、ただの静的型付言語には潜在性などない

逆に言うと可能性を無くすことで安定性、統一性、厳密性を取るのが
静的型付言語の最も基本となる性質だから当たり前
束縛のなく気楽な自由にこそ可能性はある

0848デフォルトの名無しさん

2013/10/03(木) 17:36:31.74

>>845-846
上でjavascriptがーとか言ってるから書いたんだけどなんか話の流れおかしいか？
jsは柔軟性のメリットとデメリットで後者が勝るだろって話だけど

0849デフォルトの名無しさん

2013/10/03(木) 17:46:25.76

おかしい。
LispからJavaScriptときて、やっぱり動的型付け言語の方が可能性あるよねって話の流れだから。
ましてや対して使ったこともない奴が１つの言語取り上げて云々言うのはスレチ。

それにメリットとデメリットなんて紙一重で表裏一体のもの。
それでも潜在能力はそちらの方が上だよねっていうスレタイに沿った流れ。

特定言語の批評ならここがオススメ。
http://toro.2ch.net/test/read.cgi/tech/1379350030

0850デフォルトの名無しさん

2013/10/03(木) 17:56:55.22

JavaScriptは当初は敬遠されてた
構文は10年前から殆ど変わってない
それなのに今では活躍してる
それは一言で言えば柔軟性のお陰

ES6,7を見ればわかるが
あんなに言語を拡張しても
後方互換性を失わなわずに済むのは
総じて柔軟性のお陰

柔軟性こそが直接潜在性に繋がる
静的型付け言語はその考え方と合わない
最近の主流に合わせるんなら最近出来た言語を使うか
結局後方互換性をなくして新しく設計しなければならない

つまり言語に可能性がない
言語に可能性がないのに開発の可能性なんてない
静的思考言語でそれを求めるんなら先に上げたように
別物に乗り移るしかない

今あるものに可能性、長期間の進化を求めるのならそりゃLLが一番に決まってる
その例としてJSは至極適当

0851デフォルトの名無しさん

2013/10/03(木) 20:23:59.98

>>849
何ができるようになるかって可能性と生産性は別の話だろ(´･_･`)

0852デフォルトの名無しさん

2013/10/03(木) 21:54:33.61

>>850
> それなのに今では活躍してる
> それは一言で言えば柔軟性のお陰

環境とライブラリが出来たからだろ？

言語としては普通だけど、
それだけじゃだめだってことだよ。

0853デフォルトの名無しさん

2013/10/04(金) 13:51:57.10

つまりその分可能性があるってことだなやっぱり。
といううか普通に考えてあらゆる意味で変更に強いのは動的型付け言語だし。
つうかこのスレ期待してたけど１つも「静的型付け言語の潜在開発生産性」とやらが示されてないんだけど？
批判するだけなのは楽でいいよな。

0854デフォルトの名無しさん

2013/10/04(金) 14:04:14.99

「変更に強い」の定義によるな。
同じ機能変更に対して
変更するコード量が少なくて済む、なら動的型付け言語だし
変更によるバグ混入の可能性を少なくする、なら静的型付け言語だな

0855デフォルトの名無しさん

2013/10/04(金) 14:38:36.99

JavaScriptが拡張に強いのは動的型付けだからでもLLだからでもじゃない
Webを背負ってるのと大きな勢力が幾つも関わってて慎重だからだよ

勿論最初はどのLLも皆シンプルでこの性質を持ってるけど
すぐに便利そうなものをどんどん追加して10年立たずに多くが破綻する

JavaScriptは言語の整合性を崩すような奇妙なものは入れてないし、これからもそう
これは紛いなりにも構文がJavaを参考にして生まれたお陰

反対にPerlを参考にした正規表現に限っては腐って非推奨の山になってる
そういうことだよ

0856デフォルトの名無しさん

2013/10/04(金) 16:03:44.49

その割にライブラリレベルのプラットフォーム互換性低すぎ。
あと構文がJavaを参考にしているとか意味不明。

0857デフォルトの名無しさん

2013/10/04(金) 16:17:40.76

jQuery等が出てきてDOMやXMLHttpRequestを叩く際のブラウザ間の差異を吸収して
くれるようになったので手軽にDHTMLやAJAXも扱えるようになったのであって、
それ以前のJavaScriptでのクロスブラウザ開発はまぁ酷い物だったと思う。

0858デフォルトの名無しさん

2013/10/04(金) 16:24:52.40

>>853
そもそものjavascriptの出自が10日で作った突貫工事で、とりあえずなんでもできるようにしといたことで色々やる術が有るとして、それと実際にプログラムする時の生産性は別だろよ(´・ω・｀)

おまいらjavascriptでどこまで大規模なやつつくってんの？プロトタイプ作るのには使ったけど訳わかめなバグくらいそうでこれをそのまま大規模に適用するのはためらわれるわ。

0859デフォルトの名無しさん

2013/10/04(金) 17:34:33.68

JavaScriptとかクソ言語だと思うが、
大規模にこだわるのはもっとクソだと思うぞ。

0860デフォルトの名無しさん

2013/10/04(金) 17:55:26.39

>>856
「a > b > c」と「a > b && b > c」が同義ではないという
スクリプト言語としてはかなり残念な性質を持ってるが
その辺り基本構文は全部Javaからの参考

あとライブラリの互換性も高い
DOMを使ったものでなければ転用は容易

>>857
それはJavaScript関係ない
DOMは皆のもので特定言語だけのせいじゃないし
IEのは暫くJScriptでJSとは違ってた
所謂ECMAScript自体に悪い点はない

0861デフォルトの名無しさん

2013/10/04(金) 17:59:42.12

>>858
大人数でやる大規模は現状大変かもしれないが
１人で作るものに限っては1000行、5000行書いてもそう困った事はない
デバッガが優秀になってくれたおかげがなによりまず一番だし、
言語仕様として事前(コンパイル前)エラーが出るようになったから
十二分ではないが七、八分くらいは満足できる

あと別に現時点で生産性が高いとは誰も言っていない
潜在開発生産性は高いということ
それはデバッガの進化もエンジンの進化も当然あるし、
ES.nextで大規模開発向けの仕組みが続々と入る

型に関しても色んな型やguardという仕組みがES7で入る
これは型を決めて宣言するのではなく、受け入れる型のタイプを選ぶ
まさに「ガード」を設置するというもので汎用性がかなり高い

現状活躍出来てるのはライブラリやWebAPIのお陰という声もあるが
それらは標準に取り入れられてきてる
最近だと型付配列、そういうものからもっとフレームワーク的なものまで
言語を支える仕組みとして導入が予定されている

とにかくJSはどんどん進化していけるんだから
可能性の高さは否定出来ない
というか、もしかすると一番それを示してくれていて、
これからも見せてくれる言語ではないのか

0862デフォルトの名無しさん

2013/10/04(金) 18:23:54.95

>>860
>「a > b > c」と「a > b && b > c」が同義ではないという
>スクリプト言語としてはかなり残念な性質を持ってるが
>その辺り基本構文は全部Javaからの参考

ここ、笑うところでしょうか？

0863デフォルトの名無しさん

2013/10/04(金) 18:31:59.73

>>860
>「a > b > c」と「a > b && b > c」が同義ではないという
>スクリプト言語としてはかなり残念な性質を持ってるが

JSはどうでもいいが、よく知られた言語の中で「a > b > c」と
「a > b && b > c」が同義なのはPythonだけじゃないのか？
a > b > c が型エラーにならないJSは残念な性質かもしれないが、
比較のためだけに意味不明な構文を設けているPythonも欠陥言語だろ

0864デフォルトの名無しさん

2013/10/04(金) 18:46:46.75

>>862
笑うところじゃないよ
実際にES.nextで議論されたけどJavaベースのJSでは無理だねってなったことだから

>>863
単変数ならまだいいけど
DOMやCSSのプロパティはやたら長い事があるから
それらを比較する時結局見栄えなんかのためにキャッシュすることが避けがたく
余計な行数と変数が増えて手間がかかるのは実際問題悲しい

0865デフォルトの名無しさん

2013/10/04(金) 19:55:55.03

笑うところだろ
a > b > cと書けるかどうかと
構文がJava風かどうかなんて
これっぽっちも関係ないw

0866デフォルトの名無しさん

2013/10/04(金) 20:12:59.72

>>865
そこは一例だよ
最近取り上げられたから出しただけ
証明としての例じゃなくて、それが与えた結果を説明する例だから
別に矛盾してないんだから成立している

0867デフォルトの名無しさん

2013/10/04(金) 20:23:19.63

そうかー、JavaScriptがJava風ってんなら、
きっと最近のJavaではオブジェクトリテラルを書けるんだなw
きっと最近のJavaScriptはclassとかextendsとかimplementsとかするんだなw
publicとかprotectedとかprivateとかアクセス修飾子つけるんだなw

そもそも「;」に関する構文規則すら違うというのにww

あほじゃなかろうかw

0868デフォルトの名無しさん

2013/10/04(金) 20:46:56.94

classは入るぞ爺さん

0869デフォルトの名無しさん

2013/10/04(金) 20:49:18.51

>>861
その可能性ってのは現在が足りないものゆえやれることがあるってのと同義ではないの？

逆にある程度成熟してしまったが故に進化がほとんどない言語というものもあるかもだけど。

javascriptだけがいつまでも可能性を秘めたまま進化していける理由があるなら教えてくれたまい。

0870デフォルトの名無しさん

2013/10/04(金) 20:58:37.52

ES7がブラウザで広く使えるようになるのって何時よ。
個人的にはJava10と良い勝負だと思う。

0871デフォルトの名無しさん

2013/10/04(金) 21:41:21.07

>>867
JavaScriptでは昔から
class、extends、implements、public、protected、private
は予約語
class、extends←ES6
private←近いうちに入る
public、protected←検討中

0872デフォルトの名無しさん

2013/10/04(金) 21:48:58.80

>>869
理由は散々書いたし、別に無限とは言っていない
ただ数年で変わる言語と比較したら、ざっと５倍ほどの柔軟性はあるし
こんなにも広い範囲で活躍できる言語であることは事実

>>870
別にブラウザで広く使える必要なんてない
Node.jsやFirefoxOS、各種ブラウザアプリなんてのもあるんだから
それにJava10と大きく違うのは、
全て後方互換性を崩さない変更だから
どれでも形になったものから少しづつ追加できること

今も各ブラウザはそれぞれ１０％～５０％くらいES6に対応してる
お決まりの言葉で言うとLivingStanderd
そういう目で見るとES7が来るのは遅くても2015年中から

0873デフォルトの名無しさん

2013/10/04(金) 22:37:22.38

ブラウザにスクリプトが載ってることには意義があるがJavascriptは嫌い
emscriptenでてからC++から変換できるようになって直接書かなくなった

0874デフォルトの名無しさん

2013/10/04(金) 22:40:43.94

あー、まー誰にでも好き嫌いはあるよね。
そんだけのこと。

0875デフォルトの名無しさん

2013/10/04(金) 23:45:42.46

いやあんなので大規模なコードかけない

0876デフォルトの名無しさん

2013/10/05(土) 01:12:18.50

書き方を知らないだけ。
動的型付け言語には動的型付け言語らしい書き方がある。
アプローチの仕方とも言っていい。

0877デフォルトの名無しさん

2013/10/05(土) 02:03:15.14

大きなJavascriptのオープンソースプロジェクトってなんかある？

0878デフォルトの名無しさん

2013/10/05(土) 02:06:30.72

旬なのだとshumwayとか？
この前Firefoxに入ったよね

0879デフォルトの名無しさん

2013/10/05(土) 02:23:14.43

大きいプロジェクトでJavaScriptが
使われている例ならたくさんあるんだけどね。

0880デフォルトの名無しさん

2013/10/05(土) 02:39:07.71

Node.jsとかもJSの塊やぞ

0881デフォルトの名無しさん

2013/10/05(土) 04:33:46.99

いやそれ処理系やん・・・

0882デフォルトの名無しさん

2013/10/05(土) 05:10:49.06

JavaScriptに関しては普通にブラウザ向けの開発で使わざるを得ないのだがいつになったら
このウンコな変数スコープとのおつきあいを止められるのか。

0883デフォルトの名無しさん

2013/10/05(土) 07:38:43.16

たかが変数のスコープごときで何言ってんだから。

だからおまえは、知らないんだって
ばれるんだよ。

0884デフォルトの名無しさん

2013/10/05(土) 07:41:09.34

>>872
広い範囲でって、そのほとんどがブラウザーがjavascriptエンジンを乗っけてることに起因するんじゃないの？

ブラウザーの乗っけてるのがjavascriptエンジンじゃなく仮想マシン処理系でその上で使える言語は何でもいいとなったらjavascriptは選択されないと思うけどね。

まぁ家庭の話をしてもしょうがないのでjavascriptの柔軟性の源泉について>>841からの流れにあるの？

0885デフォルトの名無しさん

2013/10/05(土) 07:46:51.42

>>884
nodeの存在が、それが間違いであることを証明した。

0886デフォルトの名無しさん

2013/10/05(土) 08:27:06.78

node.jsはクライアント側がjsだからというだけの理由で話題になっただけで
マトモな実用にはなっていないだろw

0887デフォルトの名無しさん

2013/10/05(土) 09:46:55.14

>>885
いや、それも処理系の場所が増えたってだけで言語としての特性は関係ないんじゃないの？
nodeの利点はクライアントと同じ言語でサーバーサイドもかけるよってのが主じゃない？

0888デフォルトの名無しさん

2013/10/05(土) 09:58:49.07

>>887
それを言ったら他の言語だってそうだろ。

でもひとつ言えるのは、言語がだめなら
サーバーサイドで使われることはないということ

全ての言語は、積極的な良い理由があって使われるんじゃない。
実用レベルの言語であり、言語の特性以外の何かしらの
理由があって普及したものが、使われるんだ。

0889デフォルトの名無しさん

2013/10/05(土) 10:26:22.07

>>887
>それを言ったら他の言語だってそうだろ。
いや違うだろ。
PHPなんてクライアントで使ってるの見たこと無いが。

0890デフォルトの名無しさん

2013/10/05(土) 10:30:08.44

>>888
>でもひとつ言えるのは、言語がだめなら
>サーバーサイドで使われることはないということ

おまえ、それ Perl さんの前で言ってみろ！w

0891デフォルトの名無しさん

2013/10/05(土) 10:41:50.71

Nodeのパフォーマンスがいいだけで、言語そのものは駄目だろ。

0892デフォルトの名無しさん

2013/10/05(土) 11:18:33.84

フォールトトレランスを考慮にいれたら
Nodeなんて選択肢にも上がらんゴミ

0893デフォルトの名無しさん

2013/10/05(土) 11:47:53.21

>>883
＞たかが変数のスコープごときで何言ってんだから。

たかがも何も、とても重要でいわゆるオブジェクト指向プログラミング言語だと
必須なんだけどな。カプセル化とか知らんのかね？ COBOLが嫌われるのは
全部グローバル変数なところだし。スパゲッティなコードを書きたく無ければ
変数のスコープがきっちり決まってる方がいいんですよ。

0894デフォルトの名無しさん

2013/10/05(土) 11:57:56.18

Javaもpublicなstatic変数使えるしC/C++はグローバル変数がある
そこをJavascriptだけ指摘するのはおかしいな。

newとfunction駆使すればクラス相当の書き方可能だし。

プロトタイプベースが基本なのがわかりにくいんだと思う。

0895デフォルトの名無しさん

2013/10/05(土) 12:02:41.92

>>894
いや、デフォルトがグローバルとか、
こんなんで実用する気になるほうがおかしい。

0896デフォルトの名無しさん

2013/10/05(土) 12:12:08.59

use strictつけるだけのものをそんなに気にするのがおかしい

0897デフォルトの名無しさん

2013/10/05(土) 12:26:26.97

そんなクソ宣言が必要であることが気にならないのがおかしい

0898デフォルトの名無しさん

2013/10/05(土) 12:30:28.34

C/C++でもワーニングレベル調整しなきゃざるだし
LLがそういうデフォルトになってるのにケチつけるのはおかしい

0899デフォルトの名無しさん

2013/10/05(土) 12:35:17.91

気軽さが身上のLLなのにそんなボイラープレートが必要な時点でダメ言語だろ

0900デフォルトの名無しさん

2013/10/05(土) 12:45:29.16

LL基本だからvarつけなくても動作する。
チェックをしたい場合はuse strictをつける。

まさに仕様なんで
これが気に食わないってことならあまり相手にされないと思うよ。

0901デフォルトの名無しさん

2013/10/05(土) 12:47:52.89

varを付けたときと付けないときの挙動が
逆なら良かったね

0902デフォルトの名無しさん

2013/10/05(土) 12:51:33.91

まさに仕様なんで気に食わないってことならあまり相手にされないと思うよ。

0903デフォルトの名無しさん

2013/10/05(土) 12:59:42.54

結論は>>901だな。undefinedに代入ができたり。実にダメな言語だ。

0904デフォルトの名無しさん

2013/10/05(土) 13:09:48.04

まさに仕様なんで気に食わないってことならあまり相手にされないと思うよ。

0905デフォルトの名無しさん

2013/10/05(土) 13:18:09.26

仕様がうんこ
仕様だからで思考停止する奴もうんこ

0906デフォルトの名無しさん

2013/10/05(土) 13:22:43.02

別にJavascriptがいいなどとは言ってない。
>>893は的外れだから相手にされていないと言っている。

0907デフォルトの名無しさん

2013/10/05(土) 13:36:35.21

クソプログラマはスコープなんて気にしないってこと？

0908デフォルトの名無しさん

2013/10/05(土) 13:46:54.64

後付けされたstrictモードの存在自体がJavaScriptの"varつけ忘れでいきなりグローバル"
という元々の振る舞いは失敗でしたウンコでしたと認めたようなものでしょ。

仕様だから我慢すれというのであれば別にES6でlet導入する必要も無いんでない?
こんなのが導入されるのもまともなブロックスコープすら無いと方々でブーブー文句言った
からでしょ。現状のJSの関数スコープが素敵だなんて話殆ど聞いたことが無い。
いまさらごく当たり前のブロックスコープを導入したところでIE10とそれ以前が無視できる
レベルまで置き換えが進まない限りブラウザ向けの開発では使えないんだれどもな。

class等にしてもそう。クラス的なことをするのに現状どれだけ異なる書き方の流儀がある
ことやら。import的な仕組みもライブラリごとに手作りしていたりとか。ES6でこの辺りに
仕様の追加が入るのもそういう現状はよろしくないよねという合意があるからでは?

あとは型注釈かな。きっちり型注釈が入ったライブラリで開発できるFlex+AS3は現状でも
なかなか優れたGUI開発系だし、HaxeはもちろんTypeScriptやDartなどJavaScript+型注釈
的な後発言語も多いのもそのメリットは無視できないからだと思う。
ただこれもブラウザ上のJSが対応するにしても広く普及するのはずっと未来だろうな。

0909デフォルトの名無しさん

2013/10/05(土) 13:48:49.51

github、RubyとMVCの限界を悟りC#とMVVMに全面移行　／　オープンソース界に激震
http://engawa.2ch.net/test/read.cgi/poverty/1380941226/

0910デフォルトの名無しさん

2013/10/05(土) 13:57:38.08

的外れが図星でワロタ

0911デフォルトの名無しさん

2013/10/05(土) 14:03:45.31

的を射ててワロタ

0912デフォルトの名無しさん

2013/10/05(土) 15:37:23.33

>>888
だからそういった動く環境が多いとか言った話を除いて、この言語は可能性無限だぜひゃっはー！って言ってる言語上の特性ってなによって話をしてんだが。

なのにいろんなとこで動くからとかnodeがーとか言うから話がそれる(´・ω・｀)

0913デフォルトの名無しさん

2013/10/05(土) 16:31:03.74

だから言語上の特性が理由じゃなくて、
色んな所で動くから可能性無限大なんだろ。

0914デフォルトの名無しさん

2013/10/05(土) 16:38:55.13

>>888
>でもひとつ言えるのは、言語がだめなら
>サーバーサイドで使われることはないということ

ダウト。どんなクソ言語でもサーバで使うヤツは必ず現れる。

正しくは「JavaScriptでさえ、サーバサイドで使われた。」

0915デフォルトの名無しさん

2013/10/05(土) 16:40:35.26

色んな所で動く＋大企業のサポートが強大って所かな。

いかに言語が優れていたとしても、
それ以外の部分ができてないとダメなんだよ。

そしてそれ以外の部分を強化するのってすごく難しんだよね。
努力だけではなく運やコネなんかも必要。

その点、JavaScriptは言語以外の部分が極めてすごい。
そのため、急速に言語の問題点も改善されていっている。

ほら、可能性無限大でしょ？

0916デフォルトの名無しさん

2013/10/05(土) 16:41:29.27

JavaScriptをサーバーで動かすってのも
言語的にはもともとダメだった。

だけど、言語以外の部分が強力だから
ほら、大幅に改善された。

0917デフォルトの名無しさん

2013/10/05(土) 16:43:41.10

つまり言語自体はクソだと認めた訳だなw
JavaScriptがいまだに使われているのは大企業のゴリ押しのおかげ。

0918デフォルトの名無しさん

2013/10/05(土) 16:45:34.24

馬鹿だなぁ。
クソなんて一言も言ってないじゃん。
反論の前に、お前の推論能力を疑うわｗ

反論ほしいのか？簡単。クソの理由が無いか、
重箱の隅をつつくようなものしか無い。
以上。

0919デフォルトの名無しさん

2013/10/05(土) 16:46:39.59

必要な機能がなければクソだが
すごい機能がなければ、クソってことにはならないんだよね。

そこんところよく勘違いしている人がいる。

0920917

2013/10/05(土) 16:49:50.71

>>918
企業サポートが強い＝言語はクソ

極めて論理的で科学的な推論です！
成績は５です！

0921917

2013/10/05(土) 16:52:03.65

>>920
ナリスマシしてまでJavaScriptを傑作言語にでっち上げたいのかw
おまえ、人間として最低のカスだよ。

0922デフォルトの名無しさん

2013/10/05(土) 17:00:05.91

最低だな

0923デフォルトの名無しさん

2013/10/05(土) 17:03:04.01

いや、優秀なIDEだとおかしな構文を勝手に修正してくれるじゃないか

0924デフォルトの名無しさん

2013/10/05(土) 17:32:40.66

改善されるも何も、その改善された仕様だけでやってけるのは何時になるのでしょうか？

0925デフォルトの名無しさん

2013/10/05(土) 17:38:54.20

>>921
なりすましなのか？

どうでもいいけど、じゃあなんで
お前は企業サポートが強いといったら、
言語がクソだと認めた訳だなって言ったんだ？
これならなりすまししてる人と同じ事言ってるじゃん。

さあ説明を求む。

0926デフォルトの名無しさん

2013/10/05(土) 17:42:15.31

>>924
ロボットがプログラムを書いてくれないのなら
人間が書いても同じなんですよね。
仕事が減りません。どうすれば・・・。

0927デフォルトの名無しさん

2013/10/05(土) 18:01:50.74

言語仕様への問題指摘に対して何の反論もできていない挙げ句の
> いかに言語が優れていたとしても、
> それ以外の部分ができてないとダメなんだよ。
だからなあ

マトモな対人コミュニケーション能力を持っていれば結論は見えてるよな

ところでナリスマシしといて逆ギレってのは、本当にみっともないぞ

0928デフォルトの名無しさん

2013/10/05(土) 18:03:55.57

JavaScriptだって悪い所はあるさ
それに
メリットとデメリットなんて表裏一体
それを静的言語系の人は大抵デメリットと感じるのは当然の当然

デフォルトでグローバル変数になるのだって
プロトタイプベースなのだって
スコープチェーンとプロトタイプチェーンという
真に自由なオブジェクト指向プログラミング言語なんだからだよね

http://www.slideshare.net/yuka2py/javascript-23768378

0929925

2013/10/05(土) 18:08:19.96

やっぱ説明できなくて逃げたねｗ

0930デフォルトの名無しさん

2013/10/05(土) 18:17:42.48

良い悪いなんて人の好みだと思うが、公平に速度の観点から見ると
JSは悪い言語設計とは言えないと思うな

0931デフォルトの名無しさん

2013/10/05(土) 18:19:53.17

だからJSは普通にいいんだってｗ

0932デフォルトの名無しさん

2013/10/05(土) 18:27:49.36

全く…JSは最高だぜ！！

0933デフォルトの名無しさん

2013/10/05(土) 18:27:51.68

>>929はどこまでゴミ人間なんだろうねwww
逃げて、なりすまして、また逃げて、ついに逆ギレして、呆れられて、勝利宣言w

面白いから晒しとくw

0934925

2013/10/05(土) 18:34:05.56

なりすましじゃないんだけど？

どうでもいいけど、じゃあなんで
お前は企業サポートが強いといったら、
言語がクソだと認めた訳だなって言ったんだ？
これならなりすまししてる人と同じ事言ってるじゃん。

さあ説明を求む。

0935デフォルトの名無しさん

2013/10/05(土) 18:51:02.56

>>934
言語のクソな部分の具体的な問題点の指摘に何の反論もできずに逃げた事

胸に手を当てて考えてみろwゴミ人間くんw

0936デフォルトの名無しさん

2013/10/05(土) 18:52:14.29

>>925
>さあ説明を求む。

自分がなりすました理由を説明したら？

「恥を知れ」って、よく言われない？

0937デフォルトの名無しさん

2013/10/05(土) 18:58:02.62

1か0か病はプログラマや理系人間の悪い癖
さらにたちが悪いのは
1を信仰するものはたとえ0.99であっても1じゃないとケチを付け
0を信仰するものはたとえ0.01であっても0じゃないとケチを付けること
お互い歩み寄ろうとしない

0938925

2013/10/05(土) 18:58:32.91

なんか必死だね。
なりすましは俺してないし、
誰かと勘違いしてるんじゃないか？
まったく思い込みで何一人で熱くなってるんだかｗ

918 名前：デフォルトの名無しさん[sage] 投稿日：2013/10/05(土) 16:45:34.24
馬鹿だなぁ。
クソなんて一言も言ってないじゃん。
反論の前に、お前の推論能力を疑うわｗ

反論ほしいのか？簡単。クソの理由が無いか、
重箱の隅をつつくようなものしか無い。
以上。

0939デフォルトの名無しさん

2013/10/05(土) 18:58:54.59

920が排泄物なのは確定だな。

0940デフォルトの名無しさん

2013/10/05(土) 18:59:44.75

JavaScriptは良い言語だし、
企業のサポートも多いから
今でも普及しているが
これからさらに普及するということでしょ。

0941デフォルトの名無しさん

2013/10/05(土) 19:00:01.68

>>938
それがなりすましの言い訳か。呆れたね。最低だね。ゴミだね。

0942デフォルトの名無しさん

2013/10/05(土) 19:01:14.87

>>941
なんでそんなに必死なの？
親でも殺された？

0943デフォルトの名無しさん

2013/10/05(土) 19:02:11.80

これはなりすましって言ってる奴が
なりすましの犯人というオチだなｗ

0944デフォルトの名無しさん

2013/10/05(土) 19:31:26.45

JS厨バカすぎw

0945デフォルトの名無しさん

2013/10/05(土) 20:04:41.49

プロトタイプベースは面白いと思うけど、
デフォルトでグローバルは擁護できんな
どう考えても、ローカル変数の方がよく使うんだから

0946デフォルトの名無しさん

2013/10/05(土) 20:07:13.77

は？
じゃあ上のスコープの変数使う時はどうすんのよ
グローバルっていうのは一番上のスコープってことだぞ

0947デフォルトの名無しさん

2013/10/05(土) 20:09:02.46

問題はグローバルに新しく変数ができることだけで
アクセスできるのがデフォルトなのは何もおかしくない
まあstrict modeにすればいいだけのことだが

0948デフォルトの名無しさん

2013/10/05(土) 20:13:19.05

一貫性を保つためでしょ
プロトタイプチェーンと同じでシンプルにっていう思想
x = nonlocal
と
x = global.nonlocal
が同じになるのが普通なら

nonlocal = x
と
global.nonlocal = x
が同じになるのが自然って感じな

0949デフォルトの名無しさん

2013/10/05(土) 20:14:08.87

javascriptでthisとスコープで間違いを犯したことがないものだけ静的に石を投げなさい(´・ω・｀)

0950デフォルトの名無しさん

2013/10/05(土) 20:19:50.01

プログラミング言語の文法で悩んだことにない人だけが、文句を言いなさい。

0951デフォルトの名無しさん

2013/10/05(土) 20:20:22.54

静的を批判するレスなんてないんだが？

0952デフォルトの名無しさん

2013/10/05(土) 20:20:58.41

>>949
被害妄想乙

0953デフォルトの名無しさん

2013/10/05(土) 20:25:07.74

例のJS大嫌いなキチガイが来てるんでしょ？

0954デフォルトの名無しさん

2013/10/05(土) 20:31:42.81

批判する意見が全て同一人物によるものだと思い始めたら危険
視野の狭い低能にありがちだけど

0955デフォルトの名無しさん

2013/10/05(土) 20:34:41.25

全員アイツのなりすましだ！

0956デフォルトの名無しさん

2013/10/05(土) 20:53:24.37

結局>>901でFAでしょ？
use strict とか関係なくて

0957デフォルトの名無しさん

2013/10/05(土) 20:57:06.04

そんなことはないな
クロージャとか深いスコープネスト多用するんだから

0958デフォルトの名無しさん

2013/10/05(土) 21:01:49.41

参照するだけなら関係無いし、
そんな簡単に変数を上書きしねーよ
副作用脳のサルかよ

0959デフォルトの名無しさん

2013/10/05(土) 21:02:43.27

>>949
thisのどんなところが間違えやすいのよ？

0960デフォルトの名無しさん

2013/10/05(土) 21:07:51.69

変数がヒットせずにスコープチェーンをどんどん遡っていったときに
最終的にグローバルに新しく出来てしまう事が問題なわけで
べつにvarが逆でも問題は解決しない
新しくできるのを防ぐのが大事でそれがstrictmode

0961デフォルトの名無しさん

2013/10/05(土) 21:09:47.04

ブロックスコープが無いことも叩いて。
実質的な御利益が何もない。

0962デフォルトの名無しさん

2013/10/05(土) 21:10:24.32

>>960
そんな程度の問題。
昔からjshintあたりで
検出できてたよな。

0963デフォルトの名無しさん

2013/10/05(土) 21:11:13.54

>>961
ブロックスコープなくても
クロージャースコープが有るじゃん。
これがブロックスコープの代わりになるし、

えー、そもそもブロックスコープが必要になるような
長い関数書かなければいいんじゃね？

0964デフォルトの名無しさん

2013/10/05(土) 21:13:58.01

>>961,963
意味不
JSにブロックスコープはできただろうが

0965デフォルトの名無しさん

2013/10/05(土) 21:17:20.24

ブロックスコープはletがあるし、thisバインドのアロー関数もある。
無知ばかり。

0966デフォルトの名無しさん

2013/10/05(土) 21:19:44.79

ES6でね

0967デフォルトの名無しさん

2013/10/05(土) 21:21:11.79

letは全ての最新ブラウザで使える（IEは11）

0968デフォルトの名無しさん

2013/10/05(土) 21:27:11.46

>>960
わざわざvarを付けないと、そんなウンコな振舞いになるのが問題

0969デフォルトの名無しさん

2013/10/05(土) 21:29:41.51

>>968
つstrict mode

0970デフォルトの名無しさん

2013/10/05(土) 21:36:10.55

var付ける付かないの問題じゃねえって何度言ったら分かるんかな
C言語しか書いたことのない人か？？

0971デフォルトの名無しさん

2013/10/05(土) 21:36:37.86

varを付けないのが禁止になるだけじゃん

別にvarくらいどうってことないよ？
でも良く使うもの程より短い記述で書けるべきだろ
つまりJS作った奴はアホ

0972デフォルトの名無しさん

2013/10/05(土) 21:38:53.95

>>970
わかってないお前に一言で説明してやるよ。

varの問題はとっくに解決済み。
お前の言う問題は、全て解決している。

0973デフォルトの名無しさん

2013/10/05(土) 21:40:27.56

>>971
よく使うもの？

そうだな。

functionとreturnの文字が
1ファイルにつき、1000個ぐらいあるとか
そういう話？

それは書いた奴が悪いよｗ

0974デフォルトの名無しさん

2013/10/05(土) 21:42:57.36

ん？
もしかしてローカル変数への代入にはvarがいるとか勘違いしてる？
宣言無しで変数を使った場合は上のスコープにない場合最終的にグローバル変数になるってだけで

問題っていうのは「「宣言を忘れて代入しちゃったとき」」なんだが
忘れてるものを付けるだけだから別に手間が増えるとか無いぞ？

それとも宣言なしに勝手にローカル変数にしろってか？
それはほかのスコープチェーンを辿る挙動と合わなくておかしいだろう

0975デフォルトの名無しさん

2013/10/05(土) 21:49:14.63

何がおかしいの？

0976デフォルトの名無しさん

2013/10/05(土) 21:51:29.58

宣言なしに勝手にローカル変数になるってことは
上スコープの変数の参照、代入に全てvarか何かを付けないといけなくなって
かなり大変なことになるじゃん
それくらい考えてよ

0977デフォルトの名無しさん

2013/10/05(土) 21:54:37.06

代入にはいるけど参照には不要だろ

0978デフォルトの名無しさん

2013/10/05(土) 21:55:59.44

たかだかブロックスコープを使うためにクロージャ書いたりとかIE10以前が絶滅するのを待つとか、
無駄じゃん。

varの書き忘れを書き損じとして扱うのに毎度use strictとか書くの、無駄じゃん。

普通にこの辺りは初期の言語仕様の失敗だと思うけど。

0979デフォルトの名無しさん

2013/10/05(土) 21:59:32.21

use strictはテスト時のみつければいいので
対応ブラウザとか関係ない
lintみたいなもの
使ったことない奴がほざくな

0980デフォルトの名無しさん

2013/10/05(土) 22:00:49.09

"use strict"
の12文字を書くのがそんなに嫌なのか
それなのに冗長な静的型を好む
矛盾

0981デフォルトの名無しさん

2013/10/05(土) 22:08:08.44

>>976
関数スコープを飛び越えて再代入する時は
何らかの宣言があった方が好ましいよ
再代入は参照に比べると危険な操作だし

0982デフォルトの名無しさん

2013/10/05(土) 22:10:01.15

静的言語ならそうかもしれないが、スクリプト言語だからね

0983デフォルトの名無しさん

2013/10/05(土) 22:10:39.77

>>979
テストしたソースを書き直すのはテストの意味ないんだけど？

0984デフォルトの名無しさん

2013/10/05(土) 22:15:33.61

別に書きなおす必要はないぞ？？
非対応ブラウザでは文字列になるだけだから

0985デフォルトの名無しさん

2013/10/05(土) 22:16:26.77

静的型付けの型推論はどうなのよ

0986デフォルトの名無しさん

2013/10/05(土) 22:18:38.20

>>983
>>979はテストのときのみと書いてるけれど、対応していない処理系は
"use strict";
を無視するから大丈夫。

0987デフォルトの名無しさん

2013/10/05(土) 22:22:58.12

"use strict"は開発のサポートのため
もっと言えばグローバル変数以外にも
オブジェクトキーの重複とか、色んな"Early Error"を出すためのものだから
開発が終ればstrict modeだろうがそうで無かろうが大して問題じゃない
最後は「動かないより動いた方がいい」しね

0988デフォルトの名無しさん

2013/10/05(土) 22:24:07.89

型注釈によるオプショナルな型付け+型推論がベストかと。
いずれも持たないJavaScriptはプリミティブ過ぎる。

0989デフォルトの名無しさん

2013/10/05(土) 22:30:08.31

JavaScriptでは型は「揃える」もの。
seisu = hoge|0 とか。
DOMを扱うJavaScriptでは型変換がしょっちゅう要るからそこは暗黙的な方が便利。
まあそうは言ってもES7でguardが入るんだけどね。

0990デフォルトの名無しさん

2013/10/05(土) 22:30:51.47

>>982
スクリプト言語だから、何なの？

0991デフォルトの名無しさん

2013/10/05(土) 22:33:14.82

型推論は後付けするのは難しい
TypeScriptのゴミ推論を見れば分かる

0992デフォルトの名無しさん

2013/10/05(土) 22:33:17.18

気軽な方がいいってことじゃない？

0993デフォルトの名無しさん

2013/10/05(土) 22:35:03.23

コールバック地獄＝クロージャ地獄のJSに>>901の仕様は合わない。

0994デフォルトの名無しさん

2013/10/05(土) 22:49:52.08

http://wiki.ecmascript.org/doku.php?id=strawman:trademarks
http://wiki.ecmascript.org/doku.php?id=strawman:guards

0995デフォルトの名無しさん

2013/10/05(土) 23:29:10.45

クロージャーっって知ってる？

この機能の重要な点の一つとして
関数上のスコープの変数を読み書きできないといけない
というものがあるんだが、知ってるかな？

varのつけ忘れで上のスコープの変数参照できるからって何？
クロージャーってのはそれが出来ないといけないんだよ。

上に登っていった結果、グローバル変数になったら問題だけど
それは"use strict"で防げるから、今は起こりえない問題。
古いブラウザ用であってもjshintなどで検出もできるし。

0996デフォルトの名無しさん

2013/10/05(土) 23:51:00.85

同じ話を何回するんだよｗｗ

0997デフォルトの名無しさん

2013/10/06(日) 00:16:40.24

別にクロージャ実現するのにJavaScriptのウンコな関数スコープである必然性も必要性も
無いし、外のスコープの変数を参照できるのはJavaScriptに限らず多くの言語が持つ機能
だし、他方で参照解決できなかったらいきなり大域変数作るなんてメリット何も無いし。

この辺り失敗だった事は後付use strictとletで明らか。
JavaScriptだって欠陥混じりの言語としてスタートして改良を必要としながら変化して
きたことは他の言語と全く変わらん。

仕事でもJavaScriptはそれなりに書くけどうわぁここは型をつけてIDEに仕事させたい
とか成果物ごとにモジュール化の書き方が異なって気持ちが悪いとかクロージャ書く度に
functionfuncitonfunctionfunctionfunction文字数多いよとかクロージャ以前に文字列の
式展開とかヒアドキュメントとか無いの面倒でしょHTML弄るときは特にとか不満は他言語
と同程度に普通に感じるかな。
だから改善にも期待するし、他方で合意形成やブラウザ対応の遅さにもげんなりする。

0998デフォルトの名無しさん

2013/10/06(日) 00:25:52.84

>>997
名に話をごっちゃにしてるんだよｗ

クロージャーと関数スコープの話は別だろ。
クロージャーと関係があるのはvarで
変数宣言しなかった場合どうなるかの話だ。

0999デフォルトの名無しさん

2013/10/06(日) 00:26:16.39

失敗だったものなんてないよ
最悪と言われるwith文だってブラウザでのコンソールシステムとかで活かされてるし
何をどう使うかの話
functionが長いとかもうねｗ笑わせんな
一応後方互換性は保ちながら進化してるんだから失敗じゃない
そりゃあ新しいバージョンの規格のほうが良いけど
だからといって古いものが何もかも失敗になるわけじゃない
JSに大規模開発サポートが増えてきたのも、使われ方、要求されるものがかわって来たってだけ

1000デフォルトの名無しさん

2013/10/06(日) 00:26:58.91

>>997
どの言語にも「失敗が一つもなかった」といえる言語はないよ。
Rubyとか互換性切り離してまで、
失敗した原因をなくそうと頑張ったじゃん。

JavaScriptも同じ。

1001１００１

Over 1000Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

レス数が1000を超えています。これ以上書き込みはできません。