アカウント名:
パスワード:
言語仕様の肥大化よりも、関連技術の肥大化のほうが問題ではないか。
それって、他の言語だと避けられるの？ 単に対応してないってだけか、対応してても、標準化されてなくてAPIが乱立してるか、あるいは、単に存在を知らないだけでは。
> もしかしたら、変数名もやたら長い名前を使いたがるタイプの方ですか。 > ResultSetMetaData resultSetMetaData = resultSet.getMetaData(); > とか
変数のスコープを考慮・指摘せずに自説を展開している時点で駄目だと思われます.
よく勘違いされるみたいだけど，EJBの眼目は，Entity Beansの永続化にあるんじゃないよ．EJBは，分散オブジェクトのバスという位置づけではじめられたものだから．
つまり，眼目は分散オブジェクトのほうで，Entity Beansの永続化っていうのは，あくまで付加的な機能として考えられたってこと．だから，Entity Beansの永続化の部分についての議論を「EJB」についての議論にしないでほしい．
永続化の機能と、分散オブジェクトでのみ必要な機能とを、分けることは難しいのかな。
>例えるなら、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)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
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のほうがずっと素直で使いやすかったな。
> 長いからいいんじゃない。読んだだけで何かわかる。
> その良さがわからない君は使えないプログラマだと断言できる。
これはちょっと反論するかな。
例えばtoString()がstr()になったら、そんなに難しい？
getElementAt()がat()になったら、理解できなくなる？
Javaでも、EnumerationのhasMoreElement()やnextElement()が
IteratorではhasNext()やnext()のように短くなったじゃない。
このくらいの長さだったら特に不満はない。
そんなにおかしな要望だとは思わないけどね。
みんな、うざったくないのかなー。
もしかしたら、変数名もやたら長い名前を使いたがるタイプの方ですか。
ResultSetMetaData resultSetMetaData = resultSet.getMetaData();
とか。
ぜひあなたの意見をきかせてね。
Re:Java++ (スコア:1)
> もしかしたら、変数名もやたら長い名前を使いたがるタイプの方ですか。
> ResultSetMetaData resultSetMetaData = resultSet.getMetaData();
> とか
変数のスコープを考慮・指摘せずに自説を展開している時点で駄目だと思われます.
Re:Java++ (スコア:1)
よく勘違いされるみたいだけど，EJBの眼目は，Entity Beansの永続化にあるんじゃないよ．EJBは，分散オブジェクトのバスという位置づけではじめられたものだから．
つまり，眼目は分散オブジェクトのほうで，Entity Beansの永続化っていうのは，あくまで付加的な機能として考えられたってこと．だから，Entity Beansの永続化の部分についての議論を「EJB」についての議論にしないでほしい．
Re:Java++ (スコア:1)
> EJBは，分散オブジェクトのバスという位置づけではじめられたものだから．
そうなんだ。知らなかった。ありがとう。
でも分散オブジェクトの「バス」っていうのは何？
プロトコルというぐらいの意味あいでしょうか。いや知らないもので。
簡単でいいので、教えていただけるとありがたい。
> つまり，眼目は分散オブジェクトのほうで，Entity Beansの永続化っていうのは，
> あくまで付加的な機能として考えられたってこと．だから，Entity Beansの永続化の
> 部分についての議論を「EJB」についての議論にしないでほしい．
なるほどね。
あれ、でも分散オブジェクトで必要なのは永続化ではなく直列化のほうでは？
永続化は、直接には関係しないと思うけど。
永続化の機能と、分散オブジェクトでのみ必要な機能とを、分けることは難しいのかな。
Re:Java++ (スコア:0)
SessionBean と EntityBeanで分けているのでは
Re:Java++ (スコア:1)
むしろシリアライズとRMIをそれぞれ使うというのは私の頭が単純すぎ？
EntityBeanもBMPでやるかぎり、まったく分かれているというか土木作業に近くて、J2EEで永続化と分散オブジェクトが一体化されている、という気分から程遠いところに連れて行ってくれましょう。
Re:Java++ (スコア:1)
>オブジェクト指向DBのほうがずっと素直で使いやすかったな。
まあそりゃそうですね。O-Rマッピングという概念が元々、
無駄か無理かのどっちかを抱え込まないと実装できない(笑)ようなもんなので、
最初からOODBのほうが良いに決まってます。
そういやJDO( http://java.sun.com/products/jdbc/related.html#what_is )って
どうしたんでしょうね？？
>getElementAt()がat()になったら、理解できなくなる？
Smalltalkのキーワードメッセージ方式なんかどうかな？と時折思います。
「慣れていないので」面食らいますが、良いアイデアだとは思います。
array at: 2 put: 1.
みたいな感じ。
ここで関数(Method)名が「at:put:」(だったっけ?)、つまり
「関数名の後ろだけじゃなく真ん中にも引数が来る」ってのが味噌でして、
長い名前を、意味的に切ってよさそうな個所で旨く分断できますんで、おいしいかと。
蛇足：
日本語向けに「後置キーワードメッセージ」を使おう！(笑)
キーワードメッセージは、日本語の「助詞」の概念と、似てるところがあると思うので、
G7 は、 九州 で、 ラーメン を食べる。
(ここでの関数名は「？は？で？を食べる」です)
なんてな文法の言語が作れると思うんだなー(^^;;;
>Javaでも、EnumerationのhasMoreElement()やnextElement()が
>IteratorではhasNext()やnext()のように短くなったじゃない。
あれは、Elementという単語をあの場面(どうせ対象はElementに決まっている)で使うのは冗長でしかない、
ということに彼らが遅まきながら気付いたから、でしょうね(^^;
冗長でしかないものは捨てられます。
問題は冗長とは言い切れないものをどうするかでして…
つまり、単なる長さの問題じゃないんですよね。
「余計なもの(スラド本家のもともとの意味のほう：つまりガイシュツ)」
であるかどうか？が問題なのでして。
>ResultSetMetaData resultSetMetaData = resultSet.getMetaData();
状況(そのコード)しだいで、変数名に織り込まれた単語のうちの幾つかが、
冗長と見なすことが出来て削除可能になる、でしょうね。
＃その「幾つか」が不幸にして0である可能性も否定しないっす。周囲のコード次第だなあ。
というか、型名そのまんまの変数名って、どうなんだろう？
Re:Java++ (スコア:1)
＞(ここでの関数名は「？は？で？を食べる」です)
＞なんてな文法の言語が作れると思うんだなー(^^;;;
ご存知かもしれませんが、
FORTHはいかがですか？日本語で書くならMind [scripts-lab.co.jp]というFORTH系言語があります。
masamic
Re:Java++ (スコア:1)
オブジェクト指向FORTH(とかMind)なんか考えると、ちょっと面白そうですね。
内実は、スタック型言語とは呼べない、ヒープだらけの代物になりそうですけど。
趣味の言語設計には向いているテーマかも。
(もう既にやっている人が、大勢いそうですね)
Re:Java++ (スコア:1)
関数名（メソッドセレクタ）の途中途中に引数を突っ込んだもの [kurumi.jp]。
>オブジェクト指向FORTH(とかMind)なんか考えると、ちょっと面白そうですね。
>内実は、スタック型言語とは呼べない、ヒープだらけの代物になりそうですけど。
あう。すんません。俺脳(と俺にご指導くださったかたがた)には既出でして…
ばぶばぶ [nifty.com]はモロにそれです。
というかForthというよりPostScript(のOOP拡張)でして、
この頁から何段かLink手繰って行くといずれ行き当たる何処かの頁(ぉぃ)に
書かれているように、もともとPostScriptが結構ヒープだらけ言語であるようです。
Stackに積むのはデータの参照(ポインタ)であることが多いそうなので。
もちろんばぶばぶもそう実装してあります。
＃てーか、ポインタ(参照)しかない言語のほうが、埋め込みを扱う言語より、作るのも楽なような気がします(笑)
＃メモリ管理はとりあえずGC(CならBoehmを使うってことで)に任せて左団扇。
PostScriptって、Stack言語の強い部分と、高級言語的お洒落さ(一応Lisp並？の記述力)とを、
ある程度兼ね備えた結構美味しい言語だと思います。
尤も実際には後置な書き方になかなか慣れられなくて、自ら放置プレイ状態ですが(藁
＃Local変数みたいな概念も、辞書管理Objectをnewして、それ(のポインタ)を辞書Stackに積むことで実現します。
＃おかげでScopeの入れ子も自力で管理する羽目になる(笑)。
まあ万一お暇だったら、Linkしてるあちこち(他のサイトも含め)を眺めて笑ってやってください(^^;
>Mind
後置キーワードメッセージ [infoseek.co.jp]って考えたのは…何年前だったかな…
ここに書いてあるように、後置キーワードメッセージは、Mindのやりかたの改良というか、
Mind的日本語路線とSmalltalk的キーワードメッセージ路線とを融合させたらどうかなって話でして、
前述のように「助詞」という観点から融合を図るといいんじゃないかと思ったわけです。
＃というわけで、Parseについて何も考えなくて済んだForth/PostScript系と違って、今度は
＃yaccとかを回避(笑)するのはキツイだろうなと思ってるところです。
＃racc(rubyなら)やSableCC [tripod.co.jp](Javaなら)を覚えないとなあ…
＃え？C？もういやですぅ(ぉ
>趣味の言語設計
ええ。趣味です。
ばぶばぶくらいならまだ良い(PostScriptほぼそのまんまだもんな)んですが、
最近考えてる言語仕様(とその下で動くObjectアーキテクチャ)は、ぜってー速度出ないぞって代物でして(^^;
なんせLocal変数どころか関数呼び出し引数までHashでやり取りしようなんて思ってるんですから…
＃引数は順序じゃなく名前で渡します。
Re:Java++ (スコア:0)
EJBが筋が良くないなら代替手段をがんばって作るか、時間がないなら見つければいい。
それが駄目なら恨みつつ使う他はない。
さらに言えば､ある関連技術の筋が悪いどうのってのは、>>他の言語だと避けられるの？
もっと言うと、プログラマさんごのみに筋を良くしたらしたで具合悪い人もいると思う。
>toString()がstr()に
できるなら、略すのはやめてください、略すのは。
String = str なのは習慣的に理解できるけど、
そのうちに、Element = Elem(
Re:Java++ (スコア:1, おもしろおかしい)
> はっきり言って、眠い頭でも理解できるコードならなんでも良いですよ。
寝ぼけてるヤツはコードを触るな。
> 1.人間に記憶力を求めないで、お願い。
そのために便利なエディタがあるんです。
定義位置を参照できたり、マウスを持っていくだけで…ほら整数型だ。
> 2.自分の感覚を他人に求めないでおくれ、頼むから。(略語とか)
文化に馴染むタイミングだと思う。
strcmpに何の抵抗も無いでしょ？
# あなたがＣユーザであることを願う
> 3.絶対良いと言う確証もなしに非標準な技を使わないでよ、ほんと。
文章どおりなら納得。でも、確証無しに技を使う？
> 4.後からコードを読む人を思いやって下さいね。
i++; // 変数ｉに１を加える。引くんじゃないの。前置・後置は気にしないこと。
# 注：ネタです
Re:Java++ (スコア:0)
優しいなぁw
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)
そうやって書かれたコードは俺様専用コードと呼ばれます。
# 書くときのことだけを考えてる人にはそろそろ引退してもらいたいですなぁ。