Smalltalk › 日本語 (Japanese)

[Squeak-ja: 4013] 非集中システムとScratchについて (was: Re: オープンソースカンファレンス 2008 Tokyo/Fall)

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Kazuhiro ABE-3

[Squeak-ja: 4013] 非集中システムとScratchについて (was: Re: オープンソースカンファレンス 2008 Tokyo/Fall)

こんにちは、阿部です。

2008/10/11 14:11 Koji Yokokawa <[hidden email]>:
> Scratchの資料は良くまとまっていて大変参考になりました。

ありがとうございます。

> P.23
> 情報教育用としては
> - 癖があるので注意
> - 並列非集中システムを志向
>
> という部分はどういう意味なのでしょうか?

一般的なプログラミング教育では、中心となるメインルーチンを想定することが多いように思います。それをサブルーチンに分割、階層化したとしても、基本的にはフローチャートに書けるようなプログラムでしょう。

Scratchの場合、そもそも中心となるものが存在せず、独立したスプライト(オブジェクト。Etoysのモーフ)が複数個存在します。スプライトには名前がありますが、スクリプト(メソッド)からは参照できないため、特定のものを明示的に指定することはできません(いくつかの属性値参照を除く)。つまり、スプライト同士が直接やりとりすることはありません。
スクリプトにも名前がないので、特定のものを指して起動することもできません。スクリプトを起動するにはイベントや名前付きのブロードキャストを用いますが(Scratchはこの名前をメッセージと呼ぶ)、リスナ(依存物)にはすべてのスプライトが自動的に登録されるため、同じメッセージを待つスクリプトが無条件で同時に反応し並列で動きます。このメッセージは定数で変数を使うこともできません。また、行きっぱなしでリターンしないのでサブルーチンのようには使えません。

このような仕様から考えられるのは、そもそも中心がなく、均質で対等なオブジェクトが勝手に振舞っているように見えて、全体としては自己組織化されて機能するような非集中システムです。
Etoysにもこの傾向はあるのですが、モーフやスクリプトには名前、モーフには親子関係があり、階層的に作ることもできます。Scratchの作者であるレズニックさんはStarLogoの作者でもあり、そのあたりがさら推し進められているように感じました(ただし、扱えるスプライト数は実用上数十個で、スクリプトからスプライトの生成消滅を制御できない)。
がんばれば中央集権的で階層的なプログラムも書けなくはないのですが(たとえば、ステージ(Etoysのワールド)は例外的な存在)、かなり不自然になります。以上のようなことから、従来のような情報教育にScratchを使うときは注意が必要だろうという意味で書きました。これは制御構造にwhileがあるとかとは別の話です。

もちろん、レズニックさんやアランさんは、本来は非集中的なプログラミングこそが自然なのであって、子供にも分かりやすいと考えていると思います。

非集中システム, Mitchel Resnick (著), 山本順人 (翻訳), 西岡知之 (翻訳), コロナ社, 2001/08,
ISBN 4339023868

アラン・ケイの「Is "Software Engineering" an Oxymoron?」
▼ What is it like to learn the new ideas?
http://d.hatena.ne.jp/sumim/20080806/p1

//abee
--
阿部和広 EMAIL [hidden email]

Toshiyuki Takeda

[Squeak-ja: 4019] Re: 非集中システムとScratchについて (was: Re: オープンソースカンファレンス 2008 Tokyo/Fall)

武田です。

私の大学を紹介していただきありがとうございました。
1.3はまったく試していないので勉強になりました。
Pythonと連携できるのですか。それはうれしい

さて、最近はVisualBasicが教えられているところも多く、
イベントドリブンを経験している生徒も増えています。
シーケンシャルではないプログラミングは、教育現場でも
受け入れられやすくなっている気がします。

また、予備知識のない学生にとっては並行性はそもそも
自然なものです。動くおもちゃの制御を順列にしか
記述できないCricket LOGOで書くのは、彼らにとって
なかなか大変な作業です。

