現世代Javaの動向 1 - 暇つぶし2ch

現世代Javaの動向 1 ..

49:デフォルトの名無しさん
06/09/02 01:37:17
便利だと思いますけどね、typedef
もし、
HashMap<String, LinkedHashMap<String, List<String>>>
なんてあると悲惨だし。

50:デフォルトの名無しさん
06/09/02 02:13:00
>>48
もっと大事な問題がある。

>>47
ストラウストラップが警告していたことだ。
その弊害は複数人で開発するときに起きる。
各々がtypedef宣言した型の定義が異なると
名前を書き直す手間が生まれ、面倒な自体に陥る。

typedefを導入するなら、typedefで定義した型が
重複してエラーにならないように名前空間も同時にtypedefに導入すべきだろう、
と思ったが、やっぱりそれでも混乱の元。

あらかじめチーム内でルールを決めていればいいが、
他社が作ったtypedef定義を使うときに自社で定義した型名が重複することがあり
面倒な事態が起きる。これが２社程度ならどうにかなる可能性があっても、
三社、四社となると非常にとんでもない苦労を強いられる。

>>49
その程度でtypedefを導入するなら、新たにラッパークラスで宣言した方がいい。

51:デフォルトの名無しさん
06/09/02 02:50:42
ふーん、そうなのか。
で、今ではそのtypedefの難題をどうやって解決したの？

52:デフォルトの名無しさん
06/09/02 10:05:54
>>50
クラス内のみで有効、つまりprivateなtypedefのみなら混乱は起きないんじゃ？
ラッパークラスは大げさすぎるし、たしかIBMの記事でtypedefの変わりに
ラッパー使うな、ってのがあったはず。
あぁ、これかも
URLﾘﾝｸ(www-06.ibm.com)

53:デフォルトの名無しさん
06/09/03 01:02:37
あげ

54:デフォルトの名無しさん
06/09/03 01:50:28
JAVAはバージョン違いで動かないし要らない。

55:デフォルトの名無しさん
06/09/03 10:43:23
>>50
それって、別にtypedefに限った話ではなく、名前がつくものはなんでも当てはまるよね。
クラス名だって十分重複する可能性がある。
それにJavaにはpackageがあるんだから、typedefによる名前の重複はほとんど起きないと思うよ。

typedefは、>>49が書いたように、Genericsによって複雑になった型を簡略化できる利点がある。
おれは>>50が主張する欠点はtypedefに限った話じゃないと思うから、それよりは>>49の利点のほうに一票。

56:デフォルトの名無しさん
06/09/03 11:41:03
>>55
typedefを使う型にpackageを使うのか。
実際にどうやって宣言するのかここに書いてくれないか？
副作用が見えてくるぞ。

57:デフォルトの名無しさん
06/09/03 11:41:58
>>54
それは他の言語でも同様。
Javaではそういった事態に困る確率は
他のどの言語よりも低い。

58:デフォルトの名無しさん
06/09/03 12:12:30
>>50
C++とJavaの違いをもっと良く勉強してください。

59:デフォルトの名無しさん
06/09/03 13:16:29
package jp.example;

// importは省略

public typedef Map<String, List<String>> HeaderMap; // ;はいらないかな？

public class Hoge {
　　HeaderMap getHeaders() { ... }
}

60:デフォルトの名無しさん
06/09/03 13:18:26
getHeadersにpublic付け忘れた・・・orz
で、なにか問題になるか？HeaderMapクラスがあったら、とかは却下な。

61:デフォルトの名無しさん
06/09/03 13:22:07
package jp.example;

// importは省略

public class Hoge {
　　public typedef Map<String, List<String>> HeaderMap;
　　public HeaderMap getHeaders() { ... }
}

こうかも

62:sage
06/09/03 14:13:17
>>61
読みやすさより書きやすさを優先してるように見える
一般にコードは書かれた回数より読まれる回数が多いはず
タイプ量を短くするためだけに新たな型名を定義するようなものは既存のJavaにはない気がするし
Hogeの使い方を知るためにHeaderMapの定義を見ないといけないのはつらい
Fuga.setHeaders(Hoge.HeaderMap m)とか伝染するとさらにつらい
Fuga.setAnotherHeaders(Map<String,List<String>> m)があったりして記述が一貫しなくなるのもつらい

63:デフォルトの名無しさん
06/09/03 14:15:58
>>58
お前が勉強しろよ

64:デフォルトの名無しさん
06/09/03 14:17:38
>>59
そのHeaderMapを外部から使うときは
import宣言でやるってことか。

よさそうに見えるが・・・

何か落とし穴があるような気がしてならない。

65:デフォルトの名無しさん
06/09/03 14:22:52
>>62の言う落とし穴も揚げられる。

ほかに揚げられるのは、
演算子オーバーローディング問題と
同じかな。

66:あげあげ
06/09/03 15:57:34
なら>>52の案はどうよ？
引数や戻り値には感染しないように禁止しておいて、内部で使うだけ。
結構な妥協案だけど、これなら問題ないんでね？

67:デフォルトの名無しさん
06/09/03 17:05:43
>>66
staticのやつ？

68:デフォルトの名無しさん
06/09/03 17:32:48
>>67
なんだそれ？
いや、typedefはクラス内でしか有効じゃなくて、クラス外には見せないようにする。

public class Hoge {
　typedef Map<String, List<String>> HeaderMap; // これはprivate
　// このメソッドはエラー
　public HeaderMap func1() { ... }
　// このメソッドはOK
　private HeaderMap func2() { ... }
　// これもOK
　public void func3() {
　　HeaderMap map = func2();
　　...
　}
}

69:デフォルトの名無しさん
06/09/03 21:00:02
>>68
それならpackage privateでもいいかもしれないね。

70:デフォルトの名無しさん
06/09/03 22:43:09
ときに、全ての言語はlispに向かう、って真なのかねぇ
クロージャなんて普及しないと思うんだが喜んでる奴いる？

71:デフォルトの名無しさん
06/09/03 23:20:32
>>70
> ときに、全ての言語はlispに向かう、って真なのかねぇ
たぶん偽だろうね。ああいう言説ってLisp厨の戯言にしか聞こえない
レキシカルスコープやクロージャ、GCなどをLisp系言語が最初に取り入れたのは
事実だろうけど、だからといってそれらの特徴がLispの専売特許のように言われても困る

