ブロックを組み立ててプログラムを作ろう 39
ストーリー by GetSet
幼児にもプログラミングの楽しさが伝わるかも 部門より
幼児にもプログラミングの楽しさが伝わるかも 部門より
MIYU曰く、"LEGO「MindStorms」の
開発者でもあるヘンリック・ルンド教授が新しく開発した「I-BLOCK」
の事を、
ITmediaが紹介しています。
「I-BLOCK」は、普通のLEGOの4倍の大きさがある「LEGO Duplo」サイズの
ブロックにそれぞれ“PIC16F876”マイコン（1個数百円）と2つのシリアルポート、電源コネクタを組み込んだものです。
ブロックは、演算とコミュニケーションを担当するスタンダードブロック、
光・音・接触などの情報を得るためのセンサー類が付いた入力ブロック、
音や光などを出したり、動いたり、情報を表示するための出力ブロック、
電源が用意されていて、
普通のレゴブロック
のように「I-BLOCK」を組み合わせていく事で、「プログラム」が出来上がる様になっています。
記事では、ブロックを実際に組み合わせて計算をしたり、正しい綴りの練習をしたりする様子が紹介されていますが、
ブロックの組み合わせを変える事で「起きる事」を変えられるというのは
なかなか楽しそうに思えました。商品化はまだ未定のようですが、出たら欲しい気がします。"
関連研究 (スコア:4, 参考になる)
関連研究どぞー
Re:おなじみ未踏ユースでも (スコア:1, 興味深い)
なんだかスゲーかわいそう。コンセプトはホントそっくりだなぁ。
結構行われてる研究なんだろうか。
Re:関連研究 (スコア:1)
製品だが (スコア:1)
ほすぃ
思わず想像しちゃうんだが (スコア:3, おもしろおかしい)
「朝起きたら、昨晩までいじっていたI-BLOCKの複雑な構成を作ったかたまりが、自分で空いてるブロックを勝手に持ってきて、増えてるんですよ。おまけに、私の作った構成から、自分自身で構成を勝手に変更して、進化しているみたいなんです。いやね、このままどうなるか楽しみでもあって、明日もこのままにしておこうと思うんですけどね。でもI-BLOCKの「彼」は、いったいなにを考えているんでしょう？今度音声インターフェイスブロックを接続して聞いてみたいです。」
このA氏は一週間後突如として自室の中で消息が途絶えたと言う。
# なーんてね。
Re:思わず想像しちゃうんだが (スコア:0)
やられたー (スコア:3, 参考になる)
やられました。
今回のプロジェクトではマイコンを組み込んだブロックのシミュレータを作成して、そのフレームワークを利用したアプリケーションを作成しているのですが、特にブロック同士が通信しあい、分散システムを作るって点は我々にはないおもしろさです。
実際にブツも作りたいなーと思っていたところこれですか。
こいつも、物理接続の部分でやはり信号線がネックになってる感じですね。
負けないように研究を続けたいと思います。
Re:やられたー (スコア:4, 参考になる)
思いますが、接続の自由度を落さないとロバストなものを作るのは難しいと
いうのはどこも同じようです。
ただ、この話は結局、竹内先生が述べておられるように、構成要素を
何にするかが肝であり、かつ大変困難な問題だと思います。
I-Blockの記事中で触れられている、ニューラルネットワークに基づいた
光追跡を行う車は、元ネタは Valentino Braitenberg の
"Vehicles" かと思いますが、単純な機構でMindstormを制御しようと
いうのであれば、こういう解もあると思います。Braitenberg's Vehicles
については、A.K. Dewdney「Computer Recreations」に記事がありますので
参考にしてください。Scientific American 1987年です。(多分5月)
日経サイエンスの「別冊サイエンス」にも収められていますが、絶版です。
Re:やられたー (スコア:1)
組み上げると色んな物になる物を是非ともお願いしたいです。
オブジェクト指向プログラミング (スコア:2, 興味深い)
だけではアレなので、ちょっと補足を。
各マイコンをプログラミングできるなら、プログラムの構造が目に見えますね。
Re:オブジェクト指向プログラミング (スコア:2, すばらしい洞察)
Re:オブジェクト指向プログラミング (スコア:1, おもしろおかしい)
Re:オブジェクト指向プログラミング (スコア:2, 興味深い)
オブジェクト指向って、知らない人(^^;には、
「機能」がオブジェクトになっているもの、みたいに捉えられてる節が有るけど、
実際は(そういうのも全く駄目とまでは言わないけど、どちらかってーと)
機能じゃなく「状態」がオブジェクトになってるんだよね。
つまり機能じゃなく機能を被る側のものがオブジェクト。
んだから、データを保持するため(だけ)のブロックとかも本来欲しいんですよね、
もしオブジェクト指向なブロックを作るっていうならば。
まあ、今回のコレがオブジェクト指向「でなければならない」ってわけではないけど。
とりあえず表をぱっと見た範囲では、「機能(演算または入出力)」のブロックばかりで、
状態はせいぜい添え物って扱いみたいですね。個人的趣味(OOPオタ)としてはちょっと残念。
ちなみに、我々プログラマが何時も戦っている(=バグ退治してる)対象は、
大抵の場合、機能ではなく状態だと思います。
機能って、それこそこんなブロックにするのも簡単(ユーザにとって)なくらいに
直感的に判りやすい(だからそれを並べるだけならバグも入りにくいし子供も遊び易い)んだけど、
状態はそうでもないみたい。
だけど状態ってプログラムには必須なんだよねえ。
というわけで、ちと先走るけど、真のハッカーを養成するためのギブス^H^H^Hブロックを作るならば、
状態ブロックと、その状態を見るためのテスターっていうか「デバッガ」なブロックとが
欲しいような気がします(^^;
＃あとはクロージャっていうかBlockかな。そうすれば(Smalltalk風にやれば)IF文が作れるから。
＃あと、電源ぶっこ抜いたらどうなるのかな？
＃フラッシュメモリとかを少々使って、「状態」を電源抜いても覚えてるブロック、なんてのが有ったら面白そう。
＃まるでContinuationじゃん(^^;
さて。今回のこれ、どっちかってーと、パイプラインアーキテクチャじゃないかな。
UnixのPipeでもお馴染みのアレです。
個々のブロックにCPUが有るってのは驚きだけど、
Unixで各プロセスが独立したCPU Time(=仮想的なCPU)を割り当てられてるのを見ると、
まあそんなもんかなという気もしてきます。
ええと。自分の経験の範囲で似てるものっていうと、やっぱり
MAXやPureData [cool.ne.jp]の路線かなあ。
足し算引き算をしてみせる辺りなんか、正にソックリ。
オブジェクト指向との距離の具合なんかも(^^;まさにそっくり。
こういうソフトを直接手で弄れるようにしたら今回のブロックになった、という印象。
Re:オブジェクト指向プログラミング (スコア:2, おもしろおかしい)
如何に美しく積み上げるかが肝なわけです。
Re:オブジェクト指向プログラミング (スコア:2, おもしろおかしい)
下のほうから引き抜いて、崩れたら負け。
# あれ?
Re:オブジェクト指向プログラミング (スコア:1, すばらしい洞察)
#そこまでデカいもん作らんか
Re:オブジェクト指向プログラミング (スコア:3, 参考になる)
再利用って、出来るんだろうか？
作り次第だけど、もしかして出来ないかも？
というのは、機能(であるブロック)に、恐らく状態がべったり張り付いているので、
1つの処理構造を複数の処理から呼ぶことが出来ない、んじゃないかと。
実際のプログラムでは、同じ関数を二度呼んでも、ローカル変数とかの「状態」は
毎回新たに作られていて、しかも互いに干渉しないわけで。
まあ、「再帰」を諦めればいい、という話もあるけど。
＃「MidiPipe」を作ったときに、
＃自作のPipeの組み合わせの「関数」化を行なう仕組みを導入しようとして、
＃はたと困ったのでG7
＃複数の場所から呼ばれても、状態が混線せず、returnも正しく各々の呼び元に返る、
＃という仕組みが必須であることを想定していなかったので、お手上げ。
＃いい勉強になりました(^^;
＃ちなみに大きいお友達はこちらでお勉強 [dreamhost.com]するのがGoodかも。
Re:オブジェクト指向プログラミング (スコア:2, 参考になる)
再帰呼び出し等で必須の「再入(reentrant)」可能かどうかの話とは
関係ないのではないですか。同一のランタイムユニットによる再利用
というよりかは、異なるユニット間で同じコードを改変する事なく
利用できるかどうかが「再利用」性に関わるのではないかと。
(システムの設計上、両者が不可分である場合もあるでしょうが)
I-Blocksの件においては、そもそもデータフローに近い設計なので
比較のしようがありませんが、仮にブロックのある塊を「オブジェクト」
だと思うにしても、それらは当然のようにインスタンスなので、
再入も再利用もないもんだ、と思います。仮に、その塊を「関数」あるいは
「手続き」だと思うとすれば、再入可能にする事は不可能ではないかも。
ただ、結線を工夫しないと難しいかな。(入口:出口の対を複数持てる
ようにすれば良い。ただし排他制御が必要になる)
Re:オブジェクト指向プログラミング (スコア:1)
Re:オブジェクト指向プログラミング (スコア:1)
うーん。まずこの話は(前に書いたように)OOPの話じゃないんですよね。
あと、OOPでだって再帰をやりますから
(OOPかどうかと、再帰とかがあるという意味での手続き型かどうかと、は事実上直交なので)、
「OOPの話で」という限定にはあまり意味がないと思っています。
>同一のランタイムユニットによる再利用
>というよりかは、異なるユニット間で同じコードを改変する事なく
>利用できるかどうかが「再利用」性に関わるのではないかと。
実体プログラミングの場合、
Cut＆Pasteは出来てもCopy＆Pasteは出来ない、つまり
普通の意味での再利用をしようとしたら元の回路をぶっ壊さないとならない(^^;ので、
それを再利用と呼ぶのは、なんか違うような気がしています。
＃一旦手にしたものを壊すのが凄く苦手なのでG7
＃その点、一般的なソフトウェアは、真の意味で壊さずに済むんで、凄く助かっています。
>仮にブロックのある塊を「オブジェクト」
>だと思うにしても、それらは当然のようにインスタンスなので、
>再入も再利用もないもんだ、と思います。
Smalltalkみたいなやり方を見ていると、
インスタンスの再利用という概念もあるような気がしてきます。
Smalltalkとまで言わなくても、永続オブジェクトとかオブジェクトを(R)DBに保存するとか
という世界でも、似たような感じかな。
狭義の「プログラム」が終わっても尚消えずに残るようなオブジェクトには、
それ自体に「再利用」という道が拓けてるんじゃないかと。
>ただ、結線を工夫しないと難しいかな。(入口:出口の対を複数持てる
>ようにすれば良い。ただし排他制御が必要になる)
排他するか、陰でコッソリと"インスタンス"を複数作るか、どっちかですね。
Re:オブジェクト指向プログラミング (スコア:1)
あんまりデカい物でなくても、落とすとコードがバラバラになっちゃいそうですね。
紙カードの束を落として行単位でばらばらになるってのを、オブジェクト単位で再現出来る(笑)。
＃紙カード使ったことない世代なのでID
大人の電子ブロック (スコア:2, 興味深い)
アルゴリズムも見たい、データも見たい (スコア:2, 興味深い)
ブロック間は電気信号をやりとりするのだけど、この方式だと、
データフローにした場合はデータが見えない、アクターモデルに
するとメッセージが見えない、という事になります。
実用性やロバスト性を考えるとそうせざるをえないのかもしれま
せんが、どうせなら「どっちも見たい」と私は思うのです。
で、インターネット物理モデル [eto.com]のようなやり方で
それが実現できないかと思うのですが、どないなもんでしょう。
仕掛が大きくなってしまうのは不可避かな。家庭用玩具にはなり
ませんかね。
Re:アルゴリズムも見たい、データも見たい (スコア:1)
コンピュータ物理モデルを作りたいという話を前からしていました。
かなりいいところまでプランニングしていたんだけど。
家庭用インターネット物理モデルという案も前から出てました。
Re:アルゴリズムも見たい、データも見たい (スコア:1)
そうなんですよね。
上のほうで俺が書いた「オブジェクト指向とはちょっと違う」
っていう話題と同じでして、データ(もしかしてそれこそがオブジェクトかも知れない)は
ブロックの下(?)を流れ去るだけで、俺らの目には触れない。
枯れ川は目に入るけど水が(一見)流れてなくて寂しい、みたいな。
＃ところで、オブジェクト指向を「使って作った」技術ではあるかも知れないが、
＃今度はそれを使って表現できるものは、オブジェクト指向とは限らない、ってものが
＃世の中には一杯有ります。一例でJDBCみたいなRDBの単なるラッパーライブラリとか。
多分、プログラムをこういうブロックみたいな(物理的な)媒体で表現する場合、
データだのなんだのみたいな「動的な(動的に生成／消滅する)」ものを
どう表現するか、が鍵になるんだと思います。
ノイマン式(だっけ)計算機の中では、静的なコードと動的なデータが渾然一体となって動くんだけど、
同じノリはブロックで表現するのがなかなか大変そう。
＃というか、渾然一体と決別できるなら、ノイマン(だっけ)式を超えられたことになっちゃうぞ(^^;
>で、インターネット物理モデル [eto.com]のようなやり方で
手元のブラウザではその頁が旨く表示されなかったんで推測ですが、
「キロバトル」という言葉(NHKのお笑い番組のあれ)を思い出しました(^^;
画面上で配線っぽい行為をすることでプログラミングになる、というタイプの言語(?)の場合、
それらのうち幾つかは、データが流れたときにそれが何らかのかたちで「見える」
ように仕組まれているもの、があるようです。
どうするといいんでしょうねえ。
繋ぎ目のところに「今こんなデータ通ったぜ」とLED光って示す、みたいな感じとか？
あと、前にも書いたけど、デバッガの発想は必要かも。
デバッガってのは、任意の個所のデータを見ることが出来るってのと、
あと、デバッガで表示できるように処理を一時停止できる機能が有る、っていうこと。
つまり、今ココラへんまでデータが着てるはずだから、ちょっと止まって、見せてね、と。
プログラムは本来光の速さで動くんだけど、それを敢えて遅くするのがデバッガ(の1つの面)なんだよね。
で、ついでに。
実のところ日ごろ思っているんだけど(^^;、デバッガに、
「停止」だけじゃなく「スロー再生」モードがあればいいんじゃないかな？
何を再生するかってーと、データの流れ(や変容)を、です。
今ここ通ったとか、こう変化したとか、がゆっくりと目視できるってのが、よろしいんじゃないかと。
人間(お子様含む)の目は、ほどほどの遅さのものの動きを追うのが得意(^^;なので、
従来よく有るように逐一止めるスタイルより、このほうが便利なときも有るかもだ？？？
Re:アルゴリズムも見たい、データも見たい (スコア:1)
そんな貴殿にgrind crank [jargon.net]
# これなら役にたつかもだ
建設ロボット (スコア:1)
って、知らない人が多そうだ。 [artdink.co.jp]
ブロックで (スコア:1)
1を聞いて0を知れ!
Re:ブロックで (スコア:1)
Re:ブロックで (スコア:1)
1を聞いて0を知れ!
Re:ブロックで (スコア:1)
＃ガワはどうでもいいから、
＃中身つまり計算機のキモの部分がブロックでないと
＃食い足りないのでG7
Mindstormといえば (スコア:1)
http://jpbrown.i8.com/cubesolver.html
カルネージハート (スコア:0)
Swordfishでの CAD環境 (スコア:1)
謝々々々 台湾宮廷料理海味館 名●屋市熊の前二丁目 ( MiniStop 対面 )
Re:カルネージハート (スコア:1)
# 今更続編が出ているのに気づいて注文してみたり。
Appleが提唱してたOpenDocとは (スコア:0)
Re:Appleが提唱してたOpenDocとは (スコア:1)
今回のブツは一種の知育玩具で、どちらかといえば電子ブロック [gakken.co.jp]に近いと思います。
オフトピごめん（Re:Appleが提唱してたOpenDocとは） (スコア:1)
ではないかと。
Apple + IBM 版の OLE ってとこ (今は亡き？) ですかな。