アカウント名:
パスワード:
アプリケーション拡張言語に関しては、そういう「マイ言語」乱立の弊害はずーっと言われていて、「統一しちゃる」って言語が次々出ては、one of themになってゆく…って状況じゃないですかね。 Tclだって最初はその状況を何とかするって触れ込みだったでしょ。
今までそれが成功した言語が無いってことは、やっぱり一つで全てをカバーするのが無理ってことなんじゃないのかなあ。
ただ、ライブラリバインディングの言語間の差異、というのは、それほど問題じゃないように思います。例えばコンポーネントをオブジェクト指向で見せているバインディングなら、どの言語を使ってもだいたい使いかたの類推が効くでしょう。しかし、普通のオブジェクト指向しか見たことが無い人が関数型のフレームワークを使おうとしたら、たとえ使い込んだ言語であってもやっぱり戸惑うんじゃないでしょうか。問題になるのはそういうパラダイムレベルでの差であって、そのへんをどれかに統一して表面だけいろいろの言語が使えますよって言っても、あんまり嬉しくないんじゃないかと思います。
>ソフトウェアの機能を拡張するために、新言語を覚えさせるという負担を、 >何の罪もないユーザに強いさせて、これらのソフトの作者は何とも思わないのでしょうか?
私は『なんとも思っていないことはないじゃないか』と思いながら使っています。 これはその拡張言語がCだったりPascalだったりあるいはPL/Iなどの有名言語であれば良いのかもしれませんが、ユーザがどの言語ユーザかは分からないわけで、その中で開発者はそれぞれ良いであろうと思う方法論で実装してくれているんだ、と…。 emacsの場合は、lisp使いがエディタを作って、拡張はlispでやってねって事な訳で。 CPUにも同様なことがやっぱり言えて、わざわざ新しい命令・モード増やすな!とか言うのに近くなってしまうと思うのです。まあ、transmetaのcrusoeとかはコードモーフィングでx86互換にしているということもまた一方であるわけですけど。
まあユーザは『言語拡張しなくても良い機能ふんだんのアプリケーションを作って。バグは無しでね』っていうでしょうけど(笑)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
最近のスクリプト言語の興隆をみて思うこと。 (スコア:3, 興味深い)
文法と機能が分離できていないことです。例えば、ある言語の文法が気に
入っていたとしても、その言語には自分の必要とするライブラリが充実し
ていない、という理由だけで、別の言語でスクリプトを書かなければいけ
ない、という場面が多くなりつつあります。
要するに、スクリプト言語のライブラリの再利用性は、そのスクリプト言
語に閉じてしまうのです。これは、色々な意味で勿体ないと思いませんか?
例えば、 XMLのライブラリは、Ruby, Perl, Gauche, などなど、同じ機能
を持つものを幾つ勉強しなければいけないんでしょう?また、同じ機能を
持つライブラリを多くのスクリプトで用意することで、どれくらいフリー
ソフト界の人的資源が無駄になるのでしょう?
また、ソフトウェアの機能拡張方法として、各ソフトウェアがばらばらに
異なる文法のスクリプト言語を提供しているのも明らかに異常です。
sawfish のrep しかり、emacsのelispしかり、HTMLのjavascriptしかり
(これは国際規格化されてますけど)… 最近はわりと小さなソフトでも、
独自の構文のスクリプト言語を備えています。ソフトウェアの機能を拡張
するために、新言語を覚えさせるという負担を、何の罪もないユーザに強
いさせて、これらのソフトの作者は何とも思わないのでしょうか?
この点で、あきらかにUnixはWindowsに劣っています。Windowsでは、まが
りなりにも、WSHというフレームワークで、好きなAPIを好きな言語で呼び
出せます。ActiveScriptRubyで、Wordの文書に対してgrepができる、その
ような仕組みがまだまだUnixでは未熟ですよね。
どうか、スクリプト言語の元来の利点である「手軽さ」と「保守改造のし
やすさ」が生かされるよう、そして、様々な言語で書かれた小さいソフト
ウェア部品が、他の言語からでも気軽に呼び出せるよう、そして、機能を
拡張したいと思うたびに、新しい言語を習得する、という歪んだ負荷に苦
しむこともなく、様々な人々の作ったコードを気軽に組み合わせて、楽し
んでハッキングができるという、そんなコンポーネントフレームワークが
早く実現しますように…
# Bonobo(CORBA)に期待していいのか?やっぱり駄目なのか?
Re:最近のスクリプト言語の興隆をみて思うこと。 (スコア:2, 興味深い)
いろんな思想の言語にいろんな思想のインターフェイスが存在している。これは統一したくないのではなくて、それぞれの「特徴」があるからでしょう。特徴には雑多なものがあり、良いものも悪いものもあるけれど、「決定版」的スタンダードが存在しないために、統一ができない。そういったことなのではないかと。そういった状態で無理に統一しようとすれば、磨擦が起きるか従わないものが出るだけなんで、統一する意味がないし。たとえばJavaとRubyで同一のAPIが作れたとしても、やっぱりどっちかにとって不便なことってあるように思う。
幸い今時の言語の多くは「汎用」なので、「適材適所」言い訳につまみ食いするのではなくて、どれかの言語に腰を据えてその言語の流儀を身につけながら、いろんな「機能」を実装して行くというのが、個人的な近道なのではないかと思います。
Re:最近のスクリプト言語の興隆をみて思うこと。 (スコア:2, すばらしい洞察)
メディアプレイヤーのスキンエンジンがIEのコンポーネント(というか確かIEの1つ下のレベルのコンポーネントだったっけ?)を使って書かれているのには感心しました。
LLの連携に関しては他にParrotやJVMなどが期待できるでしょうか。
しかし一方UNIXの方もアプリケーションの連携という点では劣っているようには思えません。
確かにGUIのプログラムに関しては連携性が低いと思いますが、CUIアプリケーションやデーモンについてはかなり柔軟に各プログラムが連携されていると思います。
Windowsが優れたフレームワークで連携しているのに対し、UNIXではしっかり設計されアプリケーションで連携しているという状態でしょうか。
XMLの例で言えばWindowsでは共通のライブラリを使って操作を行い、UNIXではXSLTスタイルシートを生成したり、XSH [sourceforge.net]をパイプを使って操作するといったスタイルでしょうか。
そしてUNIXはCUI文化なので普段ユーザーが行っている操作そのものをスクリプトとして書けるというのも、簡単に連携させることができるという印象を与えているのかもしれません。
Re:最近のスクリプト言語の興隆をみて思うこと。 (スコア:1)
>負担を、何の罪もないユーザに強 いさせて、これらのソフトの作者
>は何とも思わないのでしょうか?
そういうソフトの作者は,たぶん新しいプログラミング言語をマスターするのは負担でも何でもない(むしろ楽しい)ので何とも思わないでしょう.WSHみたいな言語で統一されるよりは,面白い言語がうじゃうじゃとある方を好むのではないでしょうか?
# 関係ないけど「言語をおぼえる」という表現にはすごく違和感を感じます.
Re:最近のスクリプト言語の興隆をみて思うこと。 (スコア:1, すばらしい洞察)
アプリケーション拡張言語に関しては、そういう「マイ言語」乱立の弊害はずーっと言われていて、「統一しちゃる」って言語が次々出ては、one of themになってゆく…って状況じゃないですかね。 Tclだって最初はその状況を何とかするって触れ込みだったでしょ。
今までそれが成功した言語が無いってことは、やっぱり一つで全てをカバーするのが無理ってことなんじゃないのかなあ。
ただ、ライブラリバインディングの言語間の差異、というのは、それほど問題じゃないように思います。例えばコンポーネントをオブジェクト指向で見せているバインディングなら、どの言語を使ってもだいたい使いかたの類推が効くでしょう。しかし、普通のオブジェクト指向しか見たことが無い人が関数型のフレームワークを使おうとしたら、たとえ使い込んだ言語であってもやっぱり戸惑うんじゃないでしょうか。問題になるのはそういうパラダイムレベルでの差であって、そのへんをどれかに統一して表面だけいろいろの言語が使えますよって言っても、あんまり嬉しくないんじゃないかと思います。
Re:最近のスクリプト言語の興隆をみて思うこと。 (スコア:1)
>ソフトウェアの機能を拡張するために、新言語を覚えさせるという負担を、
>何の罪もないユーザに強いさせて、これらのソフトの作者は何とも思わないのでしょうか?
私は『なんとも思っていないことはないじゃないか』と思いながら使っています。
これはその拡張言語がCだったりPascalだったりあるいはPL/Iなどの有名言語であれば良いのかもしれませんが、ユーザがどの言語ユーザかは分からないわけで、その中で開発者はそれぞれ良いであろうと思う方法論で実装してくれているんだ、と…。
emacsの場合は、lisp使いがエディタを作って、拡張はlispでやってねって事な訳で。
CPUにも同様なことがやっぱり言えて、わざわざ新しい命令・モード増やすな!とか言うのに近くなってしまうと思うのです。まあ、transmetaのcrusoeとかはコードモーフィングでx86互換にしているということもまた一方であるわけですけど。
まあユーザは『言語拡張しなくても良い機能ふんだんのアプリケーションを作って。バグは無しでね』っていうでしょうけど(笑)
/* Seeds */
Re:最近のスクリプト言語の興隆をみて思うこと。 (スコア:1)
その辺は、あちら立てればこちら立たず、なんじゃないかなあ。
例えば、なんでもかんでもライブラリ(プラグイン)化しようと思ったら、
Schemeみたいに素っ気無い言語仕様になっちゃうわけだよね、とか。
あとは自動化ですかね。SWIGって使ったこと無い(話に聞いたことしかない)んですが、
あっちとこっちの繋ぎのコードは、何らかの手段で自動生成する方向に
出来るだけ持っていきたいものです。
#あんまり自動化しすぎると、今度はメタな仕組み自体が長大になっちゃったりするが。
#とりあえずオブジェクトと無名関数が無い(or自作もできない)言語は却下なのでG7
>独自の構文のスクリプト言語を備えています
言語を"使う"環境が…ええと、こういうのは「コモディティ」とかいうんだっけか…化していない、
ということなんでしょうかね。
そういやJava畑にはJavaScriptingFrameworkだかいう(名称うろ覚え)のが出てきたんでしたね。
なにかってーと、「色々な(^^;」言語をJava上に簡単に載せれるようにするというFramework
なんだそうで、つまり言語は益々増えることを許容(どころか歓迎?)してるんだな(^^;
>同じ機能 を持つものを幾つ勉強しなければいけないんでしょう?
他言語用の既存のライブラリを、別の言語に「できるだけそのまま」移植する、
っていう方向性はアリだと思います。はい。
ただ、せっかくその言語を使ってるなら、こういうこともしないと馬鹿馬鹿しいよね、
というような面はあります。
たとえばRubyだったらイテレータも使うようにしないと空しいね、とか。
#某OODBのTransaction用APIをイテレータでラップしたのでG7
>ActiveScriptRubyで、Wordの文書に対してgrepができる、その ような仕組み
Unixは、(良し悪しはさてき)「逆」ですね。
アプリごとの「データの」差異を無視する(^^;方向性というか。Wordだなんだという区別を無視する世界。
乱暴にいえば「なんでもテキスト」の世界だったりするわけです。
で、同じテキストというクラス(?)なもんだから、どこまでいってもGrepだけで話が済むとか、そういう発想。
…まあ俺も無理を感じますけどね。
なので、俺の解釈としては、Unixが「劣っている」のだとすればそれは
「色々なデータ形式」という考え方が薄いという点が劣ってるんだと思っています。
陳腐な言葉でいえばマルチメディア(藁)という発想がUnixには無いわけで。
ただ、データをパイプで流すだけの世界だと、Objectみたいに自在にNetwork構造を組むことが出来ないんで、
メディア以前の問題ではありますね。
やっぱり「パイプ(による部品化)じゃvi(を作るのに使えるような部品)は作れない」わけで…
あと、一方で、じゃあWindowsなりなんなりならばどんな運用形態にも(^^;対応できるくらいに
柔軟なモデルを提供できているのか?っていうと、それはそれで疑問ですよね。
時期尚早という言葉を使ってる人が居ますが、
逆にいえばWindowsって、良くも悪くも「新化済みの」ものなんじゃないかな。
#たぶんSmalltalkのモデルのほうがマシだろうな。柔軟性も将来性も。
>Bonobo
Processの壁を肯定したうえで、それを越境するために大きな負担(処理効率も、記述形態も)を抱える
というやり方は、やっぱり無理を感じてます。馬鹿速いCPUで誤魔化してばかりいるのもナンですし。
Smalltalkみたいな方向性のほうが、やっぱり良いと思う。
突き詰めて本格的にやるなら (スコア:1)
プロセッサレベルでの受け入れ態勢が必要でしょう .
せめて中間コードのレベルでの透過性が .
謝々々々 台湾宮廷料理海味館 名●屋市熊の前二丁目 ( MiniStop 対面 )
Re:最近のスクリプト言語の興隆をみて思うこと。 (スコア:0)
> Windowsでは、まがりなりにも、WSHというフレームワークで、
Ruby 256 倍邪道編しか読んでないのでよく知らんけど、
あれって「WSH というフレームワーク」なの? COM とか
OLE とかじゃないの?
なお、内容に関しては #522494 に同意。
関係ないけど、俺は邪道編を読んで、マイクロソフトがちょっと
だけ
Re:最近のスクリプト言語の興隆をみて思うこと。 (スコア:0)
WSHとゆーか.netとゆーか、SOAPの標準化が進めば変わってくるのかもしれませんが。
Re:最近のスクリプト言語の興隆をみて思うこと。 (スコア:0)
目的のスクリプト言語でとあるライブラリが存在しなかったとして、別の言語にはそのライブラリが用意されていた場合、wrapperを書いてパイプ経由でデータを受け渡すという事が出来ます。それが別の言語に特化したようなライブラリならその限りではありませんが、そこまで閉じてるようには思えません。
また最近のスクリプト言語はC言語の基本さえ出来ていれば何とかなる物が殆どだと思います。簡単なwrapperを書く程度なら、その言語をマスターせずとも何とかなるものでしょう。
Re:最近のスクリプト言語の興隆をみて思うこと。 (スコア:0)
Re:最近のスクリプト言語の興隆をみて思うこと。 (スコア:0)
そうですか。
Re:最近のスクリプト言語の興隆をみて思うこと。 (スコア:1)
Re:最近のスクリプト言語の興隆をみて思うこと。 (スコア:0)