アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
最近のスクリプト言語の興隆をみて思うこと。 (スコア:3, 興味深い)
文法と機能が分離できていないことです。例えば、ある言語の文法が気に
入っていたとしても、その言語には自分の必要とするライブラリが充実し
ていない、という理由だけで、別の言語でスクリプトを書かなければいけ
ない、という場面が多くなりつつあります。
要するに、スクリプト言語のライブラリの再利用性は、そのスクリプト言
語に閉じてしまうのです。これは、色々な意味で勿体ないと思いませんか?
例えば、 XMLのライブラリは、Ruby, Perl, Gauche, などなど、同じ機能
を持つものを幾つ勉強しな
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みたいな方向性のほうが、やっぱり良いと思う。