アカウント名:
パスワード:
アプリケーション拡張言語に関しては、そういう「マイ言語」乱立の弊害はずーっと言われていて、「統一しちゃる」って言語が次々出ては、one of themになってゆく…って状況じゃないですかね。 Tclだって最初はその状況を何とかするって触れ込みだったでしょ。
今までそれが成功した言語が無いってことは、やっぱり一つで全てをカバーするのが無理ってことなんじゃないのかなあ。
ただ、ライブラリバインディングの言語間の差異、というのは、それほど問題じゃないように思います。例えばコンポーネントをオブジェクト指向で見せているバインディングなら、どの言語を使ってもだいたい使いかたの類推が効くでしょう。しかし、普通のオブジェクト指向しか見たことが無い人が関数型のフレームワークを使おうとしたら、たとえ使い込んだ言語であってもやっぱり戸惑うんじゃないでしょうか。問題になるのはそういうパラダイムレベルでの差であって、そのへんをどれかに統一して表面だけいろいろの言語が使えますよって言っても、あんまり嬉しくないんじゃないかと思います。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
最近のスクリプト言語の興隆をみて思うこと。 (スコア:3, 興味深い)
文法と機能が分離できていないことです。例えば、ある言語の文法が気に
入っていたとしても、その言語には自分の必要とするライブラリが充実し
ていない、という理由だけで、別の言語でスクリプトを書かなければいけ
ない、という場面が多くなりつつあります。
要するに、スクリプト言語のライブラリの再利用性は、そのスクリプト言
語に閉じてしまうのです。これは、色々な意味で勿体ないと思いませんか?
例えば、 XMLのライブラリは、Ruby, Perl, Gauche, などなど、同じ機能
を持つものを幾つ勉強しな
Re:最近のスクリプト言語の興隆をみて思うこと。 (スコア:1, すばらしい洞察)
アプリケーション拡張言語に関しては、そういう「マイ言語」乱立の弊害はずーっと言われていて、「統一しちゃる」って言語が次々出ては、one of themになってゆく…って状況じゃないですかね。 Tclだって最初はその状況を何とかするって触れ込みだったでしょ。
今までそれが成功した言語が無いってことは、やっぱり一つで全てをカバーするのが無理ってことなんじゃないのかなあ。
ただ、ライブラリバインディングの言語間の差異、というのは、それほど問題じゃないように思います。例えばコンポーネントをオブジェクト指向で見せているバインディングなら、どの言語を使ってもだいたい使いかたの類推が効くでしょう。しかし、普通のオブジェクト指向しか見たことが無い人が関数型のフレームワークを使おうとしたら、たとえ使い込んだ言語であってもやっぱり戸惑うんじゃないでしょうか。問題になるのはそういうパラダイムレベルでの差であって、そのへんをどれかに統一して表面だけいろいろの言語が使えますよって言っても、あんまり嬉しくないんじゃないかと思います。