mruby Advent Calendar 2016の16日目の記事です。

##おことわり
私自身はmruby Advent Calendarに参加されている他の方々のような歴戦のmrubistという訳では無く、そもそもRubyをさわり始めてまだ一年未満のぺーぺーではあるのですが、そんなぺーぺーの感じたことを記事にしたいと思って書いています。
何か深みのある蘊蓄だとかそういった事は申し訳ありませんが書けません、ご了承下さい。

##はじめに
mrubyというものは組み込み用のスクリプト言語として作成された物であり、本来はSoCやワンチップマイコン等の所謂組み込みシステムに使われる事が多いと思いますが、私はあえてアプリケーションの拡張用スクリプト言語として使用しています。
組み込みシステム向けのスクリプトなだけあって、コンパクトで省メモリな為アプリケーションに組み込むにも都合が良いかと思います。

この分野では、ここ10年位ではLuaが有名ですが、私はmrubyを一度試してみるのも良いのではないか、と思います。
以下に私がmrubyについて、アプリケーション拡張用スクリプト言語として使用したときに感じたことを記します。

#簡単に、理由を

##1. Rubyであるということ

mrubyはとても省メモリな言語でありながら、Rubyプログラマがほぼ迷わないでスクリプトを書ける程度にはRubyです。
Rubyというのは純粋なオブジェクト指向言語であり、オブジェクト指向言語ってのは大抵の場合メモリ食いなのですが、mrubyはとてもコンパクトでありながら、ほぼ完全なオブジェクト指向言語として作成されています。

Luaでスクリプトを組んだことがある人ならわかると思いますが、Luaはちょっとオブジェクト指向「っぽく」書く事は出来ますが、Lua自身がオブジェクト指向をサポートする機能を色々と持っている訳では無いのでちょっと工夫が要ります。
それでなくともRuby程純粋にオブジェクト指向している言語というのは結構珍しく、そのRubyの仕様の殆どを受け継いでいるmrubyは純粋に好奇心が沸き立つ物です。

アプリケーション拡張用のスクリプト言語として使う場合、スクリプトを書くのはアプリケーション本体を書いたプログラマとは別であるケースが多くなるのですが、エンジニアではない人間がスクリプトを書くようなケースにおいて、Rubyは比較的書きやすい言語だと思いますし、そういう点でもお勧めです。
(実際、RGSSを書く人とかはエンジニアではない人が多いように感じます)

そしてRubyであるということは、世の中にある多くのサンプルコードがかなり役に立つということです。
サンプルコードという意味でいえばLua等もかなりの数がありぶっちゃけ必要十分ではあるのですが、サンプルの応用のしやすさという点においてはRubyに分があるように思われます。

##2. 配布されているビルドシステムに、既に言語拡張の仕組みが整備されている

アプリケーションに組み込む言語というのは、その言語の標準機能だけで事足りることはまずなくて、通常は言語に対して何らかの拡張を施します。
拡張のやり方は色々あって開発者の好みや文化で取捨選択される訳ですが、mrubyには標準で拡張のシステムの１つの方法が準備されています。
mrbgemsと呼ばれるそのシステムは、mruby言語に対する拡張ライブラリのシステムなのですが、mrubyに標準で用意されているライブラリもmrbgemsで実装されている為、mrubyの能力のカスタマイズ性がとても高くなる一因となっています。
Rubyはオブジェクトインスタンスに対してあとからメソッドを足したりすることが出来るので、標準のライブラリをカスタマイズするためのライブラリをmrbgemsで実装して、特定の環境の時のみ使用する、等が簡単にできます。
言語を拡張する理由というのは色々とありますが、大抵の場合アプリケーション毎にそれらの理由は違う為、アプリケーション拡張用の言語というのはアプリケーション毎のカスタマイズが必須になる訳です。
LuaなんかだとLuaの処理系自体は同一で、アプリケーション側でLuaの拡張機能を用意してバインドしてLuaから使えるようにし、それでアプリケーション毎のカスタマイズをするのが一般的かと思いますが、mrubyの場合はそのやり方＋mrbgemsで多くの環境で使えるけれど、カスタマイズしたい機能なんかを用意する事が簡単になります。
(Luaでも、本体をカスタマイズしたりする事はあるかと思いますが、拡張機能とLua本体を分離するのがちょっと面倒です)
例えば社内で共通のmruby用拡張ライブラリがあり、それは最初からmrbgemsとして組み込まれた状態でアプリケーション開発をスタートし、その後アプリケーション自身を触らせる為にアプリケーション内部からmrubyに対してクラスなどを公開する、という風にすることで高機能なmrubyをメンテナンスされた状態で組み込みながらアプリケーション独自の拡張をそれぞれアプリケーション毎に施すことも簡単にできる、という風になります。
これは多くのアプリケーションに言語を組み込む毎に有用性がわかるようになってくる類いの物で、最初はあまり有り難いとは思わないかもしれないのですが、段々とありがたみが分かってくるでしょう。

##3. サイズのバランスが良い

アプリケーションに組み込む目的の言語でありながら、時々ばかでかい言語が存在します。Google V8とかね。
また、Lua等、非常にコンパクトでありながらアプリケーション拡張用の言語として十分な機能を持っている言語もある訳ですが、Luaはちょっと言語としての機能に若干の物足りなさを感じます。
そういった点において、私はmrubyにほどよいバランスを感じています。
ほどほどにコンパクトでありながら、完全なオブジェクト指向を実現しているというのは現実的な組み込み容易性と開発効率の両軸をバランス良く実現していると思います。
アプリケーション拡張用のスクリプト言語は、その言語自身のソース、あるいはライブラリをアプリケーション自身に組み込まねばならず、またアプリケーションの内部をスクリプトに触らせる為に言語を拡張してやる必要がある為どうしてもその関連でバグが入り込む余地があります。これは言語システムが大きければ大きいほどバグが発生した時にトレースすることが困難になるので、言語システムはコンパクトである方が望ましい。ですがスクリプト言語自身の機能がその為に制限されたのではスクリプトによる開発効率の向上が果たせません。結構バランスが難しい問題なのですが、mrubyはこれが良いバランスで組まれています。
この辺は本当に、自身で組み込んでみないと分からない気がしています。

##4. 組み込みが難しくない

組み込みが難しい、組み込み用言語というのを私は知らないので、実のところこれはメリットではありません。ただ単にアプリケーション拡張用として使える言語としてちゃんと使える水準ですよ、と言いたいだけです。他の多種多様な言語と同様、mrubyもまたアプリケーションを拡張する言語として組み込むのに何も特別な手順は必要ありません。一瞬で終わります。言語にアプリケーションを公開するための機能も他の言語、Lua等に比べてそれほど大きな違いはありません(勿論、スタックマシンであるLuaと較べて、何もかも同じなんてことは当然無いわけですが、特記しなければいけない程の違いだとは私は思いません)。

#あまり書けていませんが、まとめ

実のところ、1番の理由がほぼ全てだったりするのです。勿論アプリケーションへ組み込む際の機能に不備があるなら選択肢にも入らない訳で、その点においては他の多種の言語と同様、問題がないので書くまでもないわけです。
本稿は追記すべき事を思いつき次第追記していきたいと思います。
また、mrubyはここが良いんだよ、とかわかってね～な、といった意見がありましたらどうぞ教えて頂けましたら幸いです。