[Squeak-ja: 3031] Wiki としての SuperSwiki

> Wikiクローンの一つであるWifkyにはWifkyページとして
> 書かれたスクリプト(Perlですが)を、実行できるプラグイン
> があります。
>
> ((perl ページ名 引数1 引数2 …))
>
> WikiはWebブラウザ上でページを編集・作成できるツールです
> ので、
> 上のプラグインを使えば、プラグインの開発・編集も
> Webブラウザ上でできるという、優れものです。
>
> http://wifky.sourceforge.jp/cgi-bin/index.cgi?p=(2006.06.17)+%A5%DA%A1%BC%A5%B8%C6%E2%A5%B9%A5%AF%A5%EA%A5%D7%A5%C8%BC%C2%B9%D4%A5%D7%A5%E9%A5%B0%A5%A4%A5%F3%A4%F2%B8%F8%B3%AB%A4%B7%A4%DE%A4%B7%A4%BF%A1%A3
> http://wifky.sourceforge.jp/cgi-bin/index.cgi?p=%5Bplugin%5D+%A5%DA%A1%BC%A5%B8%C6%E2%A5%B9%A5%AF%A5%EA%A5%D7%A5%C8%BC%C2%B9%D4
>
>
> 一見それだけの機能ですが、この機能は、
> Webブラウザ上で多くの人が開発に関与できるという点で、
> 『アプリケーションの協調的な促成開発』
>  "Collaborative RAD" ができる可能性を
> 示唆していると考えています。
>
> ---
> 稼動中のシステムの拡張・変更もそのシステム上で行う
> システムといえば、Squeakもそうですね。
> SuperSwikiには上のようなプラグインがあるとすれば、
> もっと先進しているのではないか、と思いますが、、、
> いかがでしょうか。
>
> よろしければ、教えてください。
>
>
> --------------------------------------
> Let's start Yahoo! Auction  -  Free Campaign Now!
> http://pr.mail.yahoo.co.jp/auction/

> Wifkyの((perl))プラグインでは、ユーザーはWifkyのページとして
> プラグインを作成出来ます。
>
>
> 例えば、Wifkyのページ「挨拶」の内容が、
>
>   print ('<P>' . &enc ("こんにちは、$_[1]さん。") . '</P>') ;
>
> だとします。これを、普通のWifkyページの中で、
>
>   ((perl 挨拶 山田))
>
> という形で、呼び出して使うことができます。
> もちろん、「((perl 挨拶 山田))」のところには、
> 「<P>こんにちは、山田さん。</P>」がはいります。
>
>
> 「挨拶」のページもWifkyページのひとつに過ぎませんので、
> たとえば、誰か他の人が「挨拶」のページの
> バグ取りすることも可能です。
>
>
> つまり、WikipPediaでは、事典の作成を複数の人でコラボラティブ
> （協調して）やっていますが、それと同じようなことを
> プログラミングで実践できるわけです。
>
> 上の例では価値が分かりませんが、もっと大規模な
> フレームワーク構築など、に活用できるのではないか
> と、考えています。
>
> Wikiの持ってるバージョン管理の機能が、
> これにも使えることになりますし、、、、、

> それから、Pierでは、画像やゲームなどの、
> （既存の）オブジェクトを貼り付けられるようですが、
> 存在しないオブジェクトをユーザーがPier上で作成（開発）
> できるのでしょうか。
>
>
> Wifkyの((perl))プラグインでは、ユーザーはWifkyのページとして
> プラグインを作成出来ます。
>
>
> 例えば、Wifkyのページ「挨拶」の内容が、
>
> print ('<P>' . &enc ("こんにちは、$_[1]さん。") . '</P>') ;
>
> だとします。これを、普通のWifkyページの中で、
>
> ((perl 挨拶 山田))
>
> という形で、呼び出して使うことができます。
> もちろん、「((perl 挨拶 山田))」のところには、
> 「<P>こんにちは、山田さん。</P>」がはいります。
>
>
> 「挨拶」のページもWifkyページのひとつに過ぎませんので、
> たとえば、誰か他の人が「挨拶」のページの
> バグ取りすることも可能です。
>
>
> つまり、WikipPediaでは、事典の作成を複数の人でコラボラティブ
> （協調して）やっていますが、それと同じようなことを
> プログラミングで実践できるわけです。
>
> 上の例では価値が分かりませんが、もっと大規模な
> フレームワーク構築など、に活用できるのではないか
> と、考えています。
>
> Wikiの持ってるバージョン管理の機能が、
> これにも使えることになりますし、、、、、
>
>
>
> Pierには、この様な機能は、ありますか。。。。