Etoysにくらべて、できることが少なくなったと思う人も
おられるでしょうが、安定性も含めて、かなり教えやすい
環境です。よくできたサンプルが添付されていることも
助かります。

Pythonと連携できるとなると、1台のPCで完結しない
「非集中」型のプログラムが書けるようになるかもしれませんね。

武田俊之

Koji Yokokawa-3

[Squeak-ja: 4022] Re: 非集中システムとScratchについて (was: Re: オープンソースカンファレンス 2008 Tokyo/Fall)

In reply to this post by Kazuhiro ABE-3

横川です。

手続き型プログラミングの教材としてはちょっと使いにくいということですね。
フラグと変数によって黒板モデルを実装してあると見ると、とても興味深いです。

「非集中システム」も面白そうですね。StarLogoの本ですか?

On Sat, 11 Oct 2008 22:27:19 +0900
"Kazuhiro ABE" <[hidden email]> wrote:

> こんにちは、阿部です。
>
> 2008/10/11 14:11 Koji Yokokawa <[hidden email]>:
> > Scratchの資料は良くまとまっていて大変参考になりました。
>
> ありがとうございます。
>
> > P.23
> > 情報教育用としては
> > - 癖があるので注意
> > - 並列非集中システムを志向
> >
> > という部分はどういう意味なのでしょうか?
>
> 一般的なプログラミング教育では、中心となるメインルーチンを想定することが多いように思います。それをサブルーチンに分割、階層化したとしても、基本的にはフローチャートに書けるようなプログラムでしょう。
>
> Scratchの場合、そもそも中心となるものが存在せず、独立したスプライト(オブジェクト。Etoysのモーフ)が複数個存在します。スプライトには名前がありますが、スクリプト(メソッド)からは参照できないため、特定のものを明示的に指定することはできません(いくつかの属性値参照を除く)。つまり、スプライト同士が直接やりとりすることはありません。
> スクリプトにも名前がないので、特定のものを指して起動することもできません。スクリプトを起動するにはイベントや名前付きのブロードキャストを用いますが(Scratchはこの名前をメッセージと呼ぶ)、リスナ(依存物)にはすべてのスプライトが自動的に登録されるため、同じメッセージを待つスクリプトが無条件で同時に反応し並列で動きます。このメッセージは定数で変数を使うこともできません。また、行きっぱなしでリターンしないのでサブルーチンのようには使えません。
>
> このような仕様から考えられるのは、そもそも中心がなく、均質で対等なオブジェクトが勝手に振舞っているように見えて、全体としては自己組織化されて機能するような非集中システムです。
> Etoysにもこの傾向はあるのですが、モーフやスクリプトには名前、モーフには親子関係があり、階層的に作ることもできます。Scratchの作者であるレズニックさんはStarLogoの作者でもあり、そのあたりがさら推し進められているように感じました(ただし、扱えるスプライト数は実用上数十個で、スクリプトからスプライトの生成消滅を制御できない)。
> がんばれば中央集権的で階層的なプログラムも書けなくはないのですが(たとえば、ステージ(Etoysのワールド)は例外的な存在)、かなり不自然になります。以上のようなことから、従来のような情報教育にScratchを使うときは注意が必要だろうという意味で書きました。これは制御構造にwhileがあるとかとは別の話です。
>
> もちろん、レズニックさんやアランさんは、本来は非集中的なプログラミングこそが自然なのであって、子供にも分かりやすいと考えていると思います。
>
> 非集中システム, Mitchel Resnick (著), 山本順人 (翻訳), 西岡知之 (翻訳), コロナ社, 2001/08,
> ISBN 4339023868
>
> アラン・ケイの「Is "Software Engineering" an Oxymoron?」
> ▼ What is it like to learn the new ideas?
> http://d.hatena.ne.jp/sumim/20080806/p1
>
> //abee
> --
> 阿部和広 EMAIL [hidden email]
>