ただ、クロージャ自体はいろいろと便利で使い道も多いので、あった方が良いと思う
例えば、クロージャのある言語だと、スコープを抜けたらファイルのクローズ処理を
自動的にやってくれるライブラリが作れて便利だけど、現在のJavaだとそういうのがしづらい
(無名クラスを使えばできなくは無いが記述が冗長)ので、finallyで明示的にクローズしなくちゃ
ならなくてめんどいとか

72:デフォルトの名無しさん
06/09/04 07:29:47
クロージャがあると汎関数作るのが簡単になるから欲しい。
利用する側にとっても便利。いちいち無名クラスというのも…

>>71
後、汎関数もLispが先駆者で、Javaはこっちの方面は拒んで、
クラスに属するメソッド主義だったけど、クロージャを導入すると、
クラスから独立した汎関数の世界にちょっと足を踏み込んだことになる。

73:デフォルトの名無しさん
06/09/04 12:16:32
59じゃないけど typedef 擁護派

>>62
>読みやすさより書きやすさを優先してるように見える
いや、読みやすさも向上する。
HashMap<String, LinkedHashMap<String, List<String>>>　が　HogeMap になるんだから、読みやすくなるじゃん。

>一般にコードは書かれた回数より読まれる回数が多いはず
>タイプ量を短くするためだけに新たな型名を定義するようなものは既存のJavaにはない気がするし
ないから提案してるんじゃん。既存のJavaにはないからってアイデアを否定するのってどうよ？

>Hogeの使い方を知るためにHeaderMapの定義を見ないといけないのはつらい
定義をみるなんて一瞬じゃん。
それなら、HeaderMapがtypedefじゃなくてclassで定義したとしても、定義を見ないといけないのはおなじだろ。

>Fuga.setHeaders(Hoge.HeaderMap m)とか伝染するとさらにつらい
意味不明

>Fuga.setAnotherHeaders(Map<String,List<String>> m)があったりして記述が一貫しなくなるのもつらい
別につらくない。typedefが導入されているC言語では、そのような批判聞いたことない。

74:デフォルトの名無しさん
06/09/04 12:58:14
>>73
> >Hogeの使い方を知るためにHeaderMapの定義を見ないといけないのはつらい
> 定義をみるなんて一瞬じゃん。

