フリーでオープンでマルチプラットホームなHyperCardクローンってないかなあ

と思いながら、自分で作るんならどういう風に作るかなと妄想をしてました。なんでこんな古いものが欲しいかというと、やっぱり使いやすいからなんですね。いまでこそ、Javaをブンブン振り回したり、Cをガンガン走らせたり、C++をチマチマ弄ったりする私ですが、それでも古巣であるHyperCardに憧れます。それは、誤解を恐れずに書くと、他の開発環境はプログラミングをサポートするツールであるのに対して、HyperCardはプログラミングに重きを置いたオーサリングツールであるからです。ようするに、グラフィックとサウンドとテキストをチョロチョロチョロっとやって、ボタンなどのユーザーインタラクションのための部品とスクリプトをカタカタカタと書いてあげれば、それなりの作品が「はい完成」となります。しかもただのオーサリングツールとは違い、データベース的な要素も持ち合わせているため、ユーザーのインタラクション（テキストの編集など）が自動的に保存されます。
私は、HyperCardそのものにはそれほど不満がないので、作るとしたら、イメージ表示オブジェクトやグルーピングオブジェクトを導入するぐらいで、それ以外は似たようなものになると思います。あと、私が考えるHyperCardの一番の旨みは、やはり自動的に状態が保存されるということです（これは、Squeakなどでも見ることができます）。ですから、もしクローンを作るとしたら、そのときそのときの状態が自動的に保存されるというのに細心の注意を払うと思います。ま、インタラクションを保存しておいてくれるプログラミング前提のPowerPointみたいな感じでしょうか。
とりあえず、使えそうなライブラリをリンク。

piccoloは、2DGraphicsのフレームワークで、wicocoはJavaで非矩形・半透明ウィンドウを実現するためのライブラリ。あと、音をどうするかだ。
さて、プログラミングのためのHyperTalkそのものには不満タラタラです。何が不満タラタラかというと、

  1. オブジェクト指向プログラミング言語ではない
  2. データ型が文字列しかないくせに、扱いが浅い
  3. HyperCard専用言語のくせに、HyperCardのすべてにアクセスできない
  4. 手続き型言語のくせに、代入がタルイ
  5. GUIの動作を記述するには表現力がショボイ

