アカウント名:
パスワード:
JavaServletのコンテナ(の繁雑さと、たとえばRubyの WEBrick[*]の簡単さとの、あまりにも凄い格差)とか、 EJBとか、を思うと、やっぱり「Javaはウンコ」だと思うんですが、 それでも使いたいと思う人…ってゆーか企業…は多いんでしょうね。
P言語しか使えない人が、「大規模案件だからJava」と何も考えずに 導入すれば火を噴いて当然。 P言語開発者の中には、プログラミングのイロハも知らないままに ただ使っているだけの人も少なからずいるから。そう言う人は 言語に関係なく大規模案件をやれば火を噴いても不思議じゃない。
火をふくプロジェクトは、言語で起きてるんじゃない、 構成要員で起きてるんだ！！
Javaだからこそ、問題の有る要員が集まりやすいって事は無いでしょうか。 2,3年前、IT業の人気が高まってプログラマー入門者が溢れた頃、丁度サーバサイドJavaブームが重なって「Javaプログラマー」を詐称する人が大量生産されました（今考えると恐
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
身近な人の偉大さは半減する -- あるアレゲ人
太陽超小型装置 (スコア:1)
サーバーサイドだと結構メジャーになってきたようだし
Re:太陽超小型装置 (スコア:2, 興味深い)
捺印ナビリティって奴ですかね。
JavaServletのコンテナ(の繁雑さと、たとえばRubyのWEBrick[*]の簡単さとの、あまりにも凄い格差)とか、
EJBとか、を思うと、やっぱり「Javaはウンコ」だと思うんですが、
それでも使いたいと思う人…ってゆーか企業…は多いんでしょうね。
[*]
WEBrickをJavaに移植するといいんじゃないかな。
その簡単さの全てが移植できるとは(言語の構造の違いから)言えないけど、
部分的には出来るんじゃないのかな。
コンテナじゃなく単なるライブラリにしちゃうのが味噌ね。設定ファイル捨て捨て。WEBrickにはmountメソッドとかが有るのが素晴らしいわけよ。
んでさ、SeasarあたりがS2Servletとか作ればいいのよ(わら)。Servlet機能自体を完全にDIの配下に置いちゃえ。
あっそうか。逆にいえば、穴を埋めたのがJavaだったとすると、
その使われ方がいわゆる「軽量Java」系なのかどうか、ってのも
調べたらえぇのんちゃうかな。
＃まさか、Harmonyは、まだ関係あるまい…
＞P言語離れの主要因の1つとして，企業向けシステムで利用できないことが挙げられる」（同氏）
「利用できない」といっても技術的理由は少ないでしょうね。政治的な奴が多そう。
ただまあ(この記事は)、
＞64ビット
を匂わせていて、「まだメジャーじゃない環境」でのテストがOpenSourceだと甘くなりやすい、
ってな話も含めたいんだろうけど。
Re:太陽超小型装置 (スコア:2, 興味深い)
起こりそうなことを想像してみると、
- 今まで Perl/Python/Ruby で取り組んできた小さなプロジェクトが
- 上司から、隣で火を噴いている大きなプロジェクトを助けに行くよう指示された。
- 行ってみるとそこは J2EE, C#, C++, etc. で七転八倒していた。
- 仕方がないから軽量コンテナとユニットテストのことを調べ始めた。
みたいなケースがあるんじゃないか?成功裡に完了した。あるいは、山場を越えた。
ある意味、Java がウンコだからより多くの開発者を必要としている、とか。
Re:太陽超小型装置 (スコア:1, 興味深い)
逆にP言語使って火を噴いてるところは見たこと無い。
じゃ、みんなP言語使えばいいっていう理屈じゃなくて、
でかいとこってJavaに過度の期待してるんじゃないの？って感じ。
Re:太陽超小型装置 (スコア:1, 興味深い)
えええーー。
いたるところで、火吹いてるPHP案件見ますよ。
# Pythonは、そもそも実プロダクトで見たことがない。
Re:太陽超小型装置 (スコア:1, 興味深い)
# ちがうのか
Re:太陽超小型装置 (スコア:0)
いいこと何もないけど。
# スクリプトエンジンが欲しかっただけだから正直何でもよかった。
Plthonを使ったプロダクト (スコア:0)
Re:太陽超小型装置 (スコア:0)
Re:太陽超小型装置 (スコア:0)
Servletを生で使うのは極々一部ですよ。
Ruby開発者のうちでRubyVMを触っている人のようなもので。
>たとえばRubyのWEBrick[*]の簡単さとの、あまりにも凄い格差)とか、
＃あまり言いたくはないけど、Rubyとでは流石に処理速度が桁違いなのでは。
>EJBとか、を思うと、やっぱり「Javaはウンコ」だと思うんですが、
EJBはJavaの世界でもあまり好まれてはいません。(キッパリ。)
>私が見たでかい火事場はどこもJavaとストラッツ（とオラ）ですね。
>逆にP言語使って火を噴いてるところは見たこと無い。
>じゃ、みんなP言
Re:太陽超小型装置 (スコア:1)
一説によれば Java は営業的に有利だそうだから、Java の方が
下手くそなプログラマの発生率・生存率ともに高くても不思議ではない。
その現象をP言語と結びつけるのは、八つ当たりというものである。
Re:太陽超小型装置 (スコア:1)
>Servletを生で使うのは極々一部ですよ。
Servlet環境の設定とかまで含めて、その繁雑さは結局
全員(開発屋や設定屋)にのしかかりますね。
いやほんと、違いますよ。うん。
P系の中でも出来の良い言語ならば、
良い意味で「設定とコードを同じ言語で書ける」ので
コード(と設定ファイル)から変な冗長さが排除され、
おかげで書くだけじゃなく読むのも楽ですよ。
読むのも楽ってことは、ひいてはメンテしやすいってことで。
例に出したWEBrickの良さは、半分はそれ自体の作りの素性が良いのもありますが、
残り半分は、そういう「設定(のための大げさな仕組み)が不要」ってところに
味噌が有るように思います。
ああいう世界を見ちゃうと、XMLみたいなカッタルいもので設定を記述するシステム
(ServletにせよStrutsにせよ…)が馬鹿らしく思えてきます。
余談：
「火を噴かない言語」と「初心者にプログラミングを教えるのに向いた(良質な)言語」とは
結局は同じようなものに行きつくんじゃないだろうか？
ひねくれた言語や元々設計の悪い言語は、初心者にも現場にもどうせ使えない。
>＃あまり言いたくはないけど、Rubyとでは流石に処理速度が桁違いなのでは。
スピード「しか」違わないなら、
そんなもんはIntelとSunにでも喧嘩させといて
うちらは高見の見物きめこみゃいいんですよ(わら
どーせDBやHTTPやProcess切替のほうが数桁(?)遅いんだから。
>EJBはJavaの世界でもあまり好まれてはいません。(キッパリ。)
やっとこEJB(2)にも戦力外通告がなされたわけですが、
まだまだたくさん、オクラにすべきものがいっぱいありますよ、Javaには。
それにしても拡張for文。なんであんな中途半端な踏み込み方なんでしょう？
もっと洗練すりゃ良かったのにさ。
あれじゃeach(rubyでいえば)も満足に使えんぞ。
>P言語しか使えない人が、「大規模案件だからJava」と何も考えずに
>導入すれば火を噴いて当然。
んー。Pしか使えない「人」がJavaを入れるなんてこと、あるんでしょうか？
仮に俺がそれだとしたら、「またPでいくぜ」という判断しか下さないはず。
たいていの人は、そこまでアホじゃないんじゃないかな。
問題は、現場の人じゃない人(上司とか？)が
自分の部下の得手不得手を無視してJavaを選択するところにある、
ってのが主なケースだと思う。
つまり当人たちには判断させてないわけですよ。
下の人が言っているように、
そういう判断のまずさをPやP人間のせいにするのは、
やつ当たりってゆーか、まあとにかくお門違いですね。
>P言語開発者の中には、プログラミングのイロハも知らないままに
>ただ使っているだけの人も少なからずいるから。そう言う人は
>言語に関係なく大規模案件をやれば火を噴いても不思議じゃない。
はんっ。
JavaやC(を出来ると自称(*)してる人)だって似たようなもんですよ。
イロハ知らなくてもコンパイル通るソースだけなら書けるかも、
というレベルの人間なら山のように見ました。
(*)自称といっても微妙なんですよね。
たとえば外注なんかだと、本人は「HOGE言語は無理」と言ってるのに
下請け会社が無理矢理「HOGE言語が出来る」という肩書を与えて
送り出しちゃうことが有るみたい(わら)なんで。
あ。もちろん(！)HOGEとは、
顧客の要望に合わせてCだったりJavaだったりPerlだったりするわけですよ。
べつに落第コーダを裾野に山のように沢山抱えてるのは
Pの専売でもなんでもなく、 JavaだってCだって同じです。
まあ、もちろんそんな促成栽培人間を出す下請けも悪いんですが、
そういう下請けをきちんと排除しない(＆する能力も無い)元請けも
(そういう業界を作ってしまうという意味では)悪いことしてると思います。
余談：
まあScripting言語といってもピンキリですね。
VB系とかだと言語仕様がまずいんで、ソースがだらだら長くなりやすい。
Rubyとかだと結構綺麗になりますよ。
VB系で大規模(というより中規模以上？)を書くと悲惨ですが
Rubyだと十分行けます。というか綺麗さならJava以上のを幾らでも書けますから。
Re:太陽超小型装置 (スコア:1)
構成要員で起きてるんだ！！
いや、多分、七転八倒の部分は何を置き換えても、アホな人等が
一杯なら、火ふきますって。
Re:太陽超小型装置 (スコア:0)
Javaだからこそ、問題の有る要員が集まりやすいって事は無いでしょうか。
2,3年前、IT業の人気が高まってプログラマー入門者が溢れた頃、丁度サーバサイドJavaブームが重なって「Javaプログラマー」を詐称する人が大量生産されました（今考えると恐
Re:太陽超小型装置 (スコア:0)
# あ、Pだ
Re:太陽超小型装置 (スコア:0)
PHPは無視ですか！（笑）
> * 今まで Perl/Python/Ruby で取り組んできた小さなプロジェクトが
> 成功裡に完了した。あるいは、山場を越えた。
（中略）
> * 仕方がないから軽量コンテナとユニットテストのことを調べ始めた。
で、続き。
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
Re:太陽超小型装置 (スコア:1)
あと、あれは、うんこじゃなくてコーヒー豆です（笑）
Re:太陽超小型装置 (スコア:0)
Javaなんかシカのうんこ～！
Re:太陽超小型装置 (スコア:1)
でも、それほど嫌いじゃないんだけどな。
言語以外の要素で問題が起こりやすい言語だ。(違)
Re:太陽超小型装置 (スコア:0)
Re:太陽超小型装置 (スコア:1)
G7 のコメントだからって条件反射的にマイナスモデレートするのは
考え直した方がいいと思う。
Re:太陽超小型装置 (スコア:1)
それとも本文の何行目がマイナスなのか、が
さっぱり判らないんですよね。モデだと。
これは困る。
逆にいえばプラスも、どこがプラスなのかさっぱり判らないので、
ちょっと気味が悪いです。
Re:太陽超小型装置 (スコア:0)
Re:太陽超小型装置 (スコア:1)
リファクタリングをさせてくれりゃいいんですけどねえ。
単に書き換えるだけじゃなく、
Wikiなんかでありがちなようなリビジョン管理機能がついていれば、
(Oliver氏も憂えているような)「消す」ことのデメリットは無くなるわけですし。
それに、プログラムじゃないんですから(^^;、
短い文ばかりがシックリくるとは限りません。
縮めたり分割したりすればいい、ってもの(とは限ら)ないと思います。