「言語は育てるもの：Javaの未来の姿とは」記事へのコメント

Java++

[Anonymous Coward]

拡張されたJavaを、人々はJava++と呼ぶだろう。
（一部で）C++が忌み嫌われたように、Java++も同じ運命を辿る。

もっとも、後置演算子なので『まだ足されてない』んだけど。

Re:Java++

[programmer (12835)]

個人的な意見ですが。
・Javaは、C++よりはましだと思う。
    でも他のどの言語よりもよいかというと、そうは思わない。
    悪くはないけど、そんなによくもない。
・今のJavaは、言語仕様の肥大化よりも、関連技術の肥大化のほうが問題ではないか。
    JDBC、Servlet、JSPぐらいまではよかったが、EJB、カスタムタグ、JSTL、…など
    捕らえきれない。
    C++は言語仕様自体が膨らみすぎたけど、Javaは関連技術が膨らみすぎて困

Re:Java++

[Anonymous Coward]

言語仕様の肥大化よりも、関連技術の肥大化のほうが問題ではないか。

それって、他の言語だと避けられるの？ 単に対応してないってだけか、対応してても、標準化されてなくてAPIが乱立してるか、あるいは、単に存在を知らないだけでは。

Re:Java++

[programmer (12835)]

> それって、他の言語だと避けられるの？ 単に対応してないってだけか、
> 対応してても、標準化されてなくてAPIが乱立してるか、あるいは、
> 単に存在を知らないだけでは。

はは、この指摘はその通りかも。
ところで聞くんだけど、例えばEJBって筋がいいと思う？
EJBはオブジェクトとRDBMSをむりやりくっつけたようにしか
思えないんだけど。
オブジェクト指向DBのほうがずっと素直で使いやすかったな。

> 長いからいいんじゃない。読んだだけで何かわかる。
> その良さがわからない君は使えないプログラマだと断言できる。

これはちょっと反論するかな。

Re:Java++

[Anonymous Coward]

私は、おそらくプログラマさんの言うあなたではないですが。

EJBが筋が良くないなら代替手段をがんばって作るか、時間がないなら見つければいい。
それが駄目なら恨みつつ使う他はない。
さらに言えば､ある関連技術の筋が悪いどうのってのは、>>他の言語だと避けられるの？
もっと言うと、プログラマさんごのみに筋を良くしたらしたで具合悪い人もいると思う。

>toString()がstr()に
できるなら、略すのはやめてください、略すのは。
String = str なのは習慣的に理解できるけど、
そのうちに、Element = Elem(

Re:Java++

[Anonymous Coward]

言語の性質(?)上、仕方が無いのかね。

> はっきり言って、眠い頭でも理解できるコードならなんでも良いですよ。

寝ぼけてるヤツはコードを触るな。

> 1.人間に記憶力を求めないで、お願い。

そのために便利なエディタがあるんです。
定義位置を参照できたり、マウスを持っていくだけで…ほら整数型だ。

> 2.自分の感覚を他人に求めないでおくれ、頼むから。(略語とか)

文化に馴染むタイミングだと思う。
strcmpに何の抵抗も無いでしょ？
# あなたがＣ

Re:Java++

[Anonymous Coward]

C は好きだったけど

> strcmpに何の抵抗も無いでしょ？

当時から今まで StringCompare のほうがベターだと思う。

あまり長い名前は好きじゃないけど、数文字を節約して読みにくくなるのは勘弁願いたいトコ。

Re:Java++

[programmer (12835)]

> あまり長い名前は好きじゃないけど、数文字を節約して
> 読みにくくなるのは勘弁願いたいトコ。

このさじ加減に、つまりわかりやすい・わかりづらいと感じる
しきい値に個人差があるんだろうね。

Javaは、必要以上に名前が冗長すぎて、わかりやすいのかもしれない
けれど逆に読みにくいと感じていました。
getElementAt()やhasMoreElement()は確かに分かりやすいけど
書くのも面倒なら、読むのもなんか読みにくい。
例えるなら、x * y と書けてほし

フレームのもと？

[Anonymous Coward]

>例えるなら、x * y と書けてほしいのに x.multiply(y) としなきゃ
>いけないような感じ。わかるけど、読みにくい。

• str[i] と書けて欲しいのに str.charAt(i) としなきゃいけない。
• if (flags & BIT) {} と書けて欲しいのに if ((flags & BIT) != 0) {} としなきゃいけない。
• if (obj) {} と書けて欲しいのに if (obj != null) {} としなきゃいけない。

Re:フレームのもと？

[Anonymous Coward]

0やNULLが条件式で特別扱いされるのは合理的でもなんでもないですし混乱を引き起こしてきてもいます。

代入の問題もそうだし、関数の返り値が「0あるいはNULLが異常値でそれ以外が正常結果」という意味に統一されているかというとそんなことはぜんぜんないし、そういう統一が無いんだったら、プログラマとしてはifが0やNULLを特別扱されることの意義は「!=0」「!=null」を記述上省略できることでしかない。要するに慣れの問題でしかない。確かにCプログラマはこのような問題を慣れと工夫と習熟で補ってきました。「C言語はプロ向けの言語だから..」とい

Re:フレームのもと？

[G7 (3009)]

>0やNULLが条件式で特別扱いされるのは合理的でもなんでもないですし混乱を引き起こしてきてもいます。
>ifの条件をbooleanに縛る

まったくです。少なくともこの点は、(Cと比べて)Javaは良いと言い切れる。