BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ アーティクル Rubyのルーツ:Smalltalkのカムバック、Randal Schwartz氏がSmalltalkを語る

Rubyのルーツ:Smalltalkのカムバック、Randal Schwartz氏がSmalltalkを語る

ブックマーク

Gartner社のアナリスト、Mark Driver氏は最近のブログ(リンク)で、Smalltalkに対する関心が高まっていることを取り上げています。これにはたくさんの要因が寄与していますが、RubyやPythonなどの動的言語の人気上昇がその一因となっているように思われます。Smalltalkは動的言語を支える多数の概念の先駆けとなり、時期的にはこうした言語が考案される遥か前のことであり、1970/1980年代から存在し続けています。多数のSmalltalk仮想マシンも同じ位長きに渡って存在しており、すでに高度に成熟しています。

Seaside

Smalltalkへの関心が現在高まっているもう1つの理由は、RubyやRuby on Railsの場合と同様に、Webフレームワークです。誕生してからしばらく経つSeaside(リンク)が多くの関心を集めています。Seaside上に構築されたオンライン・データベース、DabbleDBを支えているのはAvi Bryant氏です。(InfoQはAvi Bryant氏をインタビューしていますが、その中で氏は、SmallTalkの持続性のイメージコンセプトをDabbleDBがどのように利用しているか、Squeakをスケールさせるにはいかにして作成できるか、について話しています)(参考記事)

SeasideはSqueak上で開発されましたが、最近では他の多数のSmalltalkベンダーもSeasideをサポートし始めました。Cincom Smalltalk(リンク)はSeasideをサポートし、ブラウザ内でSeaside開発をするためのGUIツールWebVelocityを提供しています(Web Velocityを紹介する短いビデオが閲覧可能で(リンク)、Google Videoには長編のデモンストレーションがあります)(リンク)。GemStone/S(リンク)は持続性とクラスタリングを提供するSmalltalkであり、GemStone/Sを開発するGemStone社はSeasideもサポートしていますが、例として同社のGLASSプロダクト(無料バージョンもあり)(リンク)が挙げられます。

RubyおよびSmalltalk

SmalltalkはRubyに大きな影響を与え、今でも影響し続けています。たとえばRubiniusは、VMを実装するモデルとしてSqueak Smalltalkを使っており、また、GemStone社のMaglevはSmalltalk VMの上に直に構築されています。

Rubyの文法はSmalltalkの単純な文法より複雑ですが、それでも影響を受けています。たとえば名前つきパラメータ(Smalltalkにおける「キーワードメッセージ」)はRubyでは使えませんが、SmallTalkではかなり前から利用できるハッシュリテラル という機能を使って名前つきパラメータをエミュレートできます。

Ruby:

def foo(arghash)
 # ... do something with arguments
 42
end

foo( :name => "foo", :size => 42)


注記:Ruby 1.9ではより簡潔なリテラルハッシュの構文を提供しており(リンク)、文字数個を割愛できます。

上記と同じ内容をSmallTalkのキーワードメッセージを使って書いた場合(メソッド名はキーワード引数全部の構成になっている点にご注意ください):

:name name :size size
  "this is a comment ... do something with arguments"
  ^42.

receiver name: 'foo' size: 42.

Objective-Cなどの言語もSmalltalk風のキーワードメッセージを備えています。


RubyにはLambdasやProc、Block、そして最近加わった新顔の「尖ったlambda」の構文(-> {})といった多数のバリアントが見られますが、Smalltalkはこうしたバリアントの回避にも成功しています。Smalltalkにはブロックを作成する方法が1つあります。[:argument| ^42]でブロックを作り、引数を1つとり、値42を返します。

SmalltalkとRubyの間に見られるもう1つの相違は、ツールとIDEの可用性です。Ruby IDEが最近になってから利用できるようになってきたのに対し、Smalltalkは常に緊密にIDEと一体化されてきました(しかし、GemStone/SやGNU Smalltalkのように専用のIDEがないSmalltalkもあります)。しかしRuby IDEは、Smalltalk IDEには似ても似つかぬものです。たとえば、Ruby IDEはすべて、Ruby以外の言語で記述されています。Aptana(RDT)、3rd Rail(DLTK)、Netbeans、IntelliJにおけるRubyサポートはJavaで書かれており、SapphireSteelのRuby In SteelはVisual Studioをベースにしています。RubyベースのFreeRIDEがありますが、開発は中断しているようです。