> 現在のSeasideやPierは非常に強力ですが、残念ながら、
> ホームページビルダーとしての用法に留まっています。
> ビルダーの機能はそれはそれで非常に重要なものですが、
> サイト管理者が作成するページをクライアントが閲覧する、
> サービスや情報の流れが一方通行になってしまいがちです。
>
> Wikipediaの成功が示しているのは、情報提供者と情報利用者の
> 区別のないサイトのあり方の優位性だと思っています。
>
> そういう意味で、SeadieやPierの今後の展開が楽しみですね。。。。

> 梅澤さま
>
> 中田です。返信ありがとうございます。
>
> >>>> ユーザ=プログラマというのは、かのAlan Kayさんもずっと唱えていること
> >>>> ですからね。これを実現しないとSqueakとしての面目が立ちません。
> >>>>
> >>>> 私も微力ながらそういう方向のWebを指向していきたいと思っています。
>
>
> Wikiの話題からはそれてしまいますが、、、、
>
> アラン・ケイ氏の思想についての話がでましたので、
> 私も考えているところを、、、、、、
>
>
> ビジネスシーンなど「アプリケーション」という
> 形態が最も適している場合もありますので、「利用者＝作成者」
> という図式がすべての場合に適しているとは思いませんが、、、、
> 私も同氏の思想には一理あると思っています。
>
> 現状では「利用者＝作成者」という形態のソフトウェア
> (あるいは「環境」)はまだまだ発展途上にあると感じています。
> この様な環境があれば、ソフトウェアの世界はずっと多様になる
> はずです。
>
> 残念ながら、現在のソフトウェア環境は料理や日曜大工のように
> だれでも直感的にできるほど簡単なものではありません。
> 「利用者＝作成者」を実現するには、ソフトウェア作成の過程から
> 難しい記号列(プログラムコード)を書く作業を排除すべとだと思います。
> (原理的にできるのかどうかはわかりませんが、、、)
> そのような意味では、SqueakのeToys、LEGO社のMindStorm、
> MATLABのSimulinkのように「機能の塊を視覚的につなげる」作業で
> "プログラム" できる必要があるかと思います。。。
>
> Simulinkのようにもともとブロック図で描けるようなシステムや
> CADやHP作成など、もともと視覚性のあるものを作るシステムでなければ、
> プログラミング作業を視覚的にできないようですが、、、
> ロジックの記述も視覚化できればうれしいですね。
>
> CADといえば、建築構造物の図面もCADで作成しますが、
> 数年前に話題になった「デザインパターン」(GoF)も
> 建築物のデザインパターンを意識して議論されてきた経緯があるようです。
>
> パターンを取り扱うものとして、
> AdaやC++などにはテンプレートの仕組みがあります、
> また、Haskelなどの関数型言語には高階関数という考え方があります。
> いずれも、その有用性が広く認められているところです。
> いずれも「アルゴリズムの抽象化」を実践しているものです。
> 私が思うところですが、、、
> ロジックの視覚化にはテンプレート・高階関数がひとつの鍵かも知れません。

> 横川さま
>
> 中田です。返信ありがとうございます。
>
> >>>> 高階の抽象化とその視覚化にはぼくも興味があって、
> >>>> IPA未踏プロジェクトのSwimmyで試みました。
> >>>> http://yengawa.homedns.org:8888/Swimmy
> >>>> Etoyですでにプログラムされた複数のオブジェクトをさらに組み合わせて
> >>>> 別のプログラムを構成する仕組みで、状態遷移図を視覚化に使いました。
> >>>> 可能性はありそうだけど、どう利用するかが難しくて課題を残してます。
>
> サイトを拝見し、イメージファイルも開いてみましたが、、、
> 今ひとつ操作法がよくわかりませんでした。。。。
> (Squeakにまだ慣れてないのが大きな理由かも知れませんが)
>
> サイトに書かれていた英文の説明をみましたが、
> エージェントシステムとのことですね。

