アカウント名:
パスワード:
まあP言語の特徴である, お手軽に何でもできるってのだけではおっつかない案件が増えてきたんでしょうね. 1人から数人程度でできる案件と100人以上で作る案件では, 言語に求められる物が違ってきますから.
大規模開発で使う言語だと
あたりが必要だと30年以上前から言われていて, それを実現した言語の系譜がModula, Adaなどと続いてきてJavaに至っているわけです. 一方, 少人数で小規模, さらにはメンテナンスの必要もほとんど無いような用途なら, こうした言語要件はまさに鶏を裂くに牛刀を用いるの類ということでアンチテーゼとして出てきたのがP言語です. 実際, こうした用途でP言語は大成功しました.
問題は, そういう前提条件を考慮に入れず, 何でもP言語で出来ると思い込んだ, あるいは出来ないことが分かっていても他の手段を使えなかった低レベルな開発者がP言語でシステムを作りこんじゃったことでしょう. 現在はそのゆり戻しで, P言語じゃなくてもよい部分はJavaあたりで作ろうって感じになっているんでしょう.
私の個人的な好き嫌いだけで言えば, 強い型付けの無い言語って何が起きているのか把握しづらいので気持ち悪くて嫌いなんですけどね. 結果オーライでperlは使っていますけど.
違う. 高負荷・ミッションクリティカルな部分は数人でC言語を使います.
P言語が駄目なのは, あくまでも組織的な開発をサポートする強制力が弱いってことです. 大規模開発では良い物を作ることよりも, 駄目な物を作らないことが重要になります. 縛りがゆるい言語は楽に作れますが, レベルが低いプログラマはいくらでも酷いコードを吐き出してくれます. また駄目なコードであることが分かった時に, いかにきれいに切ることができるかが重要になります.
大規模開発で優れたプログラマのみを集めるなんてのは一種のファンタジーです. そこで駄目なプログラマが混入しても最悪を避けられる開発環境が求められるわけです.
P言語が駄目なのは, あくまでも組織的な開発をサポートする強制力が 弱いってことです. 大規模開発では良い物を作ることよりも, 駄目な 物を作らないことが重要になります. 縛りがゆるい言語は楽に作れま すが, レベルが低いプログラマはいくらでも酷いコードを吐き出してくれます.
「俺のC言語コードは絶対バッファオーバランを起こさない！」というのは無しですよ。 それは非科学的です。
そしてさ、これは想像なんだけど(というのは俺もそういう場に居た事が無いんで)、 良い組織は最初から駄目プログラマを排除しているんじゃなかろうか？
JavaServletのコンテナ(の繁雑さと、たとえばRubyの WEBrick[*]の簡単さとの、あまりにも凄い格差)とか、 EJBとか、を思うと、やっぱり「Javaはウンコ」だと思うんですが、 それでも使いたいと思う人…ってゆーか企業…は多いんでしょうね。
P言語しか使えない人が、「大規模案件だからJava」と何も考えずに 導入すれば火を噴いて当然。 P言語開発者の中には、プログラミングのイロハも知らないままに ただ使っているだけの人も少なからずいるから。そう言う人は 言語に関係なく大規模案件をやれば火を噴いても不思議じゃない。
火をふくプロジェクトは、言語で起きてるんじゃない、 構成要員で起きてるんだ！！
Javaだからこそ、問題の有る要員が集まりやすいって事は無いでしょうか。 2,3年前、IT業の人気が高まってプログラマー入門者が溢れた頃、丁度サーバサイドJavaブームが重なって「Javaプログラマー」を詐称する人が大量生産されました（今考えると恐
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
太陽超小型装置 (スコア:1)
サーバーサイドだと結構メジャーになってきたようだし
アーミーナイフで家を建てる (スコア:4, すばらしい洞察)
まあP言語の特徴である, お手軽に何でもできるってのだけではおっつかない案件が増えてきたんでしょうね. 1人から数人程度でできる案件と100人以上で作る案件では, 言語に求められる物が違ってきますから.
大規模開発で使う言語だと
あたりが必要だと30年以上前から言われていて, それを実現した言語の系譜がModula, Adaなどと続いてきてJavaに至っているわけです. 一方, 少人数で小規模, さらにはメンテナンスの必要もほとんど無いような用途なら, こうした言語要件はまさに鶏を裂くに牛刀を用いるの類ということでアンチテーゼとして出てきたのがP言語です. 実際, こうした用途でP言語は大成功しました.
問題は, そういう前提条件を考慮に入れず, 何でもP言語で出来ると思い込んだ, あるいは出来ないことが分かっていても他の手段を使えなかった低レベルな開発者がP言語でシステムを作りこんじゃったことでしょう. 現在はそのゆり戻しで, P言語じゃなくてもよい部分はJavaあたりで作ろうって感じになっているんでしょう.
私の個人的な好き嫌いだけで言えば, 強い型付けの無い言語って何が起きているのか把握しづらいので気持ち悪くて嫌いなんですけどね. 結果オーライでperlは使っていますけど.
Re: アーミーナイフで家を建てる (スコア:2, すばらしい洞察)
それもまた危ないな。
高負荷・クリティカルミッションなところはJavaで書いて、
そうでないところはP言語で書けばみんな幸せになれると思うけど。
それができないのは切り分けができないSEのせい？
それとも複数の言語が入り混じるとひいてしまうハンコ押す人のせい？
そういえばDBでもPostgresやMySQLが認知される前は、
「何でもOracle」っていうのがあったな。
Re: アーミーナイフで家を建てる (スコア:4, すばらしい洞察)
違う. 高負荷・ミッションクリティカルな部分は数人でC言語を使います.
P言語が駄目なのは, あくまでも組織的な開発をサポートする強制力が弱いってことです. 大規模開発では良い物を作ることよりも, 駄目な物を作らないことが重要になります. 縛りがゆるい言語は楽に作れますが, レベルが低いプログラマはいくらでも酷いコードを吐き出してくれます. また駄目なコードであることが分かった時に, いかにきれいに切ることができるかが重要になります.
大規模開発で優れたプログラマのみを集めるなんてのは一種のファンタジーです. そこで駄目なプログラマが混入しても最悪を避けられる開発環境が求められるわけです.
Re: アーミーナイフで家を建てる (スコア:1)
言語に不自由な人は、どんな言語が開発されようともなくならないのでは？
# 私はCは嫌い。高級言語のアセンブラなんていうぐらいなら、直接アセンブリへ行く。必要とあれば
Copyright (c) 2001-2014 Parsley, All rights reserved.
Re: アーミーナイフで家を建てる (スコア:1)
平気で駄目な家を建てることでしょう。 駄目なプログラマをなんとかして束縛して、駄目なコードを生産させ
ないようにしたい、そのために Java 言語を採用するというのはあり
そうな話ですが、あまり効果的とは言えません。
Java には束縛がありますが、それでも十分に駄目なコードを書くだけの
余地があります。単なる言語に、コーチの代わりは務まりません。
大規模開発で優れたプログラマのみを集めるのがファンタジーだとすれば、
そもそも大規模開発がペイするという考えもまた、ファンタジーであるかも
知れません。あるいは、ペアプログラミングがペイしないという考えに
見切りを付けるべきときかも知れません。
バッファオーバーラン (スコア:1)
確かに高負荷には耐えられると思いますが、
セキュリティの面から見ればバッファオーバーラン [e-words.jp]という別の危険性が出てきます。
バッファオーバーランの危険性と秤にかけて見合うだけの高負荷ってどんなものでしょうかね。
「俺のC言語コードは絶対バッファオーバランを起こさない！」というのは無しですよ。
それは非科学的です。
Re:バッファオーバーラン (スコア:1)
たとえば、Apache httpd にコードを提供するようなレベルの人は、
バッファオーバランもメモリリークも"絶対"起こさない所まで
行っていなければなりません。でなきゃ危なくて仕様がないですよ。
C言語なんか生産性が低いから書きたくないけれど、もし書かなければ
ならないときはメモリ関係のエラーを出さないコードが書けること。
これが、プロの入り口じゃあないでしょうか。
別件で、C言語でCGIっていうのは bad idea だと思うけれど、これについては論じません。
Re:バッファオーバーラン (スコア:0)
バックエンドで動いててボトルネックになることが確実なモジュールはC/C++で実装することはたまにあります。
＃そろそろそういうのもJavaでやってみたいんだけど、
＃いかんせん経験が少ないのでどこまで耐えられるかの見積もりが難しい。
Re: アーミーナイフで家を建てる (スコア:1)
ってことは裏返すと、
大規模プログラムだからといって、
なにか「素晴らしい」プログラムだ、と思うのは
幻想に過ぎないってことですね。
>縛りがゆるい言語は楽に作れますが, レベルが低いプログラマはいくらでも酷いコードを吐き出してくれます.
>また駄目なコードであることが分かった時に, いかにきれいに切ることができるかが重要になります.
ただ、しょせんJavaだのCだの程度の「縛り」では、
酷いコードを排除できませんし、
駄目コードを切り離す機能も不足してます、けどね。
Javaとか程度の縛りに何かを期待するのもまた、幻想だと思うです。
余談：
「なるほど、この言語のこの機能のおかげで、プロジェクトは破滅を免れたのか！」という実例って
有るんでしょうかね？
いや、たぶん「測定できない」ってのが本音だと思う。
つまり、Javaだのなんだのが言われているようなメリットって、ホントに実在するメリットなのだろうか？
思うんですが、強い型の言語の「メリット」は、その成立年代から察するに、
往年の、UnitTestなんて夢の夢だった時代のバランス感覚
によってバイアスがかかった評価だ、といってもいいと思います。
>大規模開発で優れたプログラマのみを集めるなんてのは一種のファンタジーです.
小規模でも同様かも(わら
どっちかてーと、問題は組織のほうだと思う。
駄目組織は、大だろうが小だろうが問わず、とにかく駄目プロジェクトを編成してくれやがる。
そしてさ、これは想像なんだけど(というのは俺もそういう場に居た事が無いんで)、
良い組織は最初から駄目プログラマを排除しているんじゃなかろうか？
＃あるいは、教育において却って駄目プログラマを作るようなヘマをしない、とか。
Re: アーミーナイフで家を建てる (スコア:1)
まさにそういう意味のことが書いてありましたね。
間違って不合格にした開発者が一杯いるはずだが、御免なさい、とさ。
Re: アーミーナイフで家を建てる (スコア:1)
"この採用システムに多くの欠陥があることは分かっています（採用すべき人間を不採用にしてしまったりとか）。" [capsctrl.que.jp]
なんて書いてあるのが、それですね。
Re: アーミーナイフで家を建てる (スコア:0)
で、それが出来ない無能がP言語のせいにして、Javaを使えば、「組織的開発が出来て」「ダメコードを上手く処理できる」とJavaマンセーして、今のいろんな意味で悲惨な状態になっていると。
個人的には、ニホンでは営業的には不遇なPerlによる小規模開発をよく提案するのですが、この手の「PerlはJavaに比べて～」系の話が出ると、eToysの事例 [bulknews.net]を出します。2000年の時点で、ほぼ、現在トレ
Re: アーミーナイフで家を建てる (スコア:0)
えと、そこは笑い所ですか？
Re:アーミーナイフで家を建てる (スコア:0)
これはいくらなんでも乱暴です。
実際トラブルもなく動いている大規模なシステムを開発しているところ
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氏も憂えているような)「消す」ことのデメリットは無くなるわけですし。
それに、プログラムじゃないんですから(^^;、
短い文ばかりがシックリくるとは限りません。
縮めたり分割したりすればいい、ってもの(とは限ら)ないと思います。
Re:太陽超小型装置 (スコア:1)
Pnuts [java.net]であれば、Java であるのと同時に「P言語」という要件も満たせますので
オススメです :-)
Groovy [codehaus.org] は「P言語」ではないですから～！残念！
Re:太陽超小型装置 (スコア:1)
WebL (ぼそっ)
多分誰も知らないんだろうな。
Re:太陽超小型装置 (スコア:1)
Javaといっても結局本当に美味しいのは、
既に枯れた(?)幾つかのライブラリなのですから、
それだけを美味しく頂戴すれば済むこと。
＃「ライブラリ」ってとこが味噌ね。フレームワークではないのよ。
＃言語が良ければコンテナなんてあんまり要らないんじゃないかと思うのでG7
＃もともと言語ってメタフレームワークなので、それが良質だと、
＃「上(フレームワーク部分)」は殆ど心配事では無くなるんじゃないかな。
＃そしてあとは「下(ライブラリ)」だけ調達することを考えればいい。
なので、JVMで動く(無数の)LL言語から
よさそうなのを見繕うってのは、
結構有望なやり方だろうと推察します。
個人的にはJRuby(のパフォーマンスの向上)に期待かな。