Ruby IDEは静的解析や型推論、Rubyのコードを分析して、修正するその他のロジックを提供します -- けれどもコードはすべてJavaかC#で記述されており、JRubyのASTもしくはRubyInSteelのASTに依存します。先日Ryan Davis氏がruby_parser(参考記事)をリリースしたので、RubyソースのASTの可用性が改善されました。ruby_parserはRubyのソースを受け取り、ASTを返すことができ(UnifiedRuby形式で)、コメントと行番号を完備しています。

一方SmalltalkのIDEはSmalltalkで記述されています。静的解析ツールもリファクタリングツールも利用可能です(実際、初のリファクタリングツールはSmalltalkのRefactoring Browser(リンク)でした)。

Randal L. Schwartz氏のインタビュー

スクリプティングと結び付けられることの多い言語(Perl)からSmalltalkに移行した人の考え方を把握するために、Randal L. Schwartz氏に話を聞きました。Schwartz氏はPerlに関する評判高い書籍やコラムを多数書いています。氏は最近、Smalltalkの利用や奨励に多くの時間を費やし、"The Year of Smalltalk"(Smalltalkの年)(リンク)を宣言しています。氏はまた、Squeakのリーダーシップチームに属しています。


InfoQ:Seasideはステートの維持に継続を使うことで知られています。Avi Bryant氏は先日、AJAXによって異なるアプリケーションモデルが可能になったため、同氏が取り組んでいるプロダクトのDabbleDBでは継続の使用をやめることになったと語っていました。この件について、何か経験をお持ちですか。Seasideを使ってみたいと思わせる、魅力的なWebフレームワークにしているものは何でしょうか。

レイアウトビューの抽象化作成とほぼ同じ方法で、継続を使えば抽象化制御フローが作成できます。「このフォームが認証されるまで呈示せよ」という抽象化をライブラリに用意すると、ライブラリは、そのWebフォームの入った不完全なページが認証されるまで返すことができますが、すべてライブラリ「内」への呼び出しであることは明らかです。継続がなければ、最上部のレコグナイザをつなげて「OK。これは、このライブラリが現在見なければならない入力フォームに対する回答です」と言わせなければなりませんし、ローカルステートをすべて失ってしまうでしょう。

InfoQ:SchwartzさんのSmalltalkとSeasideアプリケーションではどの持続性メソッドをお使いですか。SmalltalkにRDBMSをお使いですか。SmalltalkのORMライブラリはどのような状態でしょうか。

レガシーインターフェースでは、Glorpをオブジェクト関連マッパーに選んでいます。Glorpは意欲的な開発が進んでいる最中で、「Active-Record」風のレイヤも追加されています。
新しいアプリケーションには、VMを完全に持続性のある環境に入れてしまうGemStone社の製品を大いに推奨します。オブジェクトがまさに自然に持続するので、昔ながらのデータベースへの挿入や取り出しのためにSQLに分解する必要はありません。

InfoQ:お使いのSmalltalkのバージョンはどれですか -- どのバージョンを使った経験をお持ちでしょうか。すべて同等でしょうか -- それとも、特定の問題分野に適したバージョンがあるのでしょうか。

私はSqueakのリーダーシップチームに属しており、Squeakの最初のリリースから追跡してきました。Cincom VisualWorksをいじり始めたのはつい最近になってからですから、私の進歩状況に応じて習得も進むことになります。GNU Smalltalkは面白いとは思いますが、私はSqueakのコントリビューターなので、ライセンス上の問題があってGNU Smalltalkの考察はできません(GPLコードをMITライセンスのリリースに派生させることはできないのです)。

InfoQ:Ruby 1.9にはFibersが追加されました。シンメトリック・コルーチンとしても使用できるコンストラクトです。Smalltalkのバージョンの中にも、重量級のカーネルスレッドを公開する代わりにこうしたコンストラクトを使うものがありますが、どのような経験をお持ちでしょうか。ユーザー空間しか備えていないSmalltalkのバージョンでは、カーネルスレッドをお使いになりたい状況はありますか。

私はスレッドの熱烈な愛用者ではありません。Unixでスレッドが「f o r k」と綴られるのには理由があるのです。共有はオプトインよりオプトアウトであるべき、と私は思いますし、スレッドは間違ったデフォルトを推定してしまうのです。 

InfoQ:かなりの期間、積極的にSmalltalkを奨励されてきましたね。Smalltalkに対して最も頻繁に尋ねられる質問、あるいはSmalltalkにぶつけられる異議の代表的なもの2つを挙げていただけますか。

「Smalltalkってもう終わっているのではないですか?」 まったくそんなことありません。
「お気に入りのエディタで編集できますか?」 基本的にはノーですし、一度に5行から10行のコードしか編集できないと分かったら、どちらにしろお気に入りのエディタを使いたいとは思わなくなり、現在の環境に敏感なエディタをとても使いたくなります。ビルトインのコードエディタが正にその仕事にうってつけです。

