RAD

Link: RAD.

RAD is a framework for programming the Arduino physcial computing platform using Ruby. RAD converts Ruby scripts written using a set of Rails-like conventions and helpers into C source code which can be compiled and run on the Arduino microcontroller. It also provides a set of Rake tasks for automating the compilation and upload process.

CBCNETでも紹介されてあちこちで話題になっている増田さんのaction-codingでも再確認することができたのですが、Rubyとハードウェアの組み合わせというのは、ハードウェアのスケッチブックとしてとても使いやすいものになる可能性を秘めています。

このRADに関しては「Unnature's changelog - Ruby Meets World」からリンクされているスライドでの説明がわかりやすいと思うのですが、ArduinoのスケッチをRubyで記述できるようにしたものです。内部的にはruby2cというトランスレータがRubyで書いたコードをCに変換し、それをArduinoボードにアップロードする、というものです。

現在でも積極的に開発が継続されているようで、Arduino 10で用意されているAPIの大部分がサポートされているようです。サンプルとして紹介されているコードをみると、確かにCで書いた場合と比較して疑似コードに近い感じで書けてよさそうです。しかし、このアプローチはArduino（の言語であるWiring）とRubyの両方を知っている人にとっては効率よくコードを書くことができて有用だと思うのですが、初心者向けかというと意外とそうではない気がします。結局のところ、ベースになっている言語を理解していないと、その上で何かを書くといっても書き進めることができません。これはJRubyなどにも共通する問題なのだと思いますが、JRubyの場合にはRuby on Railsをライブラリ的に利用するという用途には問題無いのかもしれません。

とはいえ、こうしたアプローチには大きな可能性があると思っています。Rubyは動的で新しさと古さの（保守性というと意味が違ってしまうのでこの表現にします）バランスがとても良くとれた言語だと思いますし、Chris PineのLearn to Program（リンク：西山さんによる日本語訳）のような素晴らしいプログラミング入門書もあります。ウェブアプリケーションを作るのが目的であれば、こうした入門書でデータ構造やアルゴリズムの扱い方に関してある程度スキルを積んだらRailsを使ってみる、という感じでいいのかもしれません。しかし、最近公開された久保田さんがインタビュー記事「工学と音楽を背景とした、アートとコンピュータの新たな関係」で指摘されているように、デザインやアートといった表現系では少し状況が異なります。

「デザイン・バイ・ナンバーズ以降のプログラミングのポイントは、プログラミングを学ぶ順序が変わったということです。それ以前は、プログラミングを学ぶ際には、データ構造やアルゴリズムといった数理的なところから入るのが常でした。例えばソーティングのアルゴリズムであるとか、名簿管理のためのデータ構造などから入っていったわけです。それに対して、表現のためのプログラミングの教え方は、まずは点や線を描く、次に、その点や線を動かしてみる、そして動くことでどう見え方が変わるのかを考えてみる。その次はインタラクション、マウスやキーボードで点や線の動きや色を変化させてみる。そうした順序でプログラミングを学びながら、手と鉛筆でデッサンをすることとプログラミングで描くということが、どこが同じでどこが違うのかを内面から考えてみよう、というわけです」

ここで指摘されているように、デザインやアートといった表現系でのプログラミングにおけるプログラミング言語には、データ構造やアルゴリズムを表現できるだけでなく、グラフィックやサウンドも表現できることが必須です。Processingが広く受け入れられた理由の1つがここをきちんとおさえていたところにあると思います。Rubyの場合には、今までにもさまざまなメディア用ライブラリがありましたが、Processingのようにシンプルでパワフルなものというのはなかなかなかったと思います。こうした状況に対して、JRubyという新しい流れと共にaction-codingのような使いやすいブリッジがでてくることで、スケッチのための新しい画材としてのRubyという選択肢はかなり現実味を帯びて来たと思うのです。

最後は少し話がそれてしましましたが、action-codingを使った時に改めて体験しましたが、プログラムの動的書き換えというのは、「描いては消し、また描いては消す」を繰り返すスケッチには必須の要素だと思います。RADの場合、Rubyという動的言語を使いつつも、実際に動作するまでには静的にコンパイルされてしまうため、この要素は失われてしまっています。この点に関しては、「Ruby meets World」でも今後の課題として次のように取り上げています。

Dynamic reprogramming of the Arduino (FPGA style)

この課題をどのように解決するのかはかなりハードルが高いように思うのですが、今後の大きな流れになっていくのではないかという気がしています。

これに関しては自分でも考え続けたいと思っていて、Funnelの将来的なビジョンとしてぼんやりと次のようなものを思い描いています。

• I/Oボード上でなんらかの動的言語を動作させる（RubyのサブセットやPyMiteなど）
• エディタはPC上で動かしつつ実際のコードはI/Oボード上で動作する
• I/Oボードの入出力の状態はPC上で視覚的にモニタできる
• もちろん切り離してスタンドアロンでも動作可能

とりあえずのproof-of-conceptデモであればGumstix上でRubyを動作させたものでも十分に可能だと思いますので、Sketching in Hardware 3までの課題としたいと思います。