>
> エージェント技術の用途が見えない、ひとつの理由は、
> この技術の特性によるものがあると思います。
> コーディング作業が主体をしめる現状のプログラミング環境に
> 適しているのは、静的な方つまりテンプレートや高階関数です。
>
> そしてもうひとつの理由は、エージェント技術が未成熟である
> ことにあるのではないでしょうか。エージェントを動作させる
> 環境や言語など、基盤となる技術は十分だ思われますが、
> 実用的なフレームワークは(恐らく)存在しないのではありませんか。
>
> 今でこそ当たり前になっているテンプレートの技術も、
> 「汎用プログラミング」という手法として古くから一部の
> 計算機科学者には知られていましたし、Ada言語でもgeneric機構
> として採用されていました。しかし、それが今のように実用
> 目的に用いられるまでには、SmalltalkのCollectionを含めて、
> ライブラリー・フレームワークの試行錯誤の蓄積があったからです。
> C++のテンプレートライブラリーはそれらの経験に基づくものです。
>
> エージェントの場合、ソフトウェア世界をどのようにすれば、
> 過不足なくモデル化すればいいか、つまり、エージェントの
> 語彙をどのように設定するか、語彙のフレームワークがまだ
> 成熟していないのではないでしょうか。
>
> 例えば「テレビのリモコン操作」などのようにな余りにも狭い世界で
> 語彙を決めると、テレビ以外の装置の操作ができないものとなります。
> 動的な性質をもつエージェントである必要すらなく、普通のオブジェクト
> で十分となってしまうわけです。
>
> だからといって、具体的な目標がないままだと先には進めませんので、
> 手始めには、既存のオブジェクト技術で作られたものをエージェント
> でつくり直してみるというのはどうでしょうか。簡単なところでは、
> ウィンドウツールキットをエージェントで書いたらどうなるでしょう。
> その中で、どのような語彙が共通化できて、どのような語彙は共通化
> できないかが見えてくるのではないでしょうか。うまくすれば、
> その語彙はトランザクション制御やファイル操作やデータベース処理
> にさえ使えるかもしれません。

>
>
>
> 慣れた行動は別としても、私たちが何かをする時、とりわけ新しい何か
> を考えたり・作り出すときには頭の中には「イメージ」があります。
> イメージという思考思考過程は、これまでの経験から得たものの流れを、
> そのとき考えているものに "当てはめる" 過程が大きいと思います。
>
> 難しく言えば、既知の物事との「同型性」(数学用語) を見つけて、
> それ関連づいている解法(アルゴリズム)を当てはめるというわけです。
> 逆に言えば、当てはめることのできる経験、つまり、思考の雛形
> がなければ、物事を解決できないといえます。
>
>
> 実用性が確かめられた多くの雛形が出揃った段階で、「利用者＝作成者」
> の環境は本当の意味で実現するのではないでしょうか。その時には、
> 利用者(＝作成者)は既存の雛形をいくつかつなぎ合わせて、自分の目下の
> 問題を簡単に解決している、という姿を私はイメージしています。
> "つなぎ合わせる" 作業を通して、利用者はそれと知らずにプログラミング
> 行為をしているというわけです。

> >>>> Web2.0時代のWikipediaを考えるならば、ある項目を引くと世界中の人々が
> >>>> ブログなどの中にばらばらに書いたその項目への記述を集めて表示する
> >>>> ようなものになるのでは?と夢想してます。
> >>>> そして、それができるようなハイパー・ブログ・サーバ(?)を作ろうと模索中。
> >>>> もちろん"Seaside上で"です。
>
> 私の場合 Wikipedia のよいところは、協調作業 (コラボレーション) にある
> と考えています。さまざまな人が互いの成果を確認し、評価し、その上で、
> 必要なら修正や追加をする、というプロセスを経て、個々の記事はより完成度の
> 高いものになり、またWikipedia 全体としては、より広い世界を網羅することに
> なっている、それがWikipediaそのものと考えています。
>
> ブログの集約という形になりますと、この協調作業という過程を経ることが
> できなため、個々の記事としてもサイト全体としても完成度の低いものになる
> のではないかと思います。