と、不満なところを挙げていったらキリがありません。これだけ書くと（特に一番最初）、「こいつHyperTalkの何も分かってないんじゃね？」とか思う人も出るかもしれず、それはちょっと癪なので理由も書きます。
１．「HyperTalkはオブジェクト指向プログラミング言語ではない」について
まず、オブジェクト指向プログラミング言語とは、オブジェクト指向でソフトウェア開発を実現するためのプログラミング言語です。オブジェクト指向については、書くとそれだけで朝になってしまうので、ここでは書きません。ただ一つだけ注意したいことは、オブジェクト指向は「ただの物の見方にすぎない」というところだけです。
次に、プログラミング言語とは何かと考えると、ある問題やシステムなどをコンピュータ上のプログラムとして実現するとき、そのプログラムを記述するための言語です。そんな当たり前のこと言わなくても分かってるよ〜ってな感じですが、ここからが大切です。このプログラムを記述するための言語に、なぜたくさんの種類があるのでしょうか。プログラマの数だけプログラミング言語があるなんていう言葉もありますが、なぜこのような言葉が生まれたのでしょうか。答えは簡単です。プログラミング言語の性質は、問題領域＋実行環境（＋感性）によって決まるからです。世界中には無数の問題領域があり、無数の実行環境があり、プログラマの数だけ感性があります。ですから、プログラミング言語はたくさん種類があるのです。ここでは、問題領域に焦点を当てます。ある万能言語があったとします。この万能言語は、どんな問題領域のプログラムも記述することができます。一見、この万能言語さえあれば、他の言語は必要なくなるかのようにみえます。でも現実にはそんなことはありません。なぜなら、ある狭い問題領域にしか扱わないとき、万能言語と特化言語を比較すると、特化言語の方が記述が容易かつ単純になるからです。そして、プログラムが人間の時間を節約するために開発される限り、記述が容易かつ単純であるプログラミング言語は生き残ります。なぜなら、プログラムの開発コストがプログラムを開発することにより節約されるコストよりも小さいとき、プログラムは開発されます。人間は貪欲ですから、少しでも開発コストを小さくしようとします。特化言語の法が記述が容易かつ単純になるのであれば、万能言語よりも特化言語のほうが開発コストは小さくなり、特化言語が用いられることになります。ですから、特化言語は生き残るわけです。こうして、プログラミング言語はドンドンと生まれていきます。逆に言えば、現存するプログラミング言語には、それが対象とする問題領域が必ず存在するということです。
では、オブジェクト指向プログラミング言語が対象とする問題領域とはなんでしょうか。それは、「オブジェクト指向のものの見方でプログラムを実現すること」です。ですから、これを実現するための機能が文法や意味に盛り込まれています。HyperTalk単体では、この問題領域をまったく扱うことができません。すなわち、オブジェクトとオブジェクト間メッセージパッシングを使ってモデル化されたシステムを記述することができないのです。そもそも、オブジェクトを記述する手段がないのです。そんな言語でオブジェクト指向でシステムをモデル化できるでしょうか。なお、一般的にHyperTalkがオブジェクト指向であると誤解されるのは、HyperCardという環境下でHyperCard上でモデル化されたシステムの動作を記述することにより、オブジェクト指向”っぽいこと”を実現できてしまうことが原因ではないかと考えています。
正直、オブジェクト指向ちっくなHyperCardの動作を記述する言語がまったくオブジェクト指向ではないというのは、まったくスマートじゃないので私はいやです（ここが感性）。
２．「データ型が文字列しかないくせに、扱いが浅い」について
HyperTalkにおいては、データはすべて文字列である。たまに数値として解釈されるが、基本的には文字列である。スクリプト中に未定義の名前が出てきたら、それも文字列として扱われる。でもここで問題が。変数内の文字列そのものを名前として利用できないということ。すなわち、HyperTalkにおいて、参照を表す変数の値が存在しない！！
これは、HyperTalkが変数の値として文字列しか扱えないことが原因かというとそうではない。Cでは、変数の値はすべてバイナリ列により表現された値である。この値を、文脈（変数の型）によって、値なのか参照なのかの区別を行っている。すなわち、変数の値はすべて２進値にもかかわらず、参照を実現することができている。ならば、HyperTalkでも参照が表現できてもおかしくないのではないか。なぜそれを行わないか。それが、扱いが浅いという意味。
以下、疲れたので手短に。
３．「HyperCard専用言語のくせに、HyperCardのすべてにアクセスできない」について
カードとかに描かれてる絵にアクセスできない。あるドットを白や黒にすることはできても、白か黒かを判断できない。あほっぽ。
４．「手続き型言語のくせに、代入がタルイ」について
Cだと、

a = 10;

と記述すればいいところを、

put 10 into a

と記述しなければいけない。
５．「GUIの動作を記述するには表現力がショボイ」について
GUIを真面目に記述したかったら、マルチスレッドは基本だよね。
擬似的にマルチスレッドを記述するために、関数を分割して、idleにて自力でスケジューリングなんてやってられん（これが大変なんです、ものすごく。そのくせ糞重い）。
で、以上の５つを、HyperCard/HyperTalkの限界に挑戦して実現したことがありました。利用するためには、ものすごい冗長な表現を使わないといけなかった＆こちらが用意したスタックを利用してスクリプトを編集しなきゃいけなかったという制限つきですが。たしか、zorkタイプのアドベンチャーゲームを作る過程で副産物として出来上がったものだったと記憶しています。で、動かすとすごく重いんですよ。なにしろ、do文やsend文を使いまくってるからです。そのとき思ったんです。一から言語を作ったほうが早いってね。
で、今日一日、このHyperTalkに変わる言語はないかな〜って妄想してたわけです。