EclipseなどのIDEからSmalltalkを利用可能にするアプローチのひとつに、the STDT(リンク)があります。Eclipseベースで、Smalltalkのコードをファイルとリソースに翻訳します。「Industry Misinterpretations」(業界の誤解)のポッドキャストではthe STDT開発者の1人と長時間インタビューをしています(リンク)。余談ですが、EclipseとSmalltalkは非常にうまく一緒に使えるはずなのですが、その理由はとりわけRick DeNatale氏が説明しているように、EclipseがIBMによるSmalltalkの取り組みから誕生したからです(リンク)

InfoQ:Smalltalkを手短に紹介すると、どのようになりますか。たとえば、Perlを使っている友人に何と説明しますか。

Smalltalkなら、構文「全部」を20分で教えられます。純粋なオブジェクトとデバッガにより、Web環境でさえライブのデバッギングが可能になります。Smalltalkにはソースコードの分散型管理が組み込まれており、ネイティブでもFFIを介してでも、あらゆるライブラリとトークできます。Perlのプログラムで可能なように、Smalltalkもファイルやデバイス、ソケットにもトーク可能ですが、SmalltalkはPerlに比べて「遥か」前から存在しているのです。システムとの相互作用のすべてがオープンかつ編集可能、カスタマイズ可能であり、その中には開発者ツールも含まれます。

InfoQ:最近Squeakを開発しているのは誰ですか。また、開発は前進していますか。

Squeakリーダーシップチーム(私を含む)はコミュニティを代表し、プロジェクト全体を監督しています。Webチームやリリースチーム、ニュースチーム、等々も存在し、詳細を処理しています。(http://www.squeak.org/Community/Teams/)

InfoQ:Perlの機能 -- 言語コンセプトやその他 -- でSmalltalkにもあったらいいのに、と思うものがあれば、教えてください。

コマンドラインのスクリプティングには、まだPerlを使っています。Smalltalkは小さなプログラムに役立つとは、とても言えません。:)

InfoQ:Rubyのオープンクラス(モンキーパッチング)をどうお考えですか。SqueakのTraitsはお使いになりましたか。

Seasideのようなパッケージで、適切な選択対象にクラスのディスパッチメカニズムを用いて、Webページ上すべてのオブジェクトに「自分でレンダリングせよ」と教えられるのは素晴らしいです。この種のパッチングがなければ、ユーザーコードレベルでクラスパッチングの同等物を構築せねばならず、同じくらいクリーンにはとても出来上がりません。

InfoQ:Rubyには最近新しい実装多数が登場しました -- Smalltalkには異なるベンダーから多数の異なるランタイムが出ています。Smalltalkの異なる実装を問題とみなされますか、それとも資産とお考えになりますか。

私が扱う2つの主なsmalltalk(SqueakとVisualWorks)の祖先は実際同じ(Xerox Parcのオリジナル概念)なので、大した問題はありません。けれども、Seasideのようなプロジェクトは、ベンダーの機能面におけるかなりの類似化を確実にするのに役立っているので、良いことだと思います。

Schwartz氏のSmalltalkの詳細についてですが、氏はIndustry Misinterpretationsのポッドキャストのインタビューを受けていますし(リンク)、the FLOSS Weeklyポッドキャスト(リンク)では共同司会も務めています。FLOSS 29: Interview with Dan Ingalls(FLOSS 29:Dan Ingalls氏のインタビュー)(リンク)は、Smalltalkに興味のある方々には特に興味深い内容です。Ingall氏は、Alan Kay氏による言語仕様から初のSmalltalkランタイムを1970年代に書いた人物で、PARCにおいてはその後多数のSmalltalkバージョンも記述し、加えてSqueak(リンク)も書いています。Schwartz氏はSmalltalkについてブログ(リンク)も書いています。

Smalltalkならびに、Smalltalk開発者がソフトウェア開発にアプローチする方法については、情報源のひとつとしてCincomのJames Robertson氏が挙げられますが、同氏はSmalltalkについてブログを書き、日刊のスクリーンキャストと週刊のポッドキャストを発表しています(リンク)
GemStone社にはGemStone/Linux/Apache/Smalltalk/Seasideのソフトウェアスタックに、GLASSに焦点を合わせたブログ(リンク)があります。

最後になりますが、Smalltalkに関する無料書籍(リンク)のリストがオンラインで利用できます。 

 

原文はこちらです:http://www.infoq.com/articles/smalltalk-comeback-schwartz
(このArticleは2008年10月27日に原文が掲載されました)

この記事に星をつける

おすすめ度
スタイル

BT