アカウント名:
パスワード:
言語仕様の肥大化よりも、関連技術の肥大化のほうが問題ではないか。
それって、他の言語だと避けられるの？ 単に対応してないってだけか、対応してても、標準化されてなくてAPIが乱立してるか、あるいは、単に存在を知らないだけでは。
より多くのコメントがこの議論にあるかもしれませんが、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++ (スコア: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でやり取りしようなんて思ってるんですから…
＃引数は順序じゃなく名前で渡します。