よく考えてください。C言語ができてもうすぐ30年です。 未だに「CUIとGUI、X11用とWindows用とMac用のコードが単一コードから生成できるライブラリセット」はできていません。C言語はもともと Human Interface については何の仮定も置いていないプログラミング言語なのに、ですよ?と言うことは、そもそも「UIを書く」ための「単一インターフェース(言語であれ、ライブラリであれ)」はまだないってことです。
つまり、ソースコードはなく、アセンブラで追い回したら for 文みたいな構文の中に nop が入ってる…なんてのがゴロゴロしているコードこそが曲者。なにしろ、エミュレーターや仮想マシンをもってしても、「マシン語1命令単位」での実行時間をオリジナルとぴったり合わせることはできない。CPUが早すぎたり、逆にエミュレーターが遅すぎたりする。
Javaの優位性ってなに? (スコア:3, おもしろおかしい)
ところで、Javaの優位性って何でしょう?
どんなに工夫しても所詮はインタプリタだから遅いし、
どこでも動く的な話は夢であることははっきりしてきたし、、、
WEBシステムで表示はIEへ、DBはOracleへ丸投げとか、Android上ではそれなりかもしれないが、それなら他の言語に比べて良いこと無いし。
特に実務で使う場合はコーディングルールとかの蓄積が無いからむちゃくちゃになるし、訳の判らない争いごとが多いし。
#それに比べればCOBOLって最高だよね。仕事で使うなら。
Re: (スコア:1)
古典的すぎるネタですが。
「インタープリター言語」を利用する最大の理由は「速度よりも言語的柔軟性」を優先したい場合です。なので、「遅い」事が問題になるような場合には使わない。
「どこでも動く」が嘘であっても、「WindowsでもLinuxでもMacでもそれなりに動いて欲しい」とか「HP/UXとLinuxとSolarisとAIXでそこそこ動いて欲しい」とかいうニーズに対してなら、シングルバイナリ配布で済む分、Native Binary出力よりも優位。
それは Java の問題ではなく
fjの教祖様
Re: (スコア:0)
> 「速度よりも言語的柔軟性」を優先したい場合です。
javaにそれが当てはまりますか? 例えばC++と比べてどこがインタープリタとして優れいているの?
> 「どこでも動く」が嘘であっても
ここは同意ね。
> 「WindowsでもLinuxでもMacでもそれなりに動いて欲しい」とか「HP/UXとLinuxとSolarisとAIXでそこそこ動いて欲しい」とかいうニーズに対してなら、シングルバイナリ配布で済む分、Native Binary出力よりも優位。
その意見はある程度同意します。それなりやそこそこで動く分には。
実際、単体試験は各作業員のWindowsPCで実行はUNIXサーバーという形式は良くやる。
Re:Javaの優位性ってなに? (スコア:1)
どうやらここから突っ込む必要がありそうですね。
よく考えてください。C言語ができてもうすぐ30年です。
未だに「CUIとGUI、X11用とWindows用とMac用のコードが単一コードから生成できるライブラリセット」はできていません。C言語はもともと Human Interface については何の仮定も置いていないプログラミング言語なのに、ですよ?と言うことは、そもそも「UIを書く」ための「単一インターフェース(言語であれ、ライブラリであれ)」はまだないってことです。
当然、存在しない概念を実装した処理系は存在しえません。
だから、シングルバイナリ配布で可能なのは「マシン・マシン・インターフェース」が決まっている(あるいは、unixのようにヒューマンインターフェース側が限りなくマシン・インターフェースに等しく、かつ テキストのような汎用化された通信ベースに基づいている)場合に限定されるわけです。
なので、シングルバイナリ配布の恩恵を受けられるのはHuman Interfaceを大量に必要とする「対人間用」コードではなく、その一歩手前まで…つまりサーバー側からスタートして、クライアントにおけるバックグラウンド処理まで…に限られます。最後のUIの部分は、絶対個々のOSごとに native でつくるしかないんです。
これはどのような言語であっても共通して言えること。C for JVM があっても何も変わりません。
うん。それはつまり「ソースコードがある」「ソースコードがきちんとしている」って言うことだよね。
たとえば「所定の時間待つ」ために for文+nop で構成されたりしていないってわけだ。
また、「ソースコードが無くなっていない」ってわけだ。
実際には、基盤間移植の本当に大変な部分は、ソースは残っていないし、中身は腐っているんだよ
つまり、ソースコードはなく、アセンブラで追い回したら for 文みたいな構文の中に nop が入ってる…なんてのがゴロゴロしているコードこそが曲者。なにしろ、エミュレーターや仮想マシンをもってしても、「マシン語1命令単位」での実行時間をオリジナルとぴったり合わせることはできない。CPUが早すぎたり、逆にエミュレーターが遅すぎたりする。
しかし、最適化が中途半端にかかっているものだから、デコンパイルが効かない。まさに問題のポイントの周辺が解析不能に陥る。「意味論的に理解できるパターン」が書かれているからこそ、デコンパイラーのデザイナーがパターンを登録できるのであって。「意味不明なコード」をコンパイルしてできた結果は、デコンパイルできない。
捨てて作りなおそうにも何やってんだかよく分からなさすぎる上に、コストだけは大量にかかった、スケジュールのスリップしまくったプログラムなので、まだ元が取れてない。だから捨てられない(と泣きついてくることが多い)。
しかし Java は違う。Javac は最適化をほとんどかけないので、デコンパイルし易い。JVM上で動くので最初から 「for文+nopでタイミング調整」なんてできない。
つまり「Javaで書いておくと基盤間移植しやすい」のだ。
当てはまります。が、多分それは想像している答と違うでしょう。
まず、Javaはコンパイラ言語です。C++やPascalとかと同じです。なので、C++に比べてJavaが「言語的に」何か優れている、と言うことはありません。いや、オブジェクト指向言語としてよりシンプルである、とかそういうのはあるでしょうが、「インタープリターであるための言語柔軟性」…例えば eval が実行できるとか…は Java そのものにはありません。
なので、「インタープリターとしての柔軟性」は全て JVM 用バイトコード処理系側に存在します。別の言い方をすれば、「JVMがCorei7に比べて何が優れているのか」という比較になります。で、すぐ判るでしょうが、この比較であれば「JVMは物理プラットフォームに対する縛りが緩い」事と「Garbage Collector を持っている」の2点が柔軟性としてあげられます。物理CPUに対する縛りを緩める、というのは「インタープリターとしてのJava」の特徴の一つですから、当然勘定してあげなくちゃ不公平、というものです。
GCはサーバー用/デーモン系プログラムにおける福音です。少なくともこれが福音になるような人たちですら、基本的に停止させないプログラムを書いて、メモリリークの心配をしなくて良い、という段階で福音です(JVM自身のバグのせいで酷いメモリリークを起こすことがあるのは、脇に置いておくとして)。
Javaは「馬鹿でも安全にコードが書ける」プラットフォームとして、C++に比べて言語的柔軟性が優れているのです。
# ポインタ操作の山をかいくぐって「完璧なGC」を行うのは難しい。
# だから、C++用にはBoehm GCのような保守的GCしか実装できない。と言うことは、
# メモリリークを起こすし、無限に動き続ける daemon を書く上で、C++では十分な保護は
# 受けられないわけだ。
うむ、影響範囲が狭すぎる。
考えてみて欲しい。Cの場合「歴史があるので書き方がより定まっている」というのは「私の配下では統制できている」程度の人しかいなかったなら、おかしいと思わないか?
もし、非常に狭い部隊内部だけの統制が取れればいいのであれば、マネージャーで十分だ。別に強圧的な方法なんぞ使わなくてもよい。しかし、それでは世間の常識になんかならない。
「書き方が定まっている」のは歴史があるからじゃない。組織外部に向かってでも、「こういう場合はこう言うふうに書くものであるっ!!」と宣言し、押し付けた人がいたからこそ書き方が定まっているのだ。プログラマーとしての実力が不足しすぎていて、他者を圧倒できていないとはそういうことだよ。
小さな自分の配下ごときで「できている」なんぞとは言わない。
自分の部署と取引がある部隊が同じルールに従うのでは、世界が狭すぎる。
もっともっと、でかい世界を「平伏できていない」のならば 実力不足 か、影響が十分世間に回っていないか…どちらかだ。そして「マネージャじゃなくて?」と聞いたということは、これは実力不足の方であると確定した、と言うことだ。
# 「それ、俺の仕事と違う」と宣言したに等しいからね。
fjの教祖様
こういうことですか? (スコア:2)
インタプリタ言語最強
今のCPUの設計に依存した下手な最適化バイナリコードよりも
人間が読めて理解できてある程度ちゃんと動くコードの方がいいよね
誤記 FireFox
巫女 Firefox [mozdev.org]
Re:こういうことですか? (スコア:1)
別に最強なわけじゃない。
ちゃんとコードが書ける人が、丁寧に作り上げたプログラムのメンテナンスのしやすさや動作の最適さは言語に依存しない。
というか、へたくそが書いた Java コードより、優秀な人が書いたアセンブラの方が読みやすい。
でも、プログラマのレベルを下げていくと、言語による縛りや言語によるサポートによる差が見えてくる。
そして、最悪状態でどちらがより「救いようがあるか」というと、それは Java という事。
「必要悪」の方がよほど正しい表現だな。
fjの教祖様
Re:Javaの優位性ってなに? (スコア:1)
ごめん、40年だ。
fjの教祖様
Re: (スコア:0)
> これはどのような言語であっても共通して言えること。C for JVM があっても何も変わりません。
つまりは、シングルバイナリなんて限られた条件下でしか使えないって事でしょう。
別にUIだけでなくファイルシステムや権限管理やその他多くの条件がシングルバイナリの使用を阻害しているしね。
シングルバイナリが使えるような環境ならほかの言語でもほとんどmake一発で動くし。
> Javaは「馬鹿でも安全にコードが書ける」プラットフォームとして、C++に比べて言語的柔軟性が優れているのです。
ひょっとしてギャグ?
> もっともっと、で
Re:Javaの優位性ってなに? (スコア:1)
私が書いたことが異常だというなら、「世界は異常なのだよ」。
世界をもっと見てきたまえ。
fjの教祖様
いえ、Javaはインタープリタです。 (スコア:0)