> Swimmyシステム自体はマルチエージェント開発実行環境ですが、その中のエージェ
> ントのプログラミングをEtoyでプログラムされたオブジェクトをさらに組み合わ
> せるという方法でやっているのでご紹介しました。
> 厳密に言うと高階とエージェントとは関係ありません。
> (宣伝に走って、混乱させてしまったかもしれません。すみません。)
>
> 結合力と考えると関数とマルチエージェントの間にオブジェクト指向が入ると思
> います。(オブジェクト指向とは計算をオブジェクトという単位で区切ってオブ
> ジェクト同士のメッセージのやり取りで計算を進める技術です。)
> マルチエージェントはメッセージのやり取りをさらに柔軟にしています。
>
> マルチエージェントの実用化にはおっしゃるとおりの問題があります。
> 現在それを解決する方向として具体的に進んでいるものの一つはFIPAというエー
> ジェント間コミュニケーションの標準規格化です。
>
> FIPAホームページ
> http://www.fipa.org/
>
> FIPAのとても詳しい説明。
> 日本語!チュートリアルつき!
> http://www.mamezou.net/AgentVillage/index.html
> (実はこれも宣伝です。注意;-)
>
> 個人的感想ですが、オブジェクト指向が出始めの頃「それって関数でできるじゃ
> ん」といわれていたようですが、現在のエージェント技術も同じような境遇にあ
> るように感じます。
>
> オブジェクト指向技術ではタイプやインターフェイスと呼ばれる仕組みを利用し
> て同型性をプログラミングに生かす方法が広く利用されていますね。
> マルチエージェント技術ではロール(役割)によって同型性を取り入れています。
> ぼくはこれをだんだんと「利用者＝作成者」環境に近づく過程だと感じているの
> ですが、これは意見の分かれるところでしょう。

> ぼくは信頼や完成度をどう評価するかという評価基準から変えてみようと思って
> います。「辞書とはこういうものだ」という今ある常識自体を疑ってみようとい
> う考え方です。
> ですから、「Wikipedia自体がどうなるか」を言っているのではありません。辞
> 書のように見えてまったく別の仕組み、もしくはぜんぜん辞書っぽくないけど辞
> 書の項目を調べるのと同じような効果があるものができないかと考えてます。
>
> たとえば、Web2.0という得体の知れない言葉を調べるとしたら、去年のの解釈と
> 最近1ヶ月の解釈では違っていたり、経済方面の人とIT方面の人ではまたぜんぜ
> ん違っていたりというのは当たり前です。古くて変わらない情報は辞書を調べれ
> ばいいけど、新しくて活発に議論されている情報のためのツールはほとんど無い
> というのが現状でしょう。
>
> 実はここまで書いて、大げさな言い方になってしまって困ってしまいました。
> とりあえずぼくがやれるのは単に新しいブログ・サーバを作ってみるだけという
> のが現状です。
> # こころざしは高く
> # 目標は低く

>> ぼくは信頼や完成度をどう評価するかという評価基準から変えてみようと思って
>> います。「辞書とはこういうものだ」という今ある常識自体を疑ってみようとい
>> う考え方です。
>> ですから、「Wikipedia自体がどうなるか」を言っているのではありません。辞
>> 書のように見えてまったく別の仕組み、もしくはぜんぜん辞書っぽくないけど辞
>> 書の項目を調べるのと同じような効果があるものができないかと考えてます。
>>
>> たとえば、Web2.0という得体の知れない言葉を調べるとしたら、去年のの解釈と
>> 最近1ヶ月の解釈では違っていたり、経済方面の人とIT方面の人ではまたぜんぜ
>> ん違っていたりというのは当たり前です。古くて変わらない情報は辞書を調べれ
>> ばいいけど、新しくて活発に議論されている情報のためのツールはほとんど無い
>> というのが現状でしょう。
>>
>> 実はここまで書いて、大げさな言い方になってしまって困ってしまいました。
>> とりあえずぼくがやれるのは単に新しいブログ・サーバを作ってみるだけという
>> のが現状です。
>> # こころざしは高く
>> # 目標は低く

