夏色の想像力
同人誌なのだが、恐るべき寄稿者のラインナップと、無意味にこだわった創元SFのパクリっぷり（「草原SF文庫」になっている）が凄い。内容も、商業レベルから一歩離れているせいか、ふわっと軽く遊べているように感じられるところがとても素晴らしい。
序文で大森さんも書いているけれど、こういうのはダメです。ほんと。
NOVA読んでないけど、買わないといけないらしい。買いますので。ごめんなさい。
シャッフル航法
とりあえず表題作は、
- イントロダクションを読む。
- 本文を数える。4段落。句読点分割で1段落あたり13。
- 全体を見渡す。00と08が一緒。
- ルールに従っているか確認。
- 改めて00から読んでみる。
と言うフローで処理した。最後の一文は、生成手順を思い浮かべて「笑うところ」だと思う。
意味が繋がりそうで、繋がらなかったり、そうでいて何かの伝わるような。面白い。つまりあれか、結果がそれっぽくなるようなシードを選んだってことになるのか。物語というものは、簡単な起点なり答えなりを与えたら、ある程度自動的に発展するものかもしれない。
もはや小説の読み方では無い気がするけれど、こういうイタズラなものはやっぱり楽しいと思うのです。
年刊日本SF傑作選2014 折り紙衛星の伝説
去年のを飛ばして（下書きに残ってるが）今年のを。
もともと私は海外翻訳SFばっかり読んでいて、ちょうど傑作選が出るようになった頃に日本の人のものも読むようになった。当時は自分にとって新鮮だったし、球数が今より少なかったためなのか玉石混交に感じていて、それが楽しかった記憶がある。
去年もそう思ったのだけれど、ここ最近、平均的にキチンとした感じのものが増えたと思う。収録作に困らないんだから誰が読んでもそれなりのものを入れるのが傑作選だろう。
とはいえ、何故これが傑作か、みたいなのが混じってると楽しいのも事実だと思う。円城塔のイタズラとか、宮内悠介のイタズラとか。
と書いていて、今はイタズラみたいなのが読みたい気分なんだなと思った。それはともかく。
総当たりで読むタイプではないので、傑作選はありがたい。ただ新規開拓ができるという意味では、今回はやや落ち着いてしまっている感があった。
来年も楽しみにしています。
ゼンデギ
イーガン作品のうち、遠未来を扱っている作品を苦手にしているなら、本作は現実との時代的差分が少ないためか、比較的分かりやすい側なのではと思う。ヴィンジにおける「レインボーズエンド」的な。
まあ自分は「白熱光」のほうが好きだけど…。
リライト、リビジョン、リアクト、リライブ
個人的にはいまひとつだった。
リライトは、いろいろ謎を残しつつ気を引いたのだが、全体を通すと、何か言い訳じみたものを感じてしまう。緻密という評判ではあるのだが、むしろツッコミどころが多いような。一方で矛盾をはらんでも走り切れるほどには、ストーリーの勢いが感じられなかった。初速は良さそうだっただけに…と思ってしまう。
という評価なのは、ハードSF的解釈を適用した部分がたぶんに含まれているからで、それは先に前評判を読んでしまったからだとも思う（Amazonのオススメだったからうっかり…）。先に評価を見てしまうとかは、なんとも失礼なことをした。
全滅領域、監視機構、世界受容
自分はだいたい、本屋で裏のあらすじを読んで、気になったら読む方式で、これもたまたま読んだ。SF方向だと思ったのだが、あっち系ホラーの様相が強く、読み出しでずっこけたが、あっち系ホラーもSFと近縁種とは言えるし、読み始めた以上ということで、全部読みました。
進み過ぎた科学は魔法と区別がつかない、を下から眺めたような状態で、見事に打つ手がない。個人的には、作中世界の皆様にはもうちょいやる気を出してほしい、という感想です。
これ、映画化するらしい。大丈夫なんだろうか。まあ状況だけ描いても十分おどろおどろしい気はするけど、視点人物による主観的内容だからこその部分があるようにも感じる。小説だからこその部分がある作品かもしれない。映像でキチンと締められるのかある種見もののような…。
GAE で Perl を動かせるなら
Google App Engine の Managed VMs を使って Perl を動かすのを試した。
単なる「やってみた」系で、内容として難しいことは何もない。動かす部分については Qiita にまとめてある。ここでは、さっさと Perl 試せば良かったという言い訳を。
むかし、前職の CTO （当時）に「言語なんてどれも一緒」的なことを言われたことがある。独学で Perl からプログラミングを始め、そのまま就職してしまった身としては、ふうんそういうものかね的な気持ちだったのだが、今はその意味が解る。
当時言わんとしていたことは、たぶんロジックレベルで大差ないということなのだと思う。仕事をする中で、そのことはもやもやとわかったつもりではいたが、自分がこの意味をきちんと理解できたのは、自前で構文解析器を書き、オレオレ言語が作れるようになったときだった。
以降、どんな言語を見ても、「それをどのように構文解析するか」ということが頭に浮かぶ。実際に解析器を書けるかということが問題なのではない。そのレベルでは、言語は大枠のカテゴリで大別されているだけで、キーワードの違いとちょっとした気の利きようだけが差異に感じられる。もちろん、実装の工夫はたくさんあるだろうが、実行方法は「言語」ではない。
こうして、（慣れの影響で） Perl がいちばん読みやすいという幻想が解けてしまった。私は経緯から Perl に思い入れがあるが、今の仕事では主に C++ を使っているし、ウェブも SPA が増えて、 JavaScript ばかり書いている気がする。プライベートではその時その時で適当な言語を使っている。もう Perl であってもなくても良いのだ。
さらに GAE のような本来 PaaS である環境でも Docker コンテナが動き、言語のくびきを離れてしまった。 GAE だから Python で書くかな、みたいな発想は要らなくなった。本当の意味で「言語なんてどれでも良い」が実現しつつあるように感じる。
であるならば、翻って Perl であっても良いではないか。今どきの流行りだからなどと言う理由で言語を選ぶ必然はもはやない。
おお、 GAE で nodejs 使えるのか、やってみよう！*1という前に、 Perl をやってみれば良かったのだ*2。
