たぶん、HSP関連の話は(また別のネタを仕入れない限り)これで終わり。
いろいろ話が聞けて楽しかった。情報提供してくださった皆さん、ありがとうございました。
HSPの良い点
ま、納得できないことはない。ただ、これらは「HSP言語の文法」と密接に関連しているとは言いがたい。 繰り返しになるけど「HSP(というツール全体)が良い」ことは示せても、 なぜ「あの言語でなければならないのか」という問いには答えてないように思う。
あ、「ドキュメント〜」は若干は答えになっているかな。弱いけど。
しかし、私の問いに対する答えになりそうなものも見付けることができた。
ひとつはあおきさんによるもの。
HSP とかが goto メインなのはセーブ・ロードの実装が簡単だからじゃないのかなあ。
<中略>
ゲームプラットフォームとして、if/while を取るかセーブ機構を取るかという選択ならセーブ機構になるよね
確かに、「紙芝居型ゲームにおける局面のセーブを実現するために現在の言語仕様が望ましかった」というのは、 真実かどうかはわからないけれども、もしそうであれば私の問いに対する直接の答えだ。
もうひとつはshiomanekiさんの考察。
もちろん機能が豊富とかライブラリが充実しているとかそういう面があることは否定できないけれども、もっと重要なのは『「構造化以前のBasic」のような言語』になぜ豊富なライブラリが用意されてしまうのか？（そして初心者に受け入れられてしまうのか？）
<中略>
新しい学習コストをかけたくなかったのは、自分が最初に慣れ親しんだBASICで初心者には十分だと判断した言語制作者ではないだろうか？
そして、『「構造化以前のBasic」のような言語』で育った人々が、いつかまた新しい『「構造化以前のBasic」のような言語』を作り出す。
こちらにも納得する。自分が育った言語と同じようなものを作る、 それが優れているかどうかについては深く考察を行わない、 その結果が「あの言語」である、というのも非常にありそうな仮説だ。
真実を確認することこそできなかったが、 こんな面白い考察が読めただけでも、この一連の話題は(少なくとも私にとっては)非常に有意義であった。
最後に、誤解している人がいたみたいだけど、 私はRubyのデザイナーではあるが、別にRubyと比較しようなんて最初から思ってはいない。 私は言語デザイナーである前に、言語おたくなので、あらゆる言語の「より良い形」に興味があるのだ。
私は「HSPが総合的に良いツールであること」を否定したことはない。 ただ、「HSP言語」はどうかと思うのは事実だし、 「HSP言語」がもうちょっとマシな言語だったらもっと良いツールだったとも思う。
で、私の意見が間違っているかどうかが知りたかったというわけだ。
一連のやりとりを通じての私の結論は、 私の考えつかなかったもの(セーブ機能の実現)が提示されたものの、 真実はおそらく「言語デザイナーの怠慢」 あるいは「実装者は、ツール(機能)には興味があったが、言語にはさほど興味が無かった」ということでは ないだろうか、と推測している。私としては残念な結論だ。
っていうか、仮にも言語を作ろうってんなら、 みんなもうちょっと言語そのものにも関心を払おうよぉ*1。
*1 マイノリティである言語屋の魂の叫び
今日は某kitajさんやら某gotoyuzoさんやらの誕生日らしいのだが、 うちの長女の誕生日でもある。もうこんなに大きくなったのね。 私も歳をとるはずだわ。
一日遅れの家庭の夕べでちょっとしたお祝いをする。 プレゼントをあげて。 あと、ケーキ食べる。