> 話は戻りますが、((perl))プラグインやSeasideのことを
> いろいろ議論してきましたが、すごいサイトがオープンしましたね。
>
> YouOS
>   http://www.youos.com/
>
> ここでは、JavaScriptでクライアントアプリをWeb上で開発できるようです。
> もっとも、協調作業なのかどうかはわかりませんが、
> デフォルトChat機能が搭載されていることを考えると、
> 協調作業も技術的にはまったく問題ないみたいです。
>
> 世の中の進み方、早いですね。
>

> 横川さん
>
> こちらこそ、お付き合いありがどうございます。
>
> サイト拝見しました。(というかこれまでも見たことがあります)
>
> 役割で分担するエージェントと、
> 機能で分担するオブジェクトとでは、
> 決定的に違うのは何でしょうか。
> --
> 能動性/受動性 という点では、スレッドで動作する
> java.lang.Runnable なオブジェクトは、
> エージェントということになりますよね。
>
> 10年以上前ですが、所 真理雄 氏 が研究目的で、
> Smalltalk-80 を並列化して、Concurrent Smalltalk
> というものをつくってましたが、
> それに近いものなのでしょうかね。
> (ご存知ありませんよね)
> --
> インターフェースの汎用性が決定的な違いなのでしょうか。
> LISPのevalはS式という汎用データ形式を受け付ける
> 天蓋孤独なエージェントなのでしょうか。
> --
> あるいは、「S式を受け付け、能動的かつ協調的に機能する
> 複数のオブジェクトの集まり」というというところなのでしょうか。
>
> おおよそのところ、蟻の家族とか免疫細胞群
> (T細胞,B細胞,マクロファージ,...)という
> イメージだとは思いますが、
> --
> だとしたら、エージェント技術は、やはり、
> 一人の人(またはひとつの団体)が最初から役割を
> はっきりと決めた、役割分担のできた能動体の集団
> という形で実装されるのだろうと思いました。
>
> だれが自分の家族の一員か、フェロモン・触覚、あるいは、
> レセプターで確認しあって作業するというものになりますね。
>
> 家族がばらばらになると機能できない、、、
>
> モバイルエージェントとなると、誰かが号令をかけて、
> 一族が一斉に移動することになるんでしょうね。
>
>
> なんか、すごいですね。エージェントって。
>
> "Star Trek" にでてくる、Borg とか ナノプローブ みたいな
> ものを作ろうとしているようにも思えてきました。怖い感じも
> しますね。特に軍事目的で国家規模で開発すれば、今のコンピュー
> ターウィルスなんて赤子に思える技術なのでしょうね。
>
> ------
> 話は戻りますが、((perl))プラグインやSeasideのことを
> いろいろ議論してきましたが、すごいサイトがオープンしましたね。
>
> YouOS
> http://www.youos.com/
>
> ここでは、JavaScriptでクライアントアプリをWeb上で開発できるようです。
> もっとも、協調作業なのかどうかはわかりませんが、
> デフォルトChat機能が搭載されていることを考えると、
> 協調作業も技術的にはまったく問題ないみたいです。
>
> 世の中の進み方、早いですね。
>
>
>
>
> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> > Swimmyシステム自体はマルチエージェント開発実行環境ですが、その中のエージェ
> > ントのプログラミングをEtoyでプログラムされたオブジェクトをさらに組み合わ
> > せるという方法でやっているのでご紹介しました。
> > 厳密に言うと高階とエージェントとは関係ありません。
> > (宣伝に走って、混乱させてしまったかもしれません。すみません。)
> >
> > 結合力と考えると関数とマルチエージェントの間にオブジェクト指向が入ると思
> > います。(オブジェクト指向とは計算をオブジェクトという単位で区切ってオブ
> > ジェクト同士のメッセージのやり取りで計算を進める技術です。)
> > マルチエージェントはメッセージのやり取りをさらに柔軟にしています。
> >
> > マルチエージェントの実用化にはおっしゃるとおりの問題があります。
> > 現在それを解決する方向として具体的に進んでいるものの一つはFIPAというエー
> > ジェント間コミュニケーションの標準規格化です。
> >
> > FIPAホームページ
> > http://www.fipa.org/
> >
> > FIPAのとても詳しい説明。
> > 日本語!チュートリアルつき!
> > http://www.mamezou.net/AgentVillage/index.html
> > (実はこれも宣伝です。注意;-)
> >
> > 個人的感想ですが、オブジェクト指向が出始めの頃「それって関数でできるじゃ
> > ん」といわれていたようですが、現在のエージェント技術も同じような境遇にあ
> > るように感じます。
> >
> > オブジェクト指向技術ではタイプやインターフェイスと呼ばれる仕組みを利用し
> > て同型性をプログラミングに生かす方法が広く利用されていますね。
> > マルチエージェント技術ではロール(役割)によって同型性を取り入れています。
> > ぼくはこれをだんだんと「利用者＝作成者」環境に近づく過程だと感じているの
> > ですが、これは意見の分かれるところでしょう。
>
> --------------------------------------
> Let's start Yahoo! Auction  -  Free Campaign Now!
> http://pr.mail.yahoo.co.jp/auction/

