アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
よーし (スコア:2, おもしろおかしい)
オブジェクトも動的だから、稼働しながらメンテできちゃいますよ。
まさにゲーム向け?
Re:よーし (スコア:0)
Java とかでも十分動的再構成出来ますがな。C でもプロセスをうまく分けとけばいけそう。
Re:よーし (スコア:1)
志を低く持てば、Javaでも出来るぞCでも出来るぞという議論も可能ですが、
どうせならもっと気前よく行きましょう。他にも色々メリット有るんだから。
ただまあ、Lispそのものが最高の解なのかどうかは俺は何と
Re:よーし (スコア:1)
LISP、はよく分からんですが、例えば ruby や Smalltalk、これらは確かに高い動的度を持っておるでしょう。しかし、それは他のものを犠牲にして得られたものではあるまいか?
例えば ruby の thread は、(native 化しようという動きはあれど) 基本的にユーザランドスレッドであり、お手軽な反面、より高機能なハードウェア (マルチプロセッサな環境など) をうまく利用することが出来ないでしょう。Smalltalk や LISP の現存する処理系も、多かれ少なかれそういう面を抱えているのではないですか?
「普通のやつらの上を行け」、確かにおっしゃることはごもっともな面もありますが、プログラミング言語というのは、その「言語」としてのポテンシャル以外に、どのような「実装」が現存するのか、というのも重要な判断基準でありましょう。どんなに優れた言語であっても、優れた実装が提供されない限り、宝の持ち腐れではないですか?
「言語」の持つポテンシャルと、現存する「実装」のクオリティ、それらが高いレベルでバランスしているプログラミング言語こそ、「最もパワフル」と呼ばれるに相応しい言語であると、僕は思います。
で、すなわちそれは Java であると!
// …あ、石投げないで~。
ところで Java は動的度高いと思いますよ。VM 動作させたままクラス定義入れ換えられるし。インターフェイス合わせとけば新旧のクラスが混在するような環境でも問題ナシです。ポイントはクラスローダですな。
Only Jav^Hpanese available :-)
Re:よーし (スコア:1)
データの再編成を行うように自分自身のロジックをロジックで再編成できると。
…でよかったよね?>LISPのえらいひと
Javaは…早くテンプレート実装してください~
あ、あとVMのvesionがほんの少しでも変わるとがらりとガベージコレクタの挙動が
変わっちゃうのも大変かもしれない。
C++使いには「自分で解放するから手を出すなっ」と叫びたくなることもたま~にあるが(笑
でも、言語的にはおもしろいですよ。
kusanagi shin
Re:よーし (スコア:1)
今のノイマン型コンピュータではどんな言語を使おうがプログラムとデータは等価なのではあるまいか?…なんて原則論をゆってもしょうがないっすね。確かに LISP のその特徴はシンプル、かつ非常に強力な点でありますな。設定ファイルを LISP で書ける環境だと、値を設定すべきところに式が書けたりしてめちゃめちゃ便利ですよねぇ。
> Javaは…早くテンプレート実装してください~
なんでも次のバージョンでは実装される予定だそうで。僕自身は全然必要性を感じていないんですけど、Java でも便利ですかね?異なるクラスに対して同一の操作を行うような method を作りたければ、共通の親クラスを用いて多態させればいいように思うんですが、Java にはプリミティブ型、という鬼っ子もいるわけで、もっぱらこちらのために使うことになるのかしら?しかし複数のプリミティブ型に対して同一の処理を行う method を書きたい、という局面は非常に限定的な気もしますが…。
> あ、あとVMのvesionがほんの少しでも変わるとがらりとガベージコレクタの挙動が
> 変わっちゃうのも大変かもしれない。
むぅ。僕自身かなり VM をいじめてきたつもりだったんですが、この「ほんの少しでも変わるとがらり」に相当するような挙動は見たことがないです。今後の参考のためにどんな変化だったのか教えていただけたりしませんか?ダメ?
> C++使いには「自分で解放するから手を出すなっ」と叫びたくなることもたま~にあるが(笑
参照が残ってる限り GC は手を出さないと思うんですが…って、そんな基本的なことじゃない?あこりゃ失礼しました~。
Only Jav^Hpanese available :-)
Re:よーし (スコア:2, 参考になる)
> なんでも次のバージョンでは実装される予定だそうで。僕自身は全然必要性を感じていないん
> ですけど、Java でも便利ですかね?異なるクラスに対して同一の操作を行うような method を作
> りたければ、共通の親クラスを用いて多態させればいいように思うんですが、Java にはプリミティ
> ブ型、という鬼っ子もいるわけで、もっぱらこちらのために使うことになるのかしら?しかし複数
> のプリミティブ型に対して同一の処理を行う method を書きたい、という局面は非常に限定的な
> 気もしますが…。
正確にはJ2SE 1.5 から入ります。
JCP(Java の標準団体) の JSR (Javaの仕様案) では JSR 14 Generic Types [jcp.org] です。
提唱者による実装はすでに公開 [unisa.edu.au]されています。
Generic Type は主として、コレクションクラスの高速化と安全性のために導入されます。
現行のコレクションクラスが Object を基底としているため、コレクションから取り出してきた値を使用する前に narrow cast を行う必要があります。これが不要になるぶん高速化されます。
また、Object 型を基底とするコレクションクラスにはどんなオブジェクトで入れることができるという問題がありましたが、ユーザーが指定したクラス(例えば MyClass) にパラメタライズされたコレクションには、MyClass とその導出型以外のものが入りません。その分、安心して使えますし、余分なチェックが不要になります。
あと、入れ物のクラス毎にコレクションクラスが複製されるので、JIT コンパイルが効きやすくなったり、Digitune さんが挙げているようにprimitive 型のコレクションに対するナイーブな実装ができる点が有利なポイントですね。
> > あ、あとVMのvesionがほんの少しでも変わるとがらりとガベージコレクタの挙動が
> > 変わっちゃうのも大変かもしれない。
>
> むぅ。僕自身かなり VM をいじめてきたつもりだったんですが、この「ほんの少しでも変わると
> がらり」に相当するような挙動は見たことがないです。今後の参考のためにどんな変化だったの
> か教えていただけたりしませんか?ダメ?
第3者ですが。
SUN J2SE の HotSpot VM の 1.4.0 で 1.4.1 の間でボコボコに挙動が変わっている例を一つ。
できるだけ way 数の大きい SMP マシンで、-XX:+AggressiveHeap を付けた時の挙動を確かめてみてください。天地の差があると思います。
細かい違いはまだまだ色々あって、困っているのですが。。。
# 変えるなら、変えると、ちゃんと言って欲しいよ > SUN
コンタミは発見の母
Re:よーし (スコア:1)
「同一の」じゃないから厄介なんですよね。「同様の」なんです。templateなるものが欲しくなる場面ってのは。
コンテナ型がよく引き合いに出されますね。Hoge型のデータを格納するFuga型コンテナ、みたいな。
Fuga型の仕組みはHogeが何だろうとそうそう変わるわけじゃないけど、一方でFuga型は
Hoge型とそれ以外とを差別化したくて、しかもHoge型に使いたい型の候補は1つじゃないと来たもんだ、
というケースですね。「型を作る」ときに他の型(とか)で修飾(?)したくなるという状況。
そう。「型を作る」なんですよね、問題は。
Hogeに相当する型を取っかえひっかえして色々なFuga型ファミリーを作りたい、という。
で、俺としては、いいかげん面倒だから、全部動的にしちゃえ、と思っているわけです(笑)。
ただまあ、JavaのGenericの方向性は、C++みたいなドロドロしたものにはならずに済むと聞いてる
(C++のtemplateは導入によって理解が難しくなる(笑)が、GenericなJavaはむしろすんなり理解できる)
んで、まあ有っても良いかなとは思ってますし、必要に迫られりゃ俺も使うでしょうね。
>この「ほんの少しでも変わるとがらり」に相当するような挙動は見たことがないです。
出来れば(出来るだけ)、GCの「挙動」なんかに関わらずに済ませたいものです。
Re:よーし (スコア:1)
低いじゃないですか。それが証拠にrubyでいうところのmethod_missingメソッドが無い(笑)。
有るか無いか判らないメソッドを呼ぶ、ってのを、javaは普通の構文で書けないっすよね。
動的にも出来るけど、あくまでそれは特定のクラス(要するにjava.lang.refrect.*ですが)の機能を経由して
はじめて使えるものであって、普通のソースの記述と地続きにはならないでしょ。
つまり動的な要素も秘めてるけどあくまで秘めているというか、静的言語の文法で拘束してしまっている。
#method_missing使いまくりのコードをrubyからjavaに移植したが、
#えらくみっともなくしかならなかった。鬱。
>しかし、それは他のものを犠牲にして得られたものではあるまいか?
>例えば ruby の thread は、(native 化しようという動きはあれど) 基本的にユーザランドスレッドであり、
無関係です。rubyはたまたまユーザースレッドですが、別に動的言語の宿命でもなんでもなく、
OS提供のスレッドを直接使ってる言語はいっぱいあるはず。
とりあえず、Gauche(Schemeの実装。作者は日本人)をWin32に移植しようとしてる某氏の
Threadまわりも含めた奮闘記は、Gauche作者氏のWikiサイト「WiLiKi」で、ただいま好評連載中(違
つまり(?)もともとGaucheはNativeスレッド使うらしいです。
あと…あれ?Pythonってどっちでしたっけ?
勿論、スレッドに限らず広く一般にあらゆるものを失わずに済む、なんてなことは有り得ないでしょうね。
でもそれを言ったらjavaだって何かを失いながら存在しているわけですから。程度問題です。
>「普通のやつらの上を行け」、確かにおっしゃることはごもっともな面もありますが、プログラミング言語というのは、
>その「言語」としてのポテンシャル以外に、どのような「実装」が現存するのか、というのも重要な判断基準でありましょう。
>どんなに優れた言語であっても、優れた実装が提供されない限り、宝の持ち腐れではないですか?
1:「現存するか」じゃなく「現存し得るか」が重要ですね。原理的に無理(&無理でないにしても超困難)かどうかが重要。そうでないなら頑張って実装すれば済むことですから。
1.5:それどころか実在すらするわけで、そこから先は単に知識(実在を知ってるかどうかという)の問題。
2:「言語の優れた機能」が、しもじも(笑)のOSやハードのNativeなパワーを引き出すことと、イコールとは限らないでしょう。例えばNativeスレッドを使えても本物の末尾再帰を使えなければ、そのScheme実装はSchemeとして失格(=優れてない)なわけで。
>「言語」の持つポテンシャルと、現存する「実装」のクオリティ、それらが高いレベルでバランスしているプログラミング言語こそ
俺的には、Javaの静的っぷりが既に、言語のポテンシャルの低さとして重大な足枷に感じられるんで…。
なんせ最近ご執心なのはPrototypeOOPだもんな。Classすら邪魔だと感じてるところ。
>// …あ、石投げないで~。
意思(発言)は投げておくことにします(藁
>ところで Java は動的度高いと思いますよ。VM 動作させたままクラス定義入れ換えられるし。インターフェイス合わせとけば新旧
「VMは」動的度が高いかも知れませんね。俺も正しい知識はまだ仕入れてないんでよく判ってませんが、
JVM(バイトコード)を使うJava以外の言語実装(つまりその言語のコンパイラがJavaバイトコードを吐く)
は無数に有るようです。その中にはそれこそ動的言語もいっぱいありますから、
きっと動的言語を作る際にも困らないだけの仕組みは持っている(あるいは邪魔物を持っていない?)のでしょう。
で、それはJava「言語」とは別問題。むしろJava言語はJVMの機能を全て引き出していないとも言えるのかも?