そこが(ry
でっかいファイルだと一瞬とはいかんと思う。
それから、他のファイルにまたがってるとなおさら

75:デフォルトの名無しさん
06/09/04 13:35:58
C++の標準ライブラリのtypedefの使い方を見れば、
うまく使われたtypedefが可読性を向上させるのが分かると思う。
特にGenericsの時に。

76:デフォルトの名無しさん
06/09/04 15:53:33
本来は、typedefは型を再定義することだから、読みやすいとか言うのとは、焦点がずれてる。
要求すべきは別名化 aliasとかじゃないかな？

77:デフォルトの名無しさん
06/09/04 17:04:14
>>74
そんな巨大なクラス作んないし

78:デフォルトの名無しさん
06/09/04 17:21:25
>>74
どんなチープな開発環境だよ
IDEの支援さえあればどんな巨大なクラスだろうと定義を見るのは一発だ

79:デフォルトの名無しさん
06/09/04 18:15:22
>>76
typedefとどう違うの？

80:デフォルトの名無しさん
06/09/04 18:33:39
>>76
ずれてない。
だれも「typedefは読みやすさのためにある」とは言っていない。

81:デフォルトの名無しさん
06/09/04 18:37:08
>>77-78
問題はC#のような変な仕様にならないことなんだが。

typedefで定義したものについて、さらにGenericsでパラメタライズ
するとかになったら・・・

それに対してさらにtypedefで再定義することもありえるんだな？
で、tytpedefで定義した型をGenericsのパラメタ型にするってことも
ありえるんだな。

混乱の元になりそうなのだが。
そのあたり、どう解決するのか？ IDE使っても限度があると思うぞ。

82:デフォルトの名無しさん
06/09/04 18:39:31
>>77
それはそうだが、
クラスが100あるとき、
100もの、あるいは200, 300ものtypedefで再定義した型を
作ることになると思うのだが。
一つのクラスにつきtypedefで5つの型を再定義したとすると、
クラスが100あると500ものtypedefによる再定義された型が出てくると言うことか。

>>78
巨大なクラスは作らない方がいいぞ。
しっかり分割統治してな。

83:デフォルトの名無しさん
06/09/04 18:57:52
>>82
自分ではそんなに作らんよ
ただ、字句解析のコード書くのに、StateパターンやInterpreterパターンなんて使ってられんし
クラス数が膨大になりすぎて、そっちのほうが管理できん

84:デフォルトの名無しさん
06/09/04 19:01:48
>>81
それは使い方にもよるだろう。
そんな変態的な使い方をして、読みやすくなるコードもあるはずだし
STLやBoostのコードを読んでるとよく分かるけどな
あ、あとsuperないのにtypedefで代用、とかな

#さすがにそこまで自由度の高いtypedefはいらないけどね

85:デフォルトの名無しさん
06/09/04 19:46:43
>>76
>>本来は、typedefは型を再定義することだから、読みやすいとか言うのとは、焦点がずれてる。
>>要求すべきは別名化 aliasとかじゃないかな？

C/C++のtypedefは、型に別名(alias)をつけるだけ。たとえば
typedef std::basic_string<char> stringA;
typedef std::basic_string<char> stringB;
で、コンパイラはstringA型とstringB型は同じ型として扱う。
だから焦点がずれていない。まさに要求どおりじゃないの。

86:デフォルトの名無しさん
06/09/04 20:04:34
>>83
Stateはenumで実現できまいか？

87:デフォルトの名無しさん
06/09/04 20:21:21
>>85 お前の知識が多いのは分かったから、引用をよく読んでみろよ。お前、よく相手の話を聞かないとかいわれるだろ？

88:デフォルトの名無しさん
06/09/04 20:26:22
>>79 >>80 >>85 お前のようなゴミはもういらん！もう半島に帰れ！

89:デフォルトの名無しさん
06/09/04 20:31:25
>>86
Stateパターンとenumは根本的に違うぞ
もちろんenumは使ってるけど、それはStateパターンじゃない。
しかも、enumったって、enumにメソッド持たせるんじゃなくて、
switchで分岐させてるだけだし

まぁ、字句解析はOOPできない典型例かもしれん
だれか解決策ないか？

90:デフォルトの名無しさん
06/09/04 20:32:32
>>85みたいに無駄に型名を増やすのは
まさにtypedefを悪用している例なんだよな

91:デフォルトの名無しさん
06/09/04 20:34:32
>>90
>>85はあくまで例えだろう
実際にあんな単純な状態にはならんよ

92:デフォルトの名無しさん
06/09/04 20:38:25
>>71 72
高階関数はおれも好き。でも型あり言語じゃ魅力半減じゃね？
javaで書く時は冗長でもアホでも分かるように書く癖がついちまったよ

93:デフォルトの名無しさん
06/09/04 20:41:17
>>91 お前が原因だな！わかったから巣に帰れ！

94:デフォルトの名無しさん
06/09/04 21:05:35
>>93
何の原因だよ・・・

95:デフォルトの名無しさん
06/09/04 23:12:55
おれも何の原因なのか気になる

96:62
06/09/04 23:21:23
>>73
読みやすさというのは理解が容易という意味で書いた
大抵の場合IDEで解決できるが，IDEが使えない状況もあるだろう
むしろIDEではHogeMapと書くとHashMap<...>に置き換えてくれるような機構があればいいんじゃないだろうか

>ないから提案してるんじゃん。既存のJavaにはないからってアイデアを否定するのってどうよ？
新たな機構を提案すること自体を否定してるわけじゃない
typedefを否定している

>それなら、HeaderMapがtypedefじゃなくてclassで定義したとしても、定義を見ないといけないのはおなじだろ。
サブクラスには可読性の問題解決のためでない意味があるべき

>>Fuga.setHeaders(Hoge.HeaderMap m)とか伝染するとさらにつらい
>意味不明
定義を見る先が他のクラスになるから
Map<...>を使うときはHoge.HeaderMapを使うべきかMap<...>を使うべきか判断に迷うのも嫌

>>Fuga.setAnotherHeaders(Map<String,List<String>> m)があったりして記述が一貫しなくなるのもつらい
>別につらくない。typedefが導入されているC言語では、そのような批判聞いたことない。
こんな状況は起こりえないからつらくないということ?

また，
typedefで(書きやすさのためでなく)抽象化を突き詰めるとあらゆる型をtypedefするほうがいいことになる

結局，複雑になるだけでいいことはあまりない
どうしてもやるならvar型とかで型推論の方がまだいいと思う(これが理解しやすいとは思えんけど)

97:デフォルトの名無しさん
06/09/04 23:47:40
なんで10文字20文字程度の記述の節約という、どうでもいいような理由で
言語仕様の一貫性をぶち壊しにするようなリスクの高い仕様を盛り込みたが
るんでしょうか。

10年前ならともかく、コード補完付のIDEがただで使える状況で何がつらいんだ
と小一時間（ry
おまえら1000人規模の大規模開発やったことあるのかと小一時間（ry

98:デフォルトの名無しさん
06/09/05 00:00:56
もうすでに、Javaもいろんな人が使う言語になってしまったからじゃないでしょうか？
今後さらに人が増えて、とんでもない溶融があると思います。
そして分化して独立して・・
そんなもんなんでしょう。

99:デフォルトの名無しさん
06/09/05 00:04:32
>>92
別に魅力半減はしないけどな。MLとかの型あり関数型言語使ったこと無い？
MLやHaskellでは、高階関数は当たり前のように使われてるよ

100:デフォルトの名無しさん
06/09/05 00:09:47
>>96
> どうしてもやるならvar型とかで型推論の方がまだいいと思う(これが理解しやすいとは思えんけど)
C# 3.0で入る予定の
　var hoge = new Hoge();//hogeはHoge型
みたいなやつのこと？
これなら別に理解しにくく無いと思うけどなあ
実装するのもすごく簡単で、コンパイラを数行弄るだけで実現できる機能だし

101:62
06/09/05 01:04:16
>>100
たぶんそう

理解しにくいというのは，IDEとかの支援がない状態で読むとき，
頭の中でvarを展開しなければならないということ
var hoge = make();
var fuga = hoge.getAttr();
...
ローカル変数だけで使えるなら
型安全だし，シンプルに見えるのはいいのだが，
明示的に書くよりはわかりにくい
(rubyのコードとか見てるとわかりにくいと感じる)

ところで
List makeList() {
var l = new ArrayList(); //この時点ではArrayList
...
l = new LinkedList(); //lはListでないと駄目だとわかる
...
return l; //この行でlがListと確定
}
こういうのもコンパイラを数行いじるので対応できるものなの?

102:デフォルトの名無しさん
06/09/05 01:40:53
>>101
確かに、var宣言された変数がメソッド呼び出しの返り値で初期化される
場合は、若干わかりにくいかもね。でも、ローカル変数で閉じてる限りは
大した差は無いと思う

> List makeList() {
> ...
> return l; //この行でlがListと確定
> }
> こういうのもコンパイラを数行いじるので対応できるものなの?

上のようなコードでちゃんと推論しようと思うと、さすがに数行いじるだけじゃ対応できない
自分が考えていたのは(おそらくC# 3.0のも)、var宣言の時点で初期化式の型で宣言される
ことが確定するようなもの。つまり、上のようなコードは
　l = new LinkedList();// lはArrayList型なのでLinkedList型の値を代入できない
の時点でエラーになる。実用上、これで不便になるケースはたぶんほとんど無いと思う。

103:デフォルトの名無しさん
06/09/06 06:35:51
>>96
>むしろIDEではHogeMapと書くとHashMap<...>に置き換えてくれるような機構があればいいんじゃないだろうか
それだと読みやすさは変わらんだろ。>>73でちゃんと「読みやすさが向上する」と書いているのに、よくわからんレスだな。

>新たな機構を提案すること自体を否定してるわけじゃない
>typedefを否定している
自分で書いたのをよく読め。否定する理由を>>62で「既存のJavaにはない気がする」と書いてるじゃん。
既存のJavaにはないからってアイデアを否定するのってどうよ？

>サブクラスには可読性の問題解決のためでない意味があるべき
ほんとに自分の都合のいいように話をもっていくな。おまえが指摘した点は、typedefだけでなくサブクラスでもあてはまる。
サブクラスを使うときには問題としていなかったことを、typedefのときだけ問題として取り上げることがおかしいという指摘をしているだけ。サブクラスの他の機能は関係ない。

>定義を見る先が他のクラスになるから
>Map<...>を使うときはHoge.HeaderMapを使うべきかMap<...>を使うべきか判断に迷うのも嫌
なんで迷うの？わざわざtypedefしてるんだからそれを使えばいいじゃん。

>こんな状況は起こりえないからつらくないということ?
おまえのように恣意的に使わない限りは、そんな状況は起こりえない。
おまえC言語使ったことないだろ。

>また，typedefで(書きやすさのためでなく)抽象化を突き詰めるとあらゆる型をtypedefするほうがいいことになる
いいわけないだろ。typedefを使ったほうがいいときだけ使えばいい。勝手に極論するな。

>結局，複雑になるだけでいいことはあまりない
おまえのような、意図的に間違った使い方なら複雑になるわな。

あれか、おまえもやっぱりJavaにはない機能はぜんぶ否定するJava絶対主義者か。
そんなやつに限って、Javaにその機能が導入されるといきなりマンセーしだすんだよな。

104:デフォルトの名無しさん
06/09/06 07:47:15
はい、はい。
ここでやっても意味無いから、むこうでやってね。

105:デフォルトの名無しさん
06/09/06 11:18:56
こんにちは。fondaのアプレット設置しようと思っていたのですが、
これって、有料なんでしょうか？
翻訳してみたところモノによって異なるようなのですが、
どれが無料で、どれが有料なのかわかります？
詳しく調べないで、勝手に設置したら、著作権とかヤバイですか？
URLﾘﾝｸ(www.fouda.de)

106:デフォルトの名無しさん
06/09/06 14:42:56
>>103
まわりくどいから簡潔に説明して。
二人だか何人だかしらないけど
一体どういう議論をしてんだか。

typedefマンセーだかなんだか知らないけど

107:デフォルトの名無しさん
06/09/06 14:45:12
>>105
ダウンロードしたファイルにREADMEとかlicense.txtとか入ってないのか？
それ読めば解ると思うが、なかったらサイト見ろ

108:デフォルトの名無しさん
06/09/17 22:20:56
そもそもJavaってもっともっと馬鹿な連中がネットワークプログラミングしても困らない様にって進化してきた言語だろ
あんまり複雑な機能加えるなよ
やりたきゃ既存の言語でつくってJNIするなり、Webサービスにするなりすれば良いじゃん

109:デフォルトの名無しさん
06/09/17 22:34:03
>>108
お利巧さんな君は何をしているのかな？

110:デフォルトの名無しさん
06/09/17 23:22:17
何も作れないからひがんでるんじゃないか

111:デフォルトの名無しさん
06/09/17 23:29:42
>>108はJavaスレに「ドトネト厨きーきー」のＡＡ張ってJavaスレを荒らしている奴だろ。

112:デフォルトの名無しさん
06/09/17 23:31:15
>>110
そうかもな。
奴は昔はVBが得意だったらしいが。
2chでDelphiプログラマと喧嘩して、そしてJavaプログラマとも喧嘩して
C#死滅スレで大暴れした末に、演算子オーバーロードをつけられないJavaは糞だとか
なんだと連呼したものの、結局C#を普及させることはできずに失敗し
今はJavaスレを荒らすようになってしまった。

113:デフォルトの名無しさん
06/09/19 11:10:29
Javaのenumはキモイ

114:デフォルトの名無しさん
06/09/19 12:15:22
ぜんぜん。使いやすいけど

115:デフォルトの名無しさん
06/09/19 13:04:07
>>112
自己紹介乙(ﾌﾟ

116:デフォルトの名無しさん
06/09/19 15:10:52
わろたVBマンセーしてることが自己紹介かw

117:デフォルトの名無しさん
06/09/19 23:58:25
わけあってちょいと現場を離れてた。
今度戻るけど、世の中、Javaと.NET系ではどっちの方が仕事多い？

118:デフォルトの名無しさん
06/09/20 00:06:59
>>117
場所による
ただ値段的にはJava>.NETなのはほぼ確実

ここの所客から.NETにすればもう何割か減らせません？って聞いてくるケースが多いから.NET＝安いってイメージらしい

119:デフォルトの名無しさん
06/09/20 00:20:54
結局 commons-lang の Enum 使ってる。

120:デフォルトの名無しさん
06/09/20 01:23:54
>>117-118

値段がJavaのほうが上だということが確実だって話は始めて聞いた。
仕事はJavaのほうが確実に多いが。

.NETの価値は薄いと考えている客が多いのか。
それはマイクロソフトにとっては痛い話なんだろうな。

121:デフォルトの名無しさん
06/09/20 10:29:07
マイクロソフトのマーケティングの失敗だな
Javaと.NETじゃ大して難易度変わらないのに

122:デフォルトの名無しさん
06/09/20 10:37:35
JavaじゃなくてUnix Serverが高いと思われてるような希ガス

123:デフォルトの名無しさん
06/09/20 11:40:04
>>117です。
いろいろアドバイスありがとさん。
Javaの方が仕事的には減ることはなさそうな印象を受けました。
ただ、私のまわりの中小ITはVB.NETの話が多いですね。
VB.NETの市販本買って読んだら、文法はJavaにそっくり。
とりあえず、昔覚えたJavaから復活していきます。

また、何か追加情報があったらカキコんでください。ヨロシク！！

124:デフォルトの名無しさん
06/09/20 11:44:08
最後の一行がなければさぁ……

125:デフォルトの名無しさん
06/09/20 12:01:44
>>123
> VB.NETの市販本買って読んだら、文法はJavaにそっくり。

それC#の方の.NETちゃうんかと

126:デフォルトの名無しさん
06/09/20 12:43:47
そりゃ、「”無料の”Eclipseを使うよりもVS.NETを買ったほうが作りやすく安上がりです。」
みたいなマーケティングしてるんだから.NETの方が安上がりって思うだろ普通

127:デフォルトの名無しさん
06/09/20 13:36:21
それはとんでもなく裏目にでたな。

マイクロソフトのマーケティングが
今、オープンソースの台頭によって逆効果になってしまったわけか。

128:デフォルトの名無しさん
06/09/20 13:37:28
しかもVS.NET2003Expressも慌てて一年間限定で無償で配布してしまった。
Eclipseが出てから何もかも変わってしまったな。
IBM恐るべし

129:デフォルトの名無しさん
06/09/20 13:48:42
だってVSって有償なのにEclipseにも及ばんし
つーかNetBeansにも及ばんし
ぶっちゃけIDEとしてはショボいし

130:デフォルトの名無しさん
06/09/20 14:50:36
昔、Javaの仕事が一段落した時に
上司がVBできる人を探していて
俺はできるけどできないと言った
他の奴ができるといってVB部隊に
行ったけどそれ以来見ていない

131:デフォルトの名無しさん
06/09/20 22:28:06
VB.NET は言語そのものは悪くないんだが
案件の内容がひどそうなイメージがある。

132:デフォルトの名無しさん
06/09/21 00:23:48
>>130
そんなことあったな。
2001年春のこと、まだServlet/JSPが普及していなかった時代。
CGI + Perlの10倍以上のパフォーマンスを出すこともできると
もてはやされたあのServlet。

ServletプログラミングができるけどASPはできないと言ったんだ。
でもう一人の奴はASPができるけどServletをやってみたいって言っていたが
ASPができるといったために、「じゃ、ASPのほうお願いね」
とか言われて彼はASPをやらされた。まだまだ当時新鮮だった
Servlet/JSPの仕事を与えられる俺のことを羨ましがっていた。

133:デフォルトの名無しさん
06/09/21 00:26:34
>>131
ひどいっていうか、VBとVB.ＮＥＴは同じだからVBしかできない奴を
かぎ集めてもなんとかなるだろうという甘い考えを持っている上司やVB厨が
いたから酷いことになったんだろうな。
「.NET構想」と「Javaは廃れてこれからC#が流行る！」というM$の宣伝に騙されて
ＶＢからＶＢ.NETへ移行しようとしたVB厨は、VB慣れしすぎてC#やJavaのような
言語が取っつきにくて躓いたってわけだ。
Perl厨やPHP厨やRuby厨がJavaをやり出したら同じような躓きを覚えるんだろうな。

134:デフォルトの名無しさん
06/09/21 14:13:11
スクリプト言語とJavaはライバル関係にはない

135:デフォルトの名無しさん
06/09/21 15:25:12
でも人は使いまわすからねー

136:デフォルトの名無しさん
06/09/21 16:17:34
ちょっと2,3ヶ月の応援がずるずると2,3年になるのはよくあること
2,3年もVBやスクリプト言語やったら戻れないだろう
もう経歴書からはVB屋・スクリプト屋としか思われない
身の振り方は後々のことまでよく考えてしないとな

137:デフォルトの名無しさん
06/09/21 16:41:00
マ板行けよ。

138:デフォルトの名無しさん
06/09/21 16:55:12
スクリプト屋の特徴は、
Design by Contractを守ることができないことなんだな

139:デフォルトの名無しさん
06/09/21 19:19:24
スクリプト系の言語とJavaとの違いってなんなの？
同じじゃん。

140:デフォルトの名無しさん
06/09/21 19:36:36
Java,C++.C#,D言語は型にがっしり硬い言語
静的型付け言語であるケースが多い。

Ruby, PHP, Perl, VB, JavaScriptなどは一般に型が軟らかい言語。
そして動的型付け言語であるケースが多い

こういう違いがある。

141:デフォルトの名無しさん
06/09/21 20:34:09
昔はGCがあるかないかとか、すぐ実行結果が出る出ない（コンパイル必要）だったけどね。

142:デフォルトの名無しさん
06/09/21 21:03:44
今じゃPerl6にもGCがつくからねえ。

C++やD言語と同列に並べるにはCGがあるなし
区別は苦しい。

コンパイル必要不要も今じゃ苦しい。
ソフトウェア工学という観点から見ないと。

143:デフォルトの名無しさん
06/09/21 21:21:07
なんだかんだ言っても顧客がどう見るかじゃない？
ソフトウェア工学という観点からなんて顧客は聞きもしないよ

144:デフォルトの名無しさん
06/09/21 21:25:10
だが、顧客がプログラマであった場合は、そうもいかない。

実際に、C++とかJavaとかでプログラミングをするのはソフトウェア工学
に熟知しているものだからな。

スクリプト言語だと動的言語としてのソフトウェア工学にこだわりを
持つことになるだろうが。

145:デフォルトの名無しさん
06/09/21 23:16:40
Javaはリフレクションとかアノテーションからして
スクリプトじゃない代表格C＋＋と比べればより動的じゃないの？

146:デフォルトの名無しさん
06/09/21 23:17:37
ソフトウェア工学に熟知とかありえんｗｗｗ
どうせ日経なんとかの受け売りに決まっている

147:デフォルトの名無しさん
06/09/21 23:35:36
>>145
なんかちがような気がする。
それだったらC++のほうが柔軟性がきくので動的だと思う
Javaは定められた文法規則を厳重に守らないと逝けないから

148:デフォルトの名無しさん
06/09/21 23:54:59
Javaは、C/C++の文法にとてもよく似せて作ってあるけど、動的とどう関係しているのかな？
>>147

149:デフォルトの名無しさん
06/09/22 00:17:49
アノテーションは動的とはあまり関係ない。
修正→コンパイルが必要と言う意味では静的。
Java では virtual/override が存在せず、
final 指定されてない同名メソッドを無条件で上書きするところが
動的な性質の最たるものの一つに感じる。
正直、virtual/override が欲しい。

とりあえずDI+強い型付以外の開発はもうやりたくない。

150:デフォルトの名無しさん
06/09/22 01:01:25
>>149
> Java では virtual/override が存在せず、
> final 指定されてない同名メソッドを無条件で上書きするところが
> 動的な性質の最たるものの一つに感じる。
> 正直、virtual/override が欲しい。

おいおい、@Overrideアノテーションがあるだろ。
virtualはいらないけど。

しかしそれが、動的なのかねえ

151:デフォルトの名無しさん
06/09/22 01:19:31
普通「C++とJavaだとJavaの方が動的」という文脈では
・「動的」といったら実行時解決のこと
・「静的」といったらコンパイル時解決のこと
を指すわけなんだが、君は何アホなこといってんの？

152:デフォルトの名無しさん
06/09/22 02:25:10
型付けを見たらC++のほうがJavaより動的なんだが。

153:デフォルトの名無しさん
06/09/22 02:26:55
>>152
君も何アホなこといってんの？

154:デフォルトの名無しさん
06/09/22 03:41:19
Javaではコンパイル時に型整合性チェックは行うが
利用するコードは実行時のライブラリに応じて動的解決される
結局は型チェックは行っており、メッセージ投げてみればわかるべ、という
Objective-Cほど動的ではないと言える

中庸を目指した設計だからな

155:デフォルトの名無しさん
06/09/22 05:41:19
>>144
Javaはスクリプト言語じゃないと区別したいのは分かるが、
virtaul/overrideのキーワード有無とかJavaに対しての不満の方が強いみたいで、
ソフトウェア工学とか意味不明なところからスクリプトとJavaを区別しようとしてるから、
行き詰まるんじゃないかな？

156:デフォルトの名無しさん
06/09/22 05:47:40
>>153 君の方がアホっぽいけど、気がつかないか？

157:デフォルトの名無しさん
06/09/22 13:31:15
静的型付けと動的型付けの意味も分からんとは

158:デフォルトの名無しさん
06/09/22 14:36:15
dynamic_cast 使ってる？

159:デフォルトの名無しさん
06/09/22 14:44:17
refrection API使ってる?

160:デフォルトの名無しさん
06/09/22 14:45:46
C++とJavaのいいとこ取りすると、どんな言語が生まれるんだろうね。

161:デフォルトの名無しさん
06/09/22 15:14:48
>>160
φ

162:デフォルトの名無しさん
06/09/22 15:36:19
C++/CLI。
結果良くなったかどうかはワカンネ。

163:デフォルトの名無しさん
06/09/22 15:46:31
>>162
結局MSに持ってかれたってことか？
とにかくワロタ

164:デフォルトの名無しさん
06/09/23 03:03:12
実行時にクラスファイルをロードしてしまうJavaはかなり動的だと思う。
しかもパッケージ=フォルダ。
rubyだってrailsでやっと動的ロードを手に入れたくらいなのに

165:デフォルトの名無しさん
06/09/23 03:12:09
>>160
Ｄ言語

166:デフォルトの名無しさん
06/09/23 03:13:30
>>164
だからそれは「動的型付け」とは関係ないと何度いったら(ry

一度作ったクラスの仕様を変える事ができてしまうのが
動的型付け。

たとえばクラスに有るはずがないフィールドやメソッドを追加したり

167:デフォルトの名無しさん
06/09/23 03:40:31
>>166
それは動的型付けの副作用でしかない。
フィールドやメソッドを実行時に追加したいだけなら、AOPでも事足りる。

168:デフォルトの名無しさん
06/09/23 04:00:53
と、いうけど、まじでソースコード
読みにくくなるんだよね。

Ajaxのソースコードなんかとくにひどいもんだ

169:デフォルトの名無しさん
06/09/23 07:44:57
>>166
おしい！実におしい！！

170:デフォルトの名無しさん
06/09/23 09:17:23
文字列がコードになるのが動的と思っていたけど、違う？

171:デフォルトの名無しさん
06/09/23 17:17:24
動的っていったら、プログラムの実行時になにかすること。
静的っていったら、プログラムの実行前になにかすること。

違う？

172:デフォルトの名無しさん
06/09/23 17:31:04
JMXってなににつかうん？サーバ監視だけ？

173:デフォルトの名無しさん
06/09/23 17:45:50
>>172
じゃないの？他に使い道ある？
っていうか今頃この辺が整備されるって遅すぎ

174:デフォルトの名無しさん
06/09/24 11:24:15
>>166
動的/静的型付けの違いは、式の型がコンパイル時に決まるかどうかだから、
メソッドの追加は関係ない。

だいたい、その説明だと
たいていの言語はソース書き換えてコンパイルすればメソッド追加できるから
たいていの言語は動的型付けになっちゃうよ。

175:デフォルトの名無しさん
06/09/24 11:46:49
あほですか?
メソッドが追加されたらクラス、つまり型が変わるだろ。

それだけでも動的なのに、
どう変わるかも実行時にしか分からないかもしれない。

176:デフォルトの名無しさん
06/09/24 12:33:16
>>175
「あほ？」とはずいぶんと強気だけど
「メソッドが追加されたらクラス、つまり型が変わるだろ」
どういうこと？まったく意味が分からんけど？

177:デフォルトの名無しさん
06/09/24 15:55:31
Genericsでちょっと疑問に思ったんだけど。
メソッド単体でのGenericsって引数なしだと何もできない気がする。

<T> <T> get();

これ動かないよね？
Tをnewすることもキャストすることもできないんだから。

178:デフォルトの名無しさん
06/09/24 16:03:49
キャストはできるか

179:デフォルトの名無しさん
06/09/24 16:19:49
>>174
まてまて、それでJavaScriptの型とJavaの型との違いをうまく
説明できるか？

180:デフォルトの名無しさん
06/09/24 18:31:54
166の言ってることは、動的クラスっていうだけだな。
動的クラスを使うためには動的型付が必要になるが、クラスがなくても動的型付けはできる。

動的言語処理(実行時型解決など)ができるかどうかは、言語自体が動的型付か静的型付かには関係ないよ。

181:デフォルトの名無しさん
06/09/24 23:39:09
１の趣旨とは全然無関係だが、静的・動的の話は面白いと思った。

182:デフォルトの名無しさん
06/09/25 00:37:07
こんなかんじ

typedef struct {
　Class *extends;
　Interface **implements;
　void **methods;
　void **fields;
} Class;

183:デフォルトの名無しさん
06/09/25 01:18:31
>>181どのへんが面白いの？

184:デフォルトの名無しさん
06/09/25 15:46:03
「動的型付」、という特定の機能を指す言葉(専門用語)は
一般の熟語ではないという合意が得られてないので
「動的」という一般的な形容詞句の話が混じってしまったのが混乱の元。

学会とか専門家ばかりが集まってる場所じゃないから
前提はある程度しっかりしてた方がいいな
まぁ、それくらい分かれよ、と突き放すこともできるが
いろんな人が集まれるこういう場所だ、お互い尊重すればあれることもない

185:デフォルトの名無しさん
06/09/25 15:52:37
>>184
もまえ、わかってるようだな。

186:デフォルトの名無しさん
06/09/28 15:39:12
>>177
一応できることはできる。未検査キャスト入るし、実際には使い道が無いが

public class Variant {
　private Object value;
　public <T> void set(T value){
　　this.value = value;
　}
　public <T> T get() {
　　return (T)value;
　}
　public static void main(String[] args){
　　Variant v = new Variant();
　　v.set("foo");
　　String s = v.<String>get();
　　System.out.println(s);
　}
}

>>166
クラスにメソッドを追加できるかどうかと、動的型付けかどうかは無関係。
実際、静的型付けで既存のクラスにメソッドを追加できる言語もある。MixJuiceとか

187:デフォルトの名無しさん
06/09/28 23:17:36
アスペクト指向言語ライクな言語MixJuiceか

188:デフォルトの名無しさん
06/10/06 20:57:19
>>177 ????

<T> T get(){
SomeFactory<T> factory = new Factory<T>();
return factory.getInstance();
}

189:デフォルトの名無しさん
06/10/06 22:02:16
Factoryフレームワークか。恐ろしくて使いたくないよｗ

190:デフォルトの名無しさん
06/10/06 22:37:27
factoryは大げさな感じがうざいが、時には有効

191:デフォルトの名無しさん
06/10/06 22:42:19
ファクトリ否定したらDIコンテナ使えないな。

192:デフォルトの名無しさん
06/10/06 22:52:55
例えば
Validator<EMailAddress> emValidator = ValidatorFactory.get();
みたいなことが出来るならあるいは便利かとも思うが
<T>からClassインスタンスって取れないから使えないな

193:デフォルトの名無しさん
06/10/07 16:19:16
Color color = StringConverter.fromString("0, 0, 0");
Point pt = StringConverter.fromString("0, 0");

みたいにしたかったんだけど、Class取れないんで、

Color color = StringConverter.fromString("0, 0, 0", Color.class);
Point pt = StringConverter.fromString("0, 0", Point.class);

で我慢した。Class取れればいいのにね。

194:デフォルトの名無しさん
06/10/13 02:42:15
URLﾘﾝｸ(www.uploda.org)

向こうでやるとスレ違いだから
スタティックメソッドとインスタンスメソッドの
呼び出し性能を検証する簡単なコード書いてみた
実行速度見たかったから、俺はヒープサイズ余裕持たせて
実行してみたけど、性能は誤差だね
メモリ消費量はもっとやってみないとわかんないね

195:デフォルトの名無しさん
06/10/25 20:21:41
スレ違いって言われたのでココでお聞きしたいのですが、
AWTは１コンポーネント＝１ウインドウだからシステムリソースを
食いまくる問題って解決されたのでしょうか？

196:デフォルトの名無しさん
06/10/25 21:01:15
>>195
つURLﾘﾝｸ(java.sun.com)

197:デフォルトの名無しさん
06/10/26 00:09:36
Lightweightという単語を初めて見たのはSwingについての説明だったと思うが、
こんなに流行るとは思わなかった

198:デフォルトの名無しさん
06/10/26 00:14:07
Component ベースだと普通にSwing使ったほうが手軽だし高速になるよな

199:デフォルトの名無しさん
06/10/26 01:48:13
>>196 この様子だと、永遠に解決されないみたいですね。

200:デフォルトの名無しさん
06/10/26 02:59:30
>>199
それはOSの問題だと思うが

201:デフォルトの名無しさん
06/10/26 03:05:05
AWTがリソース食うってのは、要するにMFCのCButtonなんかが
ウィンドウだってのと同じことなんだが、わかってる?

202:デフォルトの名無しさん
06/10/26 12:47:03
改善はそれぞれ SWT, Swing, AWT でそれぞれ実験（実装）済みってこと。
Windows9xのときはGDIとかシステムリソース気にしてたけど、
今じゃそんなのどうでもよくて、レスポンスが速いかの方にうつってる。
リソース食いまくるとか過去の話し出し、つまり一番速いAWTつかってOK。

203:デフォルトの名無しさん
06/10/26 13:03:36
でも貧弱すぎてつかうやついねーよ

204:デフォルトの名無しさん
06/10/26 20:04:32
Swing結構速いけど？

205:デフォルトの名無しさん
06/10/26 22:59:45
>>204 Pentium 133 とかだとどうだ？

206:デフォルトの名無しさん
06/10/26 23:02:32
それだとWindowsXPどころか2000やNT4もおもいぞ

207:デフォルトの名無しさん
06/10/26 23:12:38
あれだ、Pentium133は少し言い過ぎだけど、Swingでプログラム作っても
そのプログラムの処理は低速CPUで事足りるんじゃないか？

Javaってのは最新・現状のパソコンだけをターゲットにした言語じゃないだろ。

208:デフォルトの名無しさん
06/10/26 23:22:41
VMは最新に
そしてメモリの速度やキャッシュの速度は速いほうがいい
NetburstアーキよりPenM系列のほうが早い

あとSwingはJava2Dが需要なのでアクセラレーションのレスポンスがいい統合チップセットは意外と早い

Swing使った業務アプリはずっと作ってるけど快適さはやっぱりコードにもよるね
OSがNT4でJRE1.3.1、Pen3/600MHzは快適だった
2000やXPだと5.0にしてPen3/1GHzクラスにならないと快適さはおいつかない感じ

209:デフォルトの名無しさん
06/10/27 00:08:33
>>208
それはSwingやJavaが速いとかではなくて、ハードが進化して速くなった事はじゃないか？
業務アプリならなおさらだけど、端末がNTでPentium 200-600とかざらだからね。
それでSwingはないだろ。そしてJavaつかってもらいたいのに、
AWT無視とかどういうことだ？これだったら、UIはWebブラウザの方に流れて当然。

2D, 3DはJavaでなくてC/C++や専用ライブラリ使うから、
Javaはいくらハードが進化しても入り込めない。
今も昔も、何年たってもいまだにJava向けのヒットゲームないでしょ？

210:デフォルトの名無しさん
06/10/27 00:12:56
>>209
ハードも大事だし、VMの種類も大事とかいてるだろ
1.2と5.0くらべたら恐ろしいほどの性能さだぞ

それに当時のマシンならブラウザよりSwingのほうがはるかに軽いぞ
ブラウザってかなりメモリは食うし重いものなんだよ
それにインターフェースとして参照系ならともかく入力系はおわっとる
AWTも機能不足

ゲームは今MMORPGとかで海外はJava製ふえてきてる

211:デフォルトの名無しさん
06/10/27 00:43:01
性能差は認めるが、その効果が実感できるのは性能（VMの出来）よりも
ハードの進歩が格段に勝っていたってこと。ハード（CPUやGPU）はJavaだけ
じゃなくて他の処理（OSやイベント）をこなして、さらに余った余力でやっても、
VMの性能よりも高速ってどういうこと？

業務アプリはデータベース問い合わせを想定しているが、
大体は業務アプリはその程度じゃないか？AWTやブラウザで十分だろ。
つまりブラウザが重いとか言ってるなら、(winなら）VBとかでUIつくっても
いいけど、そうするとどこにJava（とSwing）の出番があるんだ？

212:デフォルトの名無しさん
06/10/27 00:48:54
>>211
DB引いてくるだけて、・・・・どんな業務アプリ・・・
集計ロジックくらいは、入るだろ。

ユーザとのインタラクションはいくらでも入ってくる。

213:デフォルトの名無しさん
06/10/27 01:00:09
どうもJavaがデスクトップに入り込めないでいるのは、
「出番なし」だからじゃないか？
C, C++, Perl, Ruby, JavaScript ライバルの方が強すぎて
（PCの）デスクトップには入れないだろ。
ネットワークでも、アプレットでこけたのがいたかったんじゃないか？
今じゃFlashに持ってかれてるし… （デスクトップの話ね）

214:デフォルトの名無しさん
06/10/27 06:54:07
ビジネス系だとAppletのが多いけどな。
まあオーサリングツールが無かったのと
ダウンロードの手間がFlashのが少なかったというのが大きい

215:デフォルトの名無しさん
06/10/27 08:28:55
>>212
集計ロジックはサーバサイドにやらせて
画面は入力と参照だけの作りが多いと思う。
三階層モデルが普通。DB直で触るような
C/Sモデルは5年前くらいに下火になってる。

それよりも210氏が指摘してるが入力系での優位性が大きい。
ブラウザで入力なんてのは業務系だと無理。
(業務系はえてして入力項目数が多い。)
ここ数年はそれでやってきたプロジェクトが多いけど
結局効率下げるだけで現場では不評。
これからはブラウザベースで作った業務アプリを
作り直す需要が多くなる。(既に増え始めてる。)
リッチクライアントの標準を巡って主導権争いが盛んなのもそれを見越してるから。

Swing は能力的に善戦できると思うんだけど
JRE 入れないと行けないところが難点。
(業務系になると致命的な問題にはならないことが多い。)
FLASH の方がウケが良いのは確かだが、
Swing アプリの方が制約の少ない分、後で盛り返せる余地はあると思う。

アプレットは問題外。これ提案するようなベンダーと付き合うべきでない。

216:デフォルトの名無しさん
06/10/27 09:40:09
FLASHで業務アプリって今流行ってんの？

217:デフォルトの名無しさん
06/10/27 11:06:46
>>215
>ここ数年はそれでやってきたプロジェクトが多いけど
>結局効率下げるだけで現場では不評。
>これからはブラウザベースで作った業務アプリを
>作り直す需要が多くなる。(既に増え始めてる。)
>リッチクライアントの標準を巡って主導権争いが盛んなのもそれを見越してるから。
でもこのおかげで社員のほとんどは意味も無いのにPCの前に座らせる必要が無いって事に経営層が気づいたのは事実
更に業務はパッケージ買って、経理/人事の社内総務部門をアウトソースして
株主へ利益を還元していく仕組みが出来上がりつつある

218:デフォルトの名無しさん
06/10/27 12:12:50
サーバーサイドが普及してきたのはこの5年ほどだし
すべてWEBアプリになってるわけじゃない

クライアントサーバーも開発コストの面で優れるために今でも業務系では多いし
WEBアプリからクラサバや３層式への動きもある
って>>215と重なることばっかりだ
業務系パッケージ／受託とかクラサバ多くてびびるかもよ
ようは流行とか関係なくユーザーの求めるもの作ったところが勝ち

ただアプレットはリッチクライアント用途として問題ないと思うぞ
WEBスタートにしてもいいわけだし、もちろんSwingを使うわけだし

>>216
開発ライセンスの問題とか高コストとかライブラリが整備されていないとかあって
わりと敬遠されてる
3倍金はらってくれるなら作ってもいいとはよく言われる

>>217
総務のアウトソースってはやってるようには見えないし、
パッケージのカスタマイズだけでは無理な場合も多いぞ
無理してカスタマイズされたコードのさらに修正とか死ぬぞ
新規に作ったほうが早くて使いやすい場合も多い

日本はユーザーがパッケージに業務をあわせる文化ないからね

219:217
06/10/27 12:37:05
>>218
仕組みが出来つつあるってこと
偽装派遣を合法化した結果はおそらくそこに影響が出る
最終的には金を生み出す仕組みと借金の担保になる会社という資産以外は交換可能な部品にするのが今の経団連のトップ辺りに居る連中の考え方

220:デフォルトの名無しさん
06/10/27 13:19:18
偽装請負がいつ合法化されたの？
この数年どんどん手が入ってるでしょ

キヤノンとか偽装請負すべてやめると明言したばかりでしょ

次ページ