-- !
Koji Yokokawa <[hidden email]>
http://www.yengawa.com/
^self new!

Kazuhiro ABE-3

[Squeak-ja: 4023] Re: 非集中システムとScratchについて (was: Re: オープンソースカンファレンス 2008 Tokyo/Fall)

こんにちは、阿部です。

2008/10/12 20:20 Koji Yokokawa <[hidden email]>:
> フラグと変数によって黒板モデルを実装してあると見ると、とても興味深いです。

そういう見方もできるのかもしれません。
もともとレズニックさんは人工知能の研究をしていましたし、最も影響を受けた本のひとつとしてホフスタッターのGEBを挙げていたりします。

> 「非集中システム」も面白そうですね。StarLogoの本ですか?

はい、そうです。
これは"Turtles, Termites, and Traffic Jams: Explorations in Massively
Parallel Microworlds"の邦訳なのですが、最近まで気付きませんでした。

//abee
--
阿部和広 EMAIL [hidden email]

Kazuhiro ABE-3

[Squeak-ja: 4024] Re: 非集中システムとScratchについて (was: Re: オープンソースカンファレンス 2008 Tokyo/Fall)

In reply to this post by Toshiyuki Takeda

こんにちは、阿部です。

2008/10/12 12:02 Toshiyuki Takeda <[hidden email]>:
> 私の大学を紹介していただきありがとうございました。
> 1.3はまったく試していないので勉強になりました。
> Pythonと連携できるのですか。それはうれしい

実はまだScratch Networking Protocolは実際に試していません。
直接Smalltalkをいじるのではなく、これを介して拡張すべきなのでしょうね。

> さて、最近はVisualBasicが教えられているところも多く、
> イベントドリブンを経験している生徒も増えています。
> シーケンシャルではないプログラミングは、教育現場でも
> 受け入れられやすくなっている気がします。

なるほど。

> また、予備知識のない学生にとっては並行性はそもそも
> 自然なものです。動くおもちゃの制御を順列にしか
> 記述できないCricket LOGOで書くのは、彼らにとって
> なかなか大変な作業です。

これはまったくそう思います。

> Etoysにくらべて、できることが少なくなったと思う人も
> おられるでしょうが、安定性も含めて、かなり教えやすい
> 環境です。よくできたサンプルが添付されていることも
> 助かります。

非常に大雑把なたとえですが、アニメーションを考えたときに、アニメーションを作る仕組みが重要なのか、アニメーションを使うことが重要なのかという違いがあるかもしれません。
Etoysにおける「入れ物」は重要な概念ですが、単にアニメーションをしたいだけのときには必要なステップが多すぎるかもしれません。Scratchであれば、最初からオブジェクト(スプライト)が複数の画像(コスチューム)を持てるので、単にこれを切り替えるだけです。
もちろん、例外を言えば、Scratchにはスライダがないから作らないといけないとか、Etoysでも「本」を使えば簡単にアニメーションできるとかあるわけですが、全体としての傾向はあります(simplicityに対する考え方の違い)。
気をつけないといけないのは、Scratchは決して絵本やゲームしか作れないわけではないとうことです。言語としてのポテンシャルはメタを除いてEtoysとほぼ同じです。22万個の公開作品の内、9割は他愛無いものかもしれませんが、残りの1割にすごい作品があります(良い悪いという話ではなく)。適切なたとえかどうか分かりませんが、スーパーサイエンスキッズ級がごろごろ見つかる感じです。
もし先入観やこだわりからScratchを試さないとすれば、それは損だと思います。

> Pythonと連携できるとなると、1台のPCで完結しない
> 「非集中」型のプログラムが書けるようになるかもしれませんね。

なんとなくですが、いままで研究レベルで色々やってきたことを、軽い感じで実用に持ってきたような気がします。

//abee
--
阿部和広 EMAIL [hidden email]