> 横川です。
> すっかりSqueakネタから(Wikiからも)離れてますが、もう一言お許しください。
>
> 「エージェント」という言葉が多くの研究分野で異なった定義で使われて、くわ
> えて非常に夢にあふれているので、「マルチエージェント技術」についてたくさ
> んの誤解がうまれていると思いますので、ここで弁解を。。。
>
> 少なくともFIPAで定義しているエージェントは非常に限定された(ともするとツ
> マラナイ)ソフトウェア技術です。あえてそっけなく言うと「動的に入れ替え可
> 能なソフトウェア・コンポーネント」と表現できると思います。
>
> こう観るとソフトウェア・コンポーネントとあまり変わりません。その意味で現
> 在実用になっている技術と地続きの実直なソフトウェア技術だと思います。
>
> > 役割で分担するエージェントと、
> > 機能で分担するオブジェクトとでは、
> > 決定的に違うのは何でしょうか。
>
> これはいろいろな意見が出そうなところですが、ぼくは「開発者のマインドセッ
> ト(考え方)が違う」というところを第一に挙げたいです。
> 構造化技術で開発するときとオブジェクト指向技術で開発するときの開発者のマ
> インドセットは異なります。この違いが開発効率や安全性などさまざまな影響を
> 与えています。
> 同じように、マルチエージェント技術で開発するときのマインドセットも異なり、
> 開発にいろいろな(きっと良い)影響が出そうだと感じてます。
>
> では。
>
> On Thu, 13 Jul 2006 23:11:57 +0900
> "NAKATA, Shunsuke" <[hidden email]> wrote:
>
> > 横川さん
> >
> > こちらこそ、お付き合いありがどうございます。
> >
> > サイト拝見しました。(というかこれまでも見たことがあります)
> >
> > 役割で分担するエージェントと、
> > 機能で分担するオブジェクトとでは、
> > 決定的に違うのは何でしょうか。
> > --
> > 能動性/受動性 という点では、スレッドで動作する
> > java.lang.Runnable なオブジェクトは、
> > エージェントということになりますよね。
> >
> > 10年以上前ですが、所 真理雄 氏 が研究目的で、
> > Smalltalk-80 を並列化して、Concurrent Smalltalk
> > というものをつくってましたが、
> > それに近いものなのでしょうかね。
> > (ご存知ありませんよね)
> > --
> > インターフェースの汎用性が決定的な違いなのでしょうか。
> > LISPのevalはS式という汎用データ形式を受け付ける
> > 天蓋孤独なエージェントなのでしょうか。
> > --
> > あるいは、「S式を受け付け、能動的かつ協調的に機能する
> > 複数のオブジェクトの集まり」というというところなのでしょうか。
> >
> > おおよそのところ、蟻の家族とか免疫細胞群
> > (T細胞,B細胞,マクロファージ,...)という
> > イメージだとは思いますが、
> > --
> > だとしたら、エージェント技術は、やはり、
> > 一人の人(またはひとつの団体)が最初から役割を
> > はっきりと決めた、役割分担のできた能動体の集団
> > という形で実装されるのだろうと思いました。
> >
> > だれが自分の家族の一員か、フェロモン・触覚、あるいは、
> > レセプターで確認しあって作業するというものになりますね。
> >
> > 家族がばらばらになると機能できない、、、
> >
> > モバイルエージェントとなると、誰かが号令をかけて、
> > 一族が一斉に移動することになるんでしょうね。
> >
> >
> > なんか、すごいですね。エージェントって。
> >
> > "Star Trek" にでてくる、Borg とか ナノプローブ みたいな
> > ものを作ろうとしているようにも思えてきました。怖い感じも
> > しますね。特に軍事目的で国家規模で開発すれば、今のコンピュー
> > ターウィルスなんて赤子に思える技術なのでしょうね。
> >
> > ------
> > 話は戻りますが、((perl))プラグインやSeasideのことを
> > いろいろ議論してきましたが、すごいサイトがオープンしましたね。
> >
> > YouOS
> > http://www.youos.com/
> >
> > ここでは、JavaScriptでクライアントアプリをWeb上で開発できるようです。
> > もっとも、協調作業なのかどうかはわかりませんが、
> > デフォルトChat機能が搭載されていることを考えると、
> > 協調作業も技術的にはまったく問題ないみたいです。
> >
> > 世の中の進み方、早いですね。
> >
> >
> >
> >
> > ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> > > Swimmyシステム自体はマルチエージェント開発実行環境ですが、その中のエージェ
> > > ントのプログラミングをEtoyでプログラムされたオブジェクトをさらに組み合わ
> > > せるという方法でやっているのでご紹介しました。
> > > 厳密に言うと高階とエージェントとは関係ありません。
> > > (宣伝に走って、混乱させてしまったかもしれません。すみません。)
> > >
> > > 結合力と考えると関数とマルチエージェントの間にオブジェクト指向が入ると思
> > > います。(オブジェクト指向とは計算をオブジェクトという単位で区切ってオブ
> > > ジェクト同士のメッセージのやり取りで計算を進める技術です。)
> > > マルチエージェントはメッセージのやり取りをさらに柔軟にしています。
> > >
> > > マルチエージェントの実用化にはおっしゃるとおりの問題があります。
> > > 現在それを解決する方向として具体的に進んでいるものの一つはFIPAというエー
> > > ジェント間コミュニケーションの標準規格化です。
> > >
> > > FIPAホームページ
> > > http://www.fipa.org/
> > >
> > > FIPAのとても詳しい説明。
> > > 日本語!チュートリアルつき!
> > > http://www.mamezou.net/AgentVillage/index.html
> > > (実はこれも宣伝です。注意;-)
> > >
> > > 個人的感想ですが、オブジェクト指向が出始めの頃「それって関数でできるじゃ
> > > ん」といわれていたようですが、現在のエージェント技術も同じような境遇にあ
> > > るように感じます。
> > >
> > > オブジェクト指向技術ではタイプやインターフェイスと呼ばれる仕組みを利用し
> > > て同型性をプログラミングに生かす方法が広く利用されていますね。
> > > マルチエージェント技術ではロール(役割)によって同型性を取り入れています。
> > > ぼくはこれをだんだんと「利用者＝作成者」環境に近づく過程だと感じているの
> > > ですが、これは意見の分かれるところでしょう。
> >
> > --------------------------------------
> > Let's start Yahoo! Auction  -  Free Campaign Now!
> > http://pr.mail.yahoo.co.jp/auction/
>
> -- !
> Koji Yokokawa <[hidden email]>
>     http://yengawa.com/
>     ^self new!