アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
太陽超小型装置 (スコア:1)
サーバーサイドだと結構メジャーになってきたようだし
Re:太陽超小型装置 (スコア:2, 興味深い)
捺印ナビリティって奴ですかね。
JavaServletのコンテナ(の繁雑さと、たとえばRubyのWEBrick[*]の簡単さとの、あまりにも凄い格差)とか、
EJBとか、を思うと、やっぱり「Javaはウンコ」だと思うんですが、
それでも使いたいと思う人…ってゆーか企業…は多いんでしょうね。
[*]
WEBrickをJavaに移植するといいんじゃないかな。
その簡単さの全てが移植できるとは(言語の構造の違いから)言えないけど、
部分的には出来るんじゃないのかな。
コンテナじゃなく単なるライブラリにしちゃうのが味噌ね。設定ファイル捨て捨て。WEBrickにはmountメソッドとかが有るのが素晴ら
Re:太陽超小型装置 (スコア:2, 興味深い)
とまれJavaとはどこにも書いていなかったので言語の宗教戦争をしてもしょうがありませんが、EnterpriseといえばCobolでしょう。(笑
Enterpriseの世界は決してWebアプリだけではありません。WEBrickがいくら素晴らしくてもP言語でバッチを書く気にはあまりなれないと思います。
バッチで一番必要なのはトランザクションや、2フェーズコミットや、何より実行速度だったりします。
これをCobol以外でかろうじてまともに実行できるのはJavaだけではないでしょうか。
P言語をはじめとする生産性の高い、スクリプト言語はリアルなビジネスの世界でのシビアさを知らないと思います。
J2EEやEJBの得意なのはむしろそっち方面ですし、実行速度はJITが一番進んでいる「インタプリタ言語」はJavaで間違いないでしょう。
以上、Javaが使いたくて使いたくてしかたがないのに、まわりは口を開くとCobolという世界の住人でした。
おしまい。
Re:太陽超小型装置 (スコア:1)
いや、バッチもP(俺ならばRubyだがそれはさておき)ってゆーかLLで書きたいですね。
だってWEBrickがイイ理由の一つは、つまり言語がイイからであろうから。
他の人も言っているように、メモリ管理とか、文字列処理(でmappingを簡潔に書く)とか、
そういうところがPは強いわけです。
そして、それってつまり「プログラムの肝」の部分なんですよね。
WebだろうがバッチだろうがGUIだろうがあまり変わらない、肝。
そこを簡潔に書けるんだから偉いわけで。
>バッチで一番必要なのはトランザクションや、2フェーズコミットや、何より実行速度だったりします。
速度は「ボトルネックはそこじゃないだろ」で話は終りでしょうし、
それ以外の点も含めて、それらは言語そのもの(で書かれたアプリ)というよりは
「ライブラリの仕事」じゃないですか?
たとえばDBなら、その言語環境用に、どれくらいの品質の*DBCドライバが有るかとか、そういうレベルの話。
そして、Java環境(言語じゃなく)に既に良質なドライバが有るから
それのご利益を受けたいなあというならば、
べつに「言語は」Javaである必要はなく、JVMで動く無数のP系言語のうちから
使えそうなのを選べばいいんですよ。
#Pnutsがどれくらい速いのかは結局よく理解してないのでG7。ごめんなさい…>作者氏
ところでトランザクションで思い出しましたが、
try{
something.open
something.hoge
}finally{
something.close
}
などと書かないとならない言語(Javaも)は不幸ですね。
(アプリ側の)finally節でcloseを書き忘れたらアウトなわけですから。
毎回毎回こんなコーディングしてたら手がフヤケちゃいます。
じゃあコンテナかまして、openとcloseはコンテナでやらせろってのが
よくありがちなJava陣営の作戦だったわけですが、
一部の言語はそんなしち面倒くさいコンテナなど無くても、
something.open{
something.hoge
}
みたいなコードでcloseを保証できるんで、いわゆる閉じ忘れが無い。
つまり、こう書けないがためにコンテナなんて面倒なものが必要になっちゃった、
という側面がJavaには有るわけでして、なんてゆーか本末転倒?
#Blockを使いこなせるようになったら世界が変わったのでG7。
>以上、Javaが使いたくて使いたくてしかたがないのに、まわりは口を開くとCobolという世界の住人でした。
LLを却下され、(代用品としての)Javaも却下され、仕方ないんでCで書いていますが、何か?(T_T)
Re:太陽超小型装置 (スコア:0)
>いや、バッチもP(俺ならばRubyだがそれはさておき)ってゆーかLLで書きたいですね。
書きたいのは私も同じです。(笑
私はJava「ですら」使わせてもらえない現状を書きたかっただけでした。
>速度は「ボトルネックはそこじゃないだろ」で話は終りでしょうし、
残念ながらそうも行きません。
大型のプロジェクトでは管理・運用が最優先されますので複数の言語を利用することは好まれません。
故にボトルネックに耐えられない言語は許されないのです。
残念ながら。
Javaは決して遅くありません。
ただし、JVMはメーカにより性能が異なります。
これが話をややこし
Re:太陽超小型装置 (スコア:1)
「ボトルネックはそこじゃないだろ」に対する答えには
あんまり、なってないようですが…?
>Javaが遅いという人間は裏に意図があるので注意しましょう。
意図かどうかはさておき、起動が遅いというのが印象です。
「バッチ」とのことですが、もしかして
使うたびにProcessを起動するタイプの作りのソフトだと、
起動の遅さが致命傷になりそう。
>Javaの異なるオブジェクトのclose文が全てcloseしなければいけないということはないのですが、
意味がよく判りませんが、
Connection#closeをすれば配下のStatementが全滅する、
Statement#closeをすれば配下のResultSetが全滅する、
というあれの仕組みの話ですか?
いずれにせよ、リソースの返却(広い意味で)のタイミングは、
明示的な宣言(かそれをラップした何か)が無いと
返却しようがないのではないか、と思うんですが、
その話じゃないのですか?
>現場では使用が難しいです。
現場といっても場所次第でしょうね。色々あるわけですから。
速度がRubyで足りる場ならRubyでOKなわけで。
>Rubyは現在実行速度が他言語に比べ遅く
そういやSqueakみたいに、該当言語を必要に応じてCにコンバートする
(SqueakのVMはそうやって"Squeak言語で"書かれてる)とかいう手は
どうなんでしょうね。
>そういう世界ではUNIXですら嫌われます。
そういう世界なら、Cかアセンブラで書いててくれ、としか言いようがないですよね。
>C言語にも名前空間を付けてくれたらどれだけ嬉しいだろうと思います。
長い名前で、一応は同じことが出来るはずですので、
(そして、他にこれといった手段がCには無いので)
長い名前をつけまくるしかないでしょうね。
で、そうすると邪魔になるのが、
実はソースのコーディング規約としての「1行の文字数」だったりしますね(^^;
80桁とか言うな!!長い名前が入らなくなるじゃないか!!(わら
Re:太陽超小型装置 (スコア:0)
> 何より実行速度だったりします。これをCobol以外でかろうじてまともに
> 実行できるのはJavaだけではないでしょうか。
トランザクションや 2フェーズコミットなんて DB にまかせるもんじゃ
ないの? COBOL って COBOL がその辺面倒見るの?
実行速度については Java だってどうかと思うけどねぇ。
COBOL は知らないけど、Pro*C と Java と Perl でバッチ組んだ経験にからすると、
perl でバッチ処理を行うメリットは以下の通り。
- 当然トランザクションなんて DB まかせ
- CSV→DB