アカウント名:
パスワード:
言語仕様の肥大化よりも、関連技術の肥大化のほうが問題ではないか。
それって、他の言語だと避けられるの？ 単に対応してないってだけか、対応してても、標準化されてなくてAPIが乱立してるか、あるいは、単に存在を知らないだけでは。
>例えるなら、x * y と書けてほしいのに x.multiply(y) としなきゃ >いけないような感じ。わかるけど、読みにくい。
読むときに多少ゴチャついて読みにくいかもしれないけど、慣れれば平気。
代入の問題もそうだし、関数の返り値が「0あるいはNULLが異常値でそれ以外が正常結果」という意味に統一されているかというとそんなことはぜんぜんないし、そういう統一が無いんだったら、プログラマとしてはifが0やNULLを特別扱されることの意義は「!=0」「!=null」を記述上省略できることでしかない。要するに慣れの問題でしかない。確かにCプログラマはこのような問題を慣れと工夫と習熟で補ってきました。「C言語はプロ向けの言語だから..」とい
str[i] と書けて欲しいのに str.charAt(i) としなきゃいけない。 if (flags & BIT) {} と書けて欲しいのに if ((flags & BIT) != 0) {} としなきゃいけない。 if (obj) {} と書けて欲しいのに if (obj != null) {} としなきゃいけない。 コーディング中にそんな些細なことで思考回路を妨げられたくないです。
ううむ、自分が慣れている書き方が書きやすいのは判る。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
Java++ (スコア:2, おもしろおかしい)
（一部で）C++が忌み嫌われたように、Java++も同じ運命を辿る。
もっとも、後置演算子なので『まだ足されてない』んだけど。
Re:Java++ (スコア:1)
・Javaは、C++よりはましだと思う。
でも他のどの言語よりもよいかというと、そうは思わない。
悪くはないけど、そんなによくもない。
・今のJavaは、言語仕様の肥大化よりも、関連技術の肥大化のほうが問題ではないか。
JDBC、Servlet、JSPぐらいまではよかったが、EJB、カスタムタグ、JSTL、…など
捕らえきれない。
C++は言語仕様自体が膨らみすぎたけど、Javaは関連技術が膨らみすぎて困
Re:Java++ (スコア:0)
それって、他の言語だと避けられるの？ 単に対応してないってだけか、対応してても、標準化されてなくてAPIが乱立してるか、あるいは、単に存在を知らないだけでは。
Re:Java++ (スコア:1)
> 対応してても、標準化されてなくてAPIが乱立してるか、あるいは、
> 単に存在を知らないだけでは。
はは、この指摘はその通りかも。
ところで聞くんだけど、例えばEJBって筋がいいと思う？
EJBはオブジェクトとRDBMSをむりやりくっつけたようにしか
思えないんだけど。
オブジェクト指向DBのほうがずっと素直で使いやすかったな。
> 長いからいいんじゃない。読んだだけで何かわかる。
> その良さがわからない君は使えないプログラマだと断言できる。
これはちょっと反論するかな。
Re:Java++ (スコア:0)
EJBが筋が良くないなら代替手段をがんばって作るか、時間がないなら見つければいい。
それが駄目なら恨みつつ使う他はない。
さらに言えば､ある関連技術の筋が悪いどうのってのは、>>他の言語だと避けられるの？
もっと言うと、プログラマさんごのみに筋を良くしたらしたで具合悪い人もいると思う。
>toString()がstr()に
できるなら、略すのはやめてください、略すのは。
String = str なのは習慣的に理解できるけど、
そのうちに、Element = Elem(
Re:Java++ (スコア:1, おもしろおかしい)
> はっきり言って、眠い頭でも理解できるコードならなんでも良いですよ。
寝ぼけてるヤツはコードを触るな。
> 1.人間に記憶力を求めないで、お願い。
そのために便利なエディタがあるんです。
定義位置を参照できたり、マウスを持っていくだけで…ほら整数型だ。
> 2.自分の感覚を他人に求めないでおくれ、頼むから。(略語とか)
文化に馴染むタイミングだと思う。
strcmpに何の抵抗も無いでしょ？
# あなたがＣ
Re:Java++ (スコア:0)
> strcmpに何の抵抗も無いでしょ？
当時から今まで StringCompare のほうがベターだと思う。
あまり長い名前は好きじゃないけど、数文字を節約して読みにくくなるのは勘弁願いたいトコ。
Re:Java++ (スコア:1)
> 読みにくくなるのは勘弁願いたいトコ。
このさじ加減に、つまりわかりやすい・わかりづらいと感じる
しきい値に個人差があるんだろうね。
Javaは、必要以上に名前が冗長すぎて、わかりやすいのかもしれない
けれど逆に読みにくいと感じていました。
getElementAt()やhasMoreElement()は確かに分かりやすいけど
書くのも面倒なら、読むのもなんか読みにくい。
例えるなら、x * y と書けてほしいのに x.multiply(y) としなきゃ
いけないような感じ。わかるけど、読みにくい。
strcmp()は・・・うーん、strcmp()でいいかなー。
頻繁に使うものだし。
どちらかというと、引数のうちどっちがsrcでどっちがdestだったかを
いつも忘れてしまうので、自分には名前よりそっちのほうが問題だった。
フレームのもと？ (スコア:0)
Re:フレームのもと？ (スコア:0)
if (obj) {}
とか書いた後に、何かキーを押すと
if (obj != null) {}
に変換してくれる機能を希望。
読むときに多少ゴチャついて読みにくいかもしれないけど、慣れれば平気。
Re:フレームのもと？ (スコア:0)
> if (obj) {} と書けて欲しいのに if (obj != null) {} としなきゃいけない。
逆に、整数型や参照型からboolean型への暗黙の型変換を
行なわないおかげで、Javaでは if (count = 3) {} なんて凡ミスが
コンパイルエラーになってくれるんですよね。
どちらの挙動がいいかは結局
Re:フレームのもと？ (スコア:0)
＞行なわないおかげで、Javaでは if (count = 3) {} なんて凡ミスが
＞コンパイルエラーになってくれるんですよね。
C(++)でもWarning出るってば。
if (count=hoge()) {} ってJavaではどうなんですか？
＞それに、この程度
Re:フレームのもと？ (スコア:0)
代入の問題もそうだし、関数の返り値が「0あるいはNULLが異常値でそれ以外が正常結果」という意味に統一されているかというとそんなことはぜんぜんないし、そういう統一が無いんだったら、プログラマとしてはifが0やNULLを特別扱されることの意義は「!=0」「!=null」を記述上省略できることでしかない。要するに慣れの問題でしかない。確かにCプログラマはこのような問題を慣れと工夫と習熟で補ってきました。「C言語はプロ向けの言語だから..」とい
Re:フレームのもと？ (スコア:0)
曖昧なコードをコンパイル時に排除する事によって安定性を
高めるのがｊａｖａのいいところだと思います。
Exceptionが発生する可能性のある関数はトラップしなきゃならない
とか最高です。
Ｃ／Ｃ＋＋でちゃんとかける人はいいのですが、ほ
Re:フレームのもと？ (スコア:0)
ううむ、自分が慣れている書き方が書きやすいのは判る。
Re:フレームのもと？ (スコア:1)
>ifの条件をbooleanに縛る
まったくです。少なくともこの点は、(Cと比べて)Javaは良いと言い切れる。
Re:フレームのもと？ (スコア:0)
そうやって書かれたコードは俺様専用コードと呼ばれます。
# 書くときのことだけを考えてる人にはそろそろ引退してもらいたいですなぁ。