アカウント名:
パスワード:
これって今まで使われてきた土台をベースにしてるわけだから、合っているとは思う。けど、これからもその分野でその言語が使われるか?といわれると誰にもわからないんじゃないかな。
# 傾向はつかめると思うけどあくまで道具として捉えて、やりたいことに対してどれが良いのか?っていう方からアプローチしたほうがいいとは思う。# でもそうするとどれがいいのかわからないからってことになるんだろうな。# そう考えるとなかなか難しいな。
IPv6とかで個人サーバーが増えてくれば、もっとコンパイル系言語のCGIが増えるんじゃないかと思ってるんだけど。 まあ、今やJavaScriptでCGIが書ける時代だけれど、逆に、ブラウザのJavaScriptはもはや純粋なスクリプト言語とは言いがたいわけだから……
今のトレンド方向はCGIですらないけど、それはともかくとしても、CGIやらウェブ系システムにコンパイル系言語が選ばれないのは、これまで個人が環境として使えなかったというのが主な理由ではないと思う。
CGIの代わりにコンパイラ系がなぜ弱いのかは、そこかしこで証明されていますが、大量にプログラムを起動するという点でコンパイラ系言語は圧倒的な差で負けているのですよ。 つまり、Web系のちょっとした処理のためだけにわざわざプログラムをロードするという負荷が高すぎるということです。特に大量アクセスが見込める場合はコンパイラ系は使わないほうが良いですよ。#但し、負荷がそれなりに高い処理に関しては、コンパイラ系を使ったほうが良い場合があるという結果だったような気がする#それでも大量アクセスが見込めるならコンパイラ系は使わないほうが良いみたいだけどね。
よくWebで使われるスクリプトの場合、mod_phpやらみたいにApacheモジュールがあるからってこと?だとすると、コードをほとんど改造することなく簡単にモジュールにできるツールか何かが出たら状況は変わる気がする。
ええと、分かっているんだとは思いますがCGIはプロセスを生成しますよ?s/CGI/スクリプト系言語/ または s/CGI/LL/とすれば意味は通じますが。
あと、負荷が最重要なんだったらコンパイラ系言語でモジュール書くのが一番速いと思いますが。もっと言えばウェブサーバ組み込み型のアプリをコンパイラ系言語で全部書いてしまうのが最速でしょうが、そういうのが一般的ではないのはなぜかは言うまでもないですよね。開発負荷が高すぎるんですよ。
それじゃApacheがボトルネックになるじゃないですか、と言ってnginxを開発した人とかLLからC++に移行したFacebookとかの事例もあるけどね。
ウェブサーバ組み込み型のWEBアプリを効率的に開発することに特化したライブラリと言語仕様のコンパイラ系言語って需要がありそうだな。
コンパイラ系ってよくわからないけど、事前にコンパイルしておくタイプの事を言ってるのなら、mod_perlは中間バイナリをキャッシュするし、mod_phpも商用サイトならAPCとかで同じことするし、Javaや.NETはサーバにデプロイするのはIDEから吐いた中間バイナリだし、何か勘違いしてません?Webで事前にコンパイルしておくタイプの言語が弱いのは単純に、オワコンまっしぐらのJavaが糞フレームワークであるStruts以降まともなMVCフレームワークを輩出出来ていないのと、.NETは2010年ぐらいからやっと使い物になりだしたのと、PythonはWeb屋じゃなくてインフラ屋にしかファンがいないからってだけだぜ。
勘違いしてるのは君。コンパイルするのが問題だなんてどこにも書かれてない訳だが。
CGIの代わりにコンパイラ系がなぜ弱いのかは、そこかしこで証明されていますが、
ちょっと、その証明を読みなおしてこい。
CGIとコンパイラを対比してるあたりでなんか勘違いしてる可能性が高いのだけどCGI=インタプリタとして考えたとしても、インタプリタがコンパイラより速度や負荷的に性能が上回るってことがありえるのだろうか?
モジュール一個で多数のスクリプトを裁くようななインタプリタは、実行ファイル単体のCGIにプロセス生成コストで勝ります。スクリプト言語CGI実行用HTTPD組込み型モジュールが多機能(プロセスやスレッド辺りで複数のインスタンスを捌けたり、グローバルにキャッシュが効く)なので、追いつくのは結構大変です。ネイティブコードを吐くような言語だとどうしても単体で完結しがちで、小数のプロセスやスレッドで多数のインスタンスを回すフレームワーク込みでその辺提供して、それをHTTPDと上手く組み合わせなきゃならん。
無理ではないけど、そんなフレームワーク考えるよりHTTPDのモジュールを直接書いたり、単機能HTTPDを作ってそっちに処理を投げるほうが楽だったりして、そうなってくるとCGIじゃなくなってくるというオチ
まぁそういうことだよね。WARを置かせてくれるレンタルサーバーなんて滅多にないし、自前でホスト丸ごと借りるのなんてセキュリティの設定がどうの、パッチがどうのって面倒が増えるし高くなるし。
じゃあPHPにしちゃえ、ってなるのは当然だ。
>IPv6とかで個人サーバーが増えてくれば、もっとコンパイル系言語のCGIが増えるんじゃないかと思ってるんだけど。 個人サーバーってか、メーカーお仕着せ機能のモバイルサーバーとかでないと。一般的な個人サーバーって今じゃ利点が無く、結局無難なレンタルが選ばれるから一定の環境になっちゃっているのでしょう。
レンタルサーバーだと、純粋なコンパイルまでならsshなんかで許可してくれるかもしれないけど、apacheのmoduleのビルドみたいに、導入の過程でrootが必要になる手順の場合、断られるのが普通でしょ。というか、仮にサービス提供があったら、管理側の人件費が跳ね上がるだろうから、それを価格に反映させられてしまうと手が出るユーザーはいないと思う。
でも、みんなが好き勝手にサーバーを立てる時代になれば、もっと尖がった環境が増えてもいいはずで、そこでは敢えてスクリプト言語(というかインタープリタ言語)を使う動機が薄いように思う。負荷というか、トラフィックより電気代の方がボトルネックになってくると尚更じゃないかな。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
おおむね合っているとは思うけど (スコア:5, 参考になる)
これって今まで使われてきた土台をベースにしてるわけだから、合っているとは思う。
けど、これからもその分野でその言語が使われるか?といわれると誰にもわからないんじゃないかな。
# 傾向はつかめると思うけどあくまで道具として捉えて、やりたいことに対してどれが良いのか?っていう方からアプローチしたほうがいいとは思う。
# でもそうするとどれがいいのかわからないからってことになるんだろうな。
# そう考えるとなかなか難しいな。
Re:おおむね合っているとは思うけど (スコア:1)
IPv6とかで個人サーバーが増えてくれば、もっとコンパイル系言語のCGIが増えるんじゃないかと思ってるんだけど。 まあ、今やJavaScriptでCGIが書ける時代だけれど、逆に、ブラウザのJavaScriptはもはや純粋なスクリプト言語とは言いがたいわけだから……
Re: (スコア:0)
今のトレンド方向はCGIですらないけど、それはともかくとしても、CGIやらウェブ系システムにコンパイル系言語が選ばれないのは、これまで個人が環境として使えなかったというのが主な理由ではないと思う。
Re: (スコア:0)
CGIの代わりにコンパイラ系がなぜ弱いのかは、そこかしこで証明されていますが、大量にプログラムを起動するという点でコンパイラ系言語は圧倒的な差で負けているのですよ。
つまり、Web系のちょっとした処理のためだけにわざわざプログラムをロードするという負荷が高すぎるということです。特に大量アクセスが見込める場合はコンパイラ系は使わないほうが良いですよ。
#但し、負荷がそれなりに高い処理に関しては、コンパイラ系を使ったほうが良い場合があるという結果だったような気がする
#それでも大量アクセスが見込めるならコンパイラ系は使わないほうが良いみたいだけどね。
Re:おおむね合っているとは思うけど (スコア:1)
よくWebで使われるスクリプトの場合、mod_phpやらみたいにApacheモジュールがあるからってこと?
だとすると、コードをほとんど改造することなく簡単にモジュールにできるツールか何かが出たら状況は変わる気がする。
1を聞いて0を知れ!
Re:おおむね合っているとは思うけど (スコア:1)
ええと、分かっているんだとは思いますがCGIはプロセスを生成しますよ?
s/CGI/スクリプト系言語/ または s/CGI/LL/とすれば意味は通じますが。
あと、負荷が最重要なんだったらコンパイラ系言語でモジュール書くのが一番速いと思いますが。もっと言えばウェブサーバ組み込み型のアプリをコンパイラ系言語で全部書いてしまうのが最速でしょうが、そういうのが一般的ではないのはなぜかは言うまでもないですよね。開発負荷が高すぎるんですよ。
Re: (スコア:0)
それじゃApacheがボトルネックになるじゃないですか、と言ってnginxを開発した人とかLLからC++に移行したFacebookとかの事例もあるけどね。
Re: (スコア:0)
ウェブサーバ組み込み型のWEBアプリを効率的に開発することに特化したライブラリと言語仕様のコンパイラ系言語って需要がありそうだな。
Re: (スコア:0)
コンパイラ系ってよくわからないけど、事前にコンパイルしておくタイプの事を言ってるのなら、
mod_perlは中間バイナリをキャッシュするし、mod_phpも商用サイトならAPCとかで同じことするし、
Javaや.NETはサーバにデプロイするのはIDEから吐いた中間バイナリだし、何か勘違いしてません?
Webで事前にコンパイルしておくタイプの言語が弱いのは単純に、オワコンまっしぐらのJavaが糞フレームワークであるStruts以降まともなMVCフレームワークを輩出出来ていないのと、
.NETは2010年ぐらいからやっと使い物になりだしたのと、PythonはWeb屋じゃなくてインフラ屋にしかファンがいないからってだけだぜ。
Re: (スコア:0)
勘違いしてるのは君。コンパイルするのが問題だなんてどこにも書かれてない訳だが。
Re: (スコア:0)
CGIの代わりにコンパイラ系がなぜ弱いのかは、そこかしこで証明されていますが、
ちょっと、その証明を読みなおしてこい。
Re: (スコア:0)
CGIとコンパイラを対比してるあたりでなんか勘違いしてる可能性が高いのだけど
CGI=インタプリタとして考えたとしても、インタプリタがコンパイラより速度や負荷的に性能が上回るってことがありえるのだろうか?
Re: (スコア:0)
モジュール一個で多数のスクリプトを裁くようななインタプリタは、実行ファイル単体のCGIにプロセス生成コストで勝ります。
スクリプト言語CGI実行用HTTPD組込み型モジュールが多機能(プロセスやスレッド辺りで複数のインスタンスを捌けたり、グローバルにキャッシュが効く)なので、追いつくのは結構大変です。
ネイティブコードを吐くような言語だとどうしても単体で完結しがちで、小数のプロセスやスレッドで多数のインスタンスを回すフレームワーク込みでその辺提供して、それをHTTPDと上手く組み合わせなきゃならん。
無理ではないけど、そんなフレームワーク考えるよりHTTPDのモジュールを直接書いたり、単機能HTTPDを作ってそっちに処理を投げるほうが楽だったりして、そうなってくるとCGIじゃなくなってくるというオチ
Re: (スコア:0)
まぁそういうことだよね。WARを置かせてくれるレンタルサーバーなんて滅多にないし、
自前でホスト丸ごと借りるのなんてセキュリティの設定がどうの、パッチがどうのって
面倒が増えるし高くなるし。
じゃあPHPにしちゃえ、ってなるのは当然だ。
Re: (スコア:0)
>IPv6とかで個人サーバーが増えてくれば、もっとコンパイル系言語のCGIが増えるんじゃないかと思ってるんだけど。
個人サーバーってか、メーカーお仕着せ機能のモバイルサーバーとかでないと。
一般的な個人サーバーって今じゃ利点が無く、結局無難なレンタルが選ばれるから一定の環境になっちゃっているのでしょう。
Re: (スコア:0)
レンタルサーバーだと、純粋なコンパイルまでならsshなんかで許可してくれるかもしれないけど、apacheのmoduleのビルドみたいに、導入の過程でrootが必要になる手順の場合、断られるのが普通でしょ。というか、仮にサービス提供があったら、管理側の人件費が跳ね上がるだろうから、それを価格に反映させられてしまうと手が出るユーザーはいないと思う。
でも、みんなが好き勝手にサーバーを立てる時代になれば、もっと尖がった環境が増えてもいいはずで、そこでは敢えてスクリプト言語(というかインタープリタ言語)を使う動機が薄いように思う。負荷というか、トラフィックより電気代の方がボトルネックになってくると尚更じゃないかな。