https://us.macmillan.com/series/monkrobot

なんとなく本屋で見かけて手に取った本だけどかなり面白かった。『銀河核へ』の邦訳もあるベッキー・チェンバースのシリーズで、中編2本で構成されている。一本目のタイトルは A psalm for the wild-built、二本目のタイトルは A prayer for the crown-shy。

パンガという世界が舞台で、そこではロボットたちが自意識に目覚め、人間と別れて生きることを決めた。それから時は流れ、人類はAIや知的なロボットといった存在とは無縁の生活をしてきた。人類の住むべき領域と、ロボットたちの領域である Wild が分かれ、人間たちは自分たちの領域で生きてきた。時は流れ、ロボットたちの存在はもはや神話のようになっていた。

主人公のデックスは tea monk という、悩みを持った人に茶を提供しつつ話を聞くといった仕事をする人間。 tea monk としては成功を収めたデックスだが、人生に思い悩み、本当にちょっとした理由から禁断の Wild に踏み込んでしまう。そこで出会ったのがロボットのモスカップ。モスカップもモスカップで、長い時をへて改めて人間と接触しようとしていたロボットだった。ロボットたちの質問は一つ — 人類は何が必要なのか？ (what do people need?)

デックスとモスカップはそれから Wild を少し探索し、そして次に人間社会に出ていく。一作目は主にロボットたちの生態（というのかなんというのか）やあり方が詳しく描かれ、二作目は人間社会が詳しく描写されている。どちらもそれなりにユニークで興味深い。デックスとモスカップのユニークなキャラクターも味わいがあり、二人の対話も飽きさせない。どちらの作品ともちょっと癒やしっぽいオチがついていて読後感も悪くない。いや面白かった。正直なところ、『銀河核へ』は翻訳で読んでいて途中でダレてしまって投げ出したのだけど、英語で読み直そうかなと思ったぐらい。

本作は「ソーラーパンク」として書かれたと言われていて、自分にはあまり詳しくない用語だった。サステナブルエナジーとかエコみたいなテーマを扱った作品ということで、2009年に提唱されたものらしく、作例はそれほど多くはないようだった。事後的にル=グウィンの『オールウェイズ・カミング・ホーム』や『所有せざる人々』がソーラーパンク作品ということにされているらしい。なるほどそれでこういう人類社会なのかね、と腑に落ちるところもあったりした。

そういうわけでなかなか良かったのだけど、本作は邦訳は非常に難しいんじゃないかなという気がする。それは主人公であるデックスの性別に起因する。デックスは男性でも女性でもなく、作中では常に singular-they が使われている。修道僧（モンク）なので敬称がつけられるが Sibling と呼ばれている（Sibling Dexという表記が多い）。が、すべての人がそうなのではなく、男性なら僧なら Brother がつけられるし、でなければ Mr. がついたり he で呼ばれる人もいるし、女性なら Sister / Ms. / she が使われている。デックスは特別な存在ではなく、ほかにも Sibling や Mx. のついた登場人物は普通に出てくる（ちなみにロボットには it が使われている。モスカップ自身がそうしろというくだりもある）。

この人類社会の性別はどのようになっているんだろうか、というのは興味の一つでもあったし、これが解決しないと翻訳は難しいだろうなという気もする（解決してもぎこちない翻訳になりそうでそれはそれで興をそぐ気がする）。が、2作で終わりだということだがその辺はあまりはっきりとは説明されなかった。単に自己の決定によって Sibling / Mx. / they を選択するのか生まれながらそうなのか、外見だけでわかるような違いがあるのか、みたいなことが気になっている。LGBTQテーマのSFとしてはそこは追求するべきではないような気もするし、だからこそちょっと曖昧なところで終わらせてるような気もするけど、翻訳するとしたら大変そうだなと思った。

短いしそれほど難解な話ではないので、英語で読んでも大丈夫な人は読んでみてください。おすすめ。

年末年始にかけて日本に2週間ほど滞在していた。といっても主に親戚との年末イベントがメインで、あまり人にあったりしなかった。子がまだ小さいこともあり、映画を見たりといった余暇もなし。本はちょっとだけ買ったが子供の絵本が多かった。

日本の生活

今回はairbnbで部屋を借りた。子供が小さいので、家具や食器・台所付きで寝室が分かれている部屋というのが助かる。都内ということで蒲田近郊に滞在していた。外食はそこまでせず、基本的には部屋で自炊。それか親戚の家にいくか。

前回に帰った時も思ったけど、「まいばすけっと」がそこらじゅうにあってとにかくびびる。なんなんだろうあれ。東京で一番店舗数のあるのまいばすけっとなんじゃないか。あんなに店舗があって利用客がいるものなんだろうか。こちらもある程度は自炊するのであると安心感はある。が、結局は普通のスーパーマーケットの利用がメインでまいばすけっとはそこまで使わなかった。

パンデミックの影響なのかどうかは定かではないけど、クレジットカードやコンタクトレスな支払いのオプションはかなり充実してきたと思う。現金の利用は結構減ってきたなという感じがある。まだ必要ではあるけれど。

zipair

行き帰りの飛行機にはzipair Tokyoを使った。zipairはLLCで、とにかく安かった。サンノゼ-成田便は就航してすぐということでご祝儀価格で割引だったのかね。あそこまで安いなら仕方ないというぐらいの安さ。

ただ安かろう悪かろうということはなく、体験はかなり良かった。まず機体はBoeing 787なので広く快適だった（zipair全体で787しか使わないことでコストを削減するということもあるらしい）。フルフラットシートもあるが、6歳以下の人は使えないという制限があり、そちらは使わず。職員やCAの人当たりも日本らしく丁寧。

一方で予定変更が一切できず、様々なものが有料化している。例えば預け入れ荷物も有料で、重さによって値段が変わる。機内食も有料で事前に頼んでおく必要がある。水すら有料なのはちょっと困った（水筒を持って行って入場後の空港で汲んだりしたけど足りなくなったりした）。また席にはディスプレイが付いていないので、機内で暇つぶしをするには自分の携帯電話かタブレットを利用しないといけない。

とはいえ実際には機内食そんなに美味くなくて微妙な気持ちにもなるからなくてもいいや、子供向け機内食もほとんどベビーフードみたいになっていて自分の子にはそぐわない、といったこともあるから、機内食がオプショナルなのは意味があった。今回行きは（自分用には）smash burgerを買って、帰りには寿司岩の鯖棒鮨を買っておいた。子供にも子供用の食事を持っていくことにした。

席にはディスプレイは付いていないが、実は機内エンターテイメントシステムが存在しているというのも面白かった。機内wifiが完備されていて（インターネットにも繋げるという話だったがこれはほとんど使えなかった）、機内wifiから機内サービスに色々アクセスできる。食べ物の注文や現在位置の表示のほか、機内wifiからだけ見える映像コンテンツ（映画とか）もあった。事前にNETFLIXとかでデータをダウンロードしておいたんだけど、そこまでする必要は実はあんまりなかった。なので意外と機内の体験は悪くない。

天候の問題で欠航になったりするとかなり困る気がするが、そういうリスクを除いてはzipairかなりいいという印象。

wingz

空港と自宅の行き来にはwingzというアプリを使った。Uberみたいな配車サービスだが空港送迎に特化していて、皆の車がデカかったり、チャイルドシートを指定できたり、航空便の予定に合わせて予約できたりする。子供が小さいので（この記事そればっかりだが）チャイルドシートがあるというのが大きい。普通の配車サービスやタクシーでは対応できないからね。従来型のシャトルサービスでも良かったが、アプリというだけあって体験は色々良かった。担当してくれたドライバーの人も感じがよく良い体験だった。

その他の事柄

時差ボケ。一般にアメリカから日本への方向の時差ボケは楽で日本からアメリカの方向はきついということが言われている気がするが、今回は日本の最初の数日の時差ボケがひどかった。夜中の1時に爽快な感覚で目覚めてしまい、同じ頃に起きてしまった子と「もう朝かね、おきますか」と起きてから時間を確認したら深夜でびっくりしながら慌ててふたたび寝かしつけるという失態を犯したくらい。逆に日本からアメリカの方向では、夕方に乗ると朝に着く時間帯の便だったことと、子供の世話のサイクルに気を取られたからか、今のところそれほどキツさを感じない。もっとも妻はアメリカに戻ってからの時差ボケがかなりキツそうなので人によるとしか言いようがない。

上野の科学博物館に行った。特別展（毒展）は並んでたので常設展のみだったけど、よく考えてみると常設展をじっくりみたのは初めてかもしれない。フタバスズキリュウの展示とか見応えがあって良かった。

川崎水族館にも行った。カピバラに餌をやったりした。あとしながわ水族館（品川駅近くにあるやつではなく大森海岸にあるやつ）にも行ってイルカのショーを見たりした。多摩動物公園にも行った（坂がすごくて子供を抱えての移動が結構な運動になった）。子供にこういう体験がよかったのかどうかはよくわからない。子供はグッズ販売エリアのガシャポンのレバーをガチャガチャ動かすのが楽しいようでそこでずっと遊んでいたような気がするが、まあそれでよし。

https://anond.hatelabo.jp/20221129085814

なかなか面白いテーマだと思った。実際のところ、平常の仕事で必要かどうかでいうと全然必要ないんだよね。知っておく必要は特にない。もちろんフレームワークを作ったりプログラミング言語を作ったり、いろいろ必要な局面がありうるとは思うけど、たいていのソフトウェア技術者のたいていの仕事には必要な局面はごく稀。それは別にbigtechの従業員でも同じと思う。

そういえば圏論についてこんなことを書いたことがあった。これは今でも間違っていないと思う。https://qr.ae/pr7ITC

なのでまあ必要に応じて学んでいけばいいし、永遠に必要にならないこともたくさんある。そもそも学部レベルで学ぶような内容は（大学にもよるでしょうが）そこまで広い範囲でもなくカバーしていない分野も多いし、一方ですごく深く理解できるようになるかというとそこまででもないという気もする。

けど実際のところ体系的に学んでいないと必要に応じて学ぶというアクションを取ることができないというか、そのような選択肢に思い至らなくていろいろおかしくなってしまうということがあるんじゃないかなぁ。という気がする。

そういえば昔こんなことがあった。Google日本語入力チームで働いていたとき、軽く雑談しましょうとのちのPFNの人たち（当時PFI？設立前？どっちだったか）と話したことがあった。その雑談の中で、こんなふうに辞書データを圧縮していてこういうデータ構造を使ってるんですよね、まあこれが最適かどうかはわからないんですけど……みたいな話をちょっと話したところ、岡野原さんがさっと立ち上がって、軽く計算してみましょうか、とホワイトボードにざっくりとした概算を計算しはじめ、理論的な下限がこのくらいだからかなりいいんじゃないですか、みたいなことをパッと言ったのだった。

CSの学位があればこういうことができるかというとそれだけではないわけだけど（こちらもCS系の学位を持っている人はたくさんいた）、ないとできないようなタイプの議論とか考え方というものはあるのだと思った。

何ヶ月か前のことなんだけど、Highway 85を走っていたら “Norman Y. Mineta Highway” って書いてある標識を見かけた。

ハイウェイは通常、数字で呼ばれるけれど、たまに名前がついていることもある。大体の人は名前の存在を知らないけれど、そういうことはある。なので、おっそんな名前ついたんだ、と思ったのだった。

ノーマン・Y・ミネタの日本における知名度は高くないと思うけど、地元ではとても有名な政治家で、かなり出世した人だ。名前はかなり知られている。サンノゼ空港が正式には Norman Y. Mineta San Jose International Airport であったりするようなこともある。

つい最近（2022年5月）に亡くなられたのもあって、それでついた標識なのかなぁと思ったのだった。

それでふと、これいつからある標識なんだろ？と思ったのだった。Googleのストリートビューは定期的に撮影しなおされていて、過去の画像も見えたりする。で、色々みてみるとなんと2008年の12月にはもうあるのだった。

Wikipediaを見てみたら2008年9月にこの名前がついたという情報が書いてあった。どういうきっかけなのかはよくわからないけれど。

それにしても2008年て。私がこの辺に引っ越してくるより随分前だ。2008年くらいにはもう出張で頻繁に訪れて、この通りを通った回数なんて数えきれないぐらいなのに、マジで今年になるまでこの標識のことに気づいていなかった。

やーびっくりしました、という話でした。人間の認知なんてあてにならんもんです（それは主語が大きいという話かもしれないが）

ElonがTwitterを買ったことは自分にとって思った以上にショックだった。彼のやろうとしていることがうまくいくか、それがいいことなのかどうか、というのはまあ興味深い話ではあるが、それはそれとして個人的に私はElonを支持しないので、彼の支配下のTwitterの利用を段階的にやめてみることにした。このブログは自動連携でtwitterに出てくるようになると思うし、アカウントを止めるわけではないが、基本的には投稿はしないし見るのも減らしている。

と言っても、まあ完全に止められるかはわからないし、数ヶ月後に何事もなかったかのように利用を再開することもあるかもしれない、と予防線ははっておきます。自分はsocial addictなので……。

さてそういうわけでどうするかということで、ひとまず個人的なこととかはFacebookに書いてみたり、5年前にアカウントを作ったっきり放置していたMastodonのアカウントを復活させて少し投稿してみたり、しているが、これが持続可能なのかどうかはよくわからない。

twitterがもしダメだったとして、しかし今後どうなるだろうか？　Mastodonとfediverse（というらしい）がそのニッチに収まるかというと非常に怪しいなという印象しかない。Mastodonは（色々トラブルはあるものの）比較的牧歌的な状態であるが、それはユーザ数が少なくて理想論的なユーザが多いからだろう。ユーザ数がふえればtwitterと同じような問題、スパムやボット、問題発言、偽アカウントなどの問題が頻発するようになるはずだ。そして分散的なネットワークであるMastodon / fediverseでは誰かを追い出したり禁止したりということを現実的にenforceすることが非常に難しくなるだろう、ということは容易に想像される。

公式アカウントの認定のような機能はMastodon / fediverse には存在しないし、ありえないとも考えられる。ただ自分のドメインで運用することで公式性を与えるということになるだろう。それでも「紛らわしい微妙な名前のドメイン名」を使ってくる人々とか、そういう多数の問題が生じることも容易に想像される。映画が公式サイトにドメインを取得して公開後に第三者が勝手にドメインを獲得できてしまうように、時限的なアカウントの乗っ取りのようなことも起こりえる。それに結局、ドメイン名の維持に必要なのは少々の登録料な訳で、金銭で認証バッヂを買える新しいtwitterとどれぐらい違いがあるのかはまあわからない。

fediverseというのはどうもblogosphereみたいなのと似たような語感に思う。そうやって「誰もが使うサービス」はなくなり、それぞれがそれぞれに分かれて棲み分けるようになるという未来像は考えられなくもない。とはいえ便利だからみんな使うようになるわけで、twitterでないにせよ、それがなくなるという未来もあんまり考えづらい……。

とかまあ考えてみるとMastodon / fediverseではない別の何かになるのかなという気がする。それはdiscordのような非公開の場かもしれないし、redditなのかもしれないし、これからできる新しい何かなのかもしれない。正直よくわからんけど、まあ新しくできた何かなんじゃないか、という気がする。

---

話のついでにactivitypubも把握しておいた方がいいだろうなと思って仕様もざっくりと眺めてみた。20年くらい前にRDF / RSS / Atom とかを勉強してたのを思い出すね。なんか自分でactivitypubなマイクロブログを作ってみると楽しいのかなぁ。どう考えても持続可能ではないけれど。

それにしても仕様としてはまあまあシンプルなので、このままではとてもスケールしなさそうだなという気がする。例えば、

• いろんなドメインのオーナーが自分のMastodonインスタンスなりなんなりを立てるのは大変すぎるので、マルチホストで独自ドメインに対応したホスティングサービスは不可欠になる。今のwordpress.comみたいな感じ。Automatticとか今頃そういうのを頑張ったりとかしてるのかな
• スパム対策。メールと同じでスパムメッセージには対策が必須になる。Akismetみたいなサービスが必須みたいなことになると思う
• 投稿数に応じてHTTPリクエストが爆発的に増えるとやってられないので、中継・一括化のようなものが必要になりそう

とか、色々やることがあるのかもね。

yaml、どうしてこんなに使われているのだろうか。kubernetesにも責任があるというのはありそうな話だけど、色々考えてみるとそこまで簡単な話でもなさそうな気がする。例えばtravis-CIの設定ファイルがyamlであったりというように、この分野ではyamlは割と広く使われていたんじゃないかという気がする。思い起こせばGoogle AppEngineもapp.yamlに設定を書いていたし、設定にyamlというのは割とよくあることであった、のではないかなあ。

しかしなぜyamlなんだろうか。yamlのフォーマットには問題がたくさんあることが知られているし、自分も全く好きではない。

例えばyamlの問題の一つとして、キーに任意のデータ構造を持ってこれるという話があり、これが一部のプログラミング言語で問題を厄介にしている。またエイリアスがあってデータ構造がツリーにならない（複数の経路から同じノードに到達できる）ということがある。本質的にはグラフになっている。

一方、kubernetesなどを見てもそんなことは全く考えられていない。全てのキーは単に文字列しか考えられていないし、エイリアスがレスポンスに出てくることはあり得ない。入力にエイリアスがあった場合の処理は自分はやったことがないのでわからないけど可能なら単にコピーしていたりするだけで、循環はスキーマに合致せずにエラーを返して終わりだろう。実際のところ、kubernetesのAPIサーバはyamlもjsonも返せるようになっているので、jsonで表現できないデータ表現はkubernetesにはあり得ない。

要するにyamlである必然性は全くない。単純に、jsonみたいだがもう少し「簡単に」かけてコメントのある何かというのが望まれていて、標準的だったのがyamlだったというのが本当のところだろうと思う。

ただ本当にこれが望まれているものだったのか、というのは謎でもある。yamlは文字列も数字もクオートなしで書けるのでちょっとした変更でデータ型が意図せず変わってスキーマに一致しなくなったりとか、インデントに意味があるのでうっかりミスでおかしくなったりとか、全体的に非常にerror proneなところが大きい。やりたいことは「なんか少しだけオシャレなJSON」なのにオーバースペックすぎる。なんというか、vscodeの設定ファイルみたいな、JSONにコメントを書けるようにすると言った拡張だけするのが望まれていたんじゃないか、という気もする。

kubernetesを出すときか、別のタイミングがあり得たのか知らないけれど、何か別のフォーマット、jsonnetとかcueとかdhallとかHCLとか……なんかそういうものを作ってそれを使えるようにしておけばよかったんじゃないか、という気がしないでもない。社内のborgは独自の設定ファイルだったからyamlにする必要はなかっただろうにね。

もっとも、新しくオープンソースプロジェクトを立ち上げるにあたって設定言語を独自に策定、というのはやりたくなかったのだろうね。yamlがここまで使われているのには「それが標準規格のものだから」というのはある気がする。コメント付きのJSONを処理するためのパーサというのはどのプログラミング言語にもあるわけではないけど、標準規格のフォーマットは大体パーサライブラリがあるので。

ただいかにもstatus quoであってこれをなんとか打開することがあったりしないんだろうか……といつも思っている。そう思ってる人がいるから、結構いろんな設定言語が色々あるんだろうけども。

（Helmについても色々思うところがあるが今回はオフトピックなので次回に持ち越します）

clear alignerを始めた

のその後です。1ヶ月くらい経って3個目のアライナーに移行しました。

• 装着していると数日で慣れる。慣れると割とどうということもない
• ただ新しいアライナーになるとまた最初は結構力がかかっているのを感じるようになる。毎回そうなるっぽい
• 歯間フロスの感触が結構変わってきているから、実際に歯は動き始めてるってことなんだろうなあ。面白い
• 飲食のたびに外すのはまあまあ面倒だが、そこまででもないといえばそこまででもない。飲食後に洗ったり口をすすいだりするのは結構雑になってきた気がする。食べかすが残ってて虫歯になったりするとシャレにならんけど
  • ただ仕事中にお茶を飲む量は減って水ばっかりになっている気がする
  • コーヒーはおおむね昼食後に一杯しか飲まない習慣だったので、昼食時とコーヒー飲用を一回のセッション（？）で行えていて、これまでと同じくらい飲めている
  • 熱で変形するのが問題なのでさませばそのまま茶を飲んでもいいはずなので、そういう方向性を考えてみたい
• アライナー、わりとすぐ汚れるので歯ブラシで洗っているけど、これが面倒

まあそんな感じで慣れてきました。最後にどれぐらい変わりますかね。

ここのところ歯医者でずっと勧められていたのでclear alignerを始めてみた。いわゆる歯列矯正というやつなのだけど、ワイヤーなどを使って矯正するのではなく、透明なマウスピースのようなものをずっと嵌めて生活するというスタイルの矯正だ。アメリカでは比較的一般的みたい。invisalign（インビザライン）というのも聞いたことがあるが、これは特定商品の名前であって私がつけているのはそれではなく別の会社の製品。一般名詞はclear alignersというらしい。

治療に入る前に一旦計測器で歯の形状や配列を調べてデータをメーカーに送ると、メーカーがそのデータからシミュレーションをして歯の形状と動きに合わせたマウスピースを作ってくれる。マウスピースは自分の場合、2週間に1回新しい形状のものに取り替える仕組み。とりあえず3個まで（6週間分）のマウスピースをもらってきた。6週間ごとに歯医者を訪問して続きのやつをもらいつつ進捗を確認するといった状況のようだ。

マウスピースは着脱可能で、食事とかの際には外す。食事が終わったら歯磨きなどをして嵌め直す。1日だいたい22時間以上つけていてくれ、と言われている。飲み物とか噛まない食べ物（例えばアイスクリームとか）なら大丈夫らしい。でも後で口をすすいでほしいとのこと。間に入り込むと虫歯の原因になるからだろう。コーヒーなども制限があるという話だったが、聞いてみたところどちらかといえば高熱で変形するのが問題なようで、冷めていればいいらしい。でもまぁ外した状態で飲んで、後で水で口をすすぐ方がいいのかも。それ以外には特に制限はなく、要するにずっとつけているだけ。

矯正にかかる時間は人それぞれで事前には数ヶ月と聞いていたけど、製造されたアライナー（マウスピース）を渡されてみればナンバリングが1/26なので52週間つまり自分は1年間はやることになるようだ。

そのほかの雑感。

• つけていると違和感はある。なんとなく慣れる気がするが一旦外すとまた付け直した瞬間には違和感がある。慣れるかなあ
• メーカーによるのかもしれないが、自分のものは歯に着脱用の突起みたいなものを接着してアライナーをフィットさせる方式だった。この突起もまだ自分的には慣れてない
• 目立たないということでいいのだが、喋り方とか滑舌とかちょっと変わる気もするがどうなんだろう？
• 食事のたびにマウスピースを外したり、食後すぐに歯磨きをする生活がこれまでの生活習慣と異なるので、家族込みでの生活習慣の確立をしないといけない。例えばうちに小さな子供がいるので、子の前でマウスピースを外すといったあらぬ好奇心を掻き立てるようなことをしないようにしないといけない

とまあそんな感じ。始めたばっかりでよくわからないからそんな書くことがないな……。ただ1年と長丁場なので、記憶がフレッシュなうちに記録にとどめておくのがいいかもしれないかなと思って書いておいた。

費用。相場というものが全くわからないしこれもまた人それぞれであろうという気がするが、自分の場合はだいたい定価が$6,000くらいと言われた（60万円……ではなく今の円相場だと80万円強ぐらいか）。ここから保険が降りて、なぜか分割払いか一括払いかの選択で一括払いを選ぶと少し安くなるので、自己負担額は$3,300くらい。このうち一部はFSAを使って払ったので感覚的にはもう少し割り引かれた感じ。高いのか安いのかよくわからんけど適当にウェブで検索してみたところ日本でもこれが馬鹿たかいというほどではない気がする。

以上ですが、さてどうなるでしょうかね。

http://lise-sophia.net/kktm/Essay/xx-shi.htm

このエッセイが面白かった。動詞に-erや-orをつけるような名詞は「◯◯子」「◯◯機」「◯◯器」などといった接尾辞がつけられる。特に抽象的な概念などの場合には「子」がつけられがち。例えばoperatorを「演算子」と呼んだりidentifierを「識別子」と呼んだりするように、と。

プログラミングの世界ではまさにそういう「抽象的な概念」であるが-erや-orがついた名詞というのはたくさんあるような気がする。どうなっているだろう？

constructorについては、「構成子」という訳語があるかな、と思ったが、「構築子」という用語もあるようだ。どちらも現存するらしい（前者は例えばJIS規格のFortran、後者はJIS規格のC#で使われている）。さてFortranのことは全く詳しくないが、C#くらいモダンな言語にはこの種の「◯◯子」がたくさんありそうだ。そこでJISX 3015をネットで検索して適当に見かけたものを探してみた。

なかなか面白い。みなさんも色々考えてみてほしい。

まずconstructorに対応するものとしてdestructorだけど、C#の仕様にはdestructorがない。あったけど紛らわしいのでfinalizerという名前になったようだ。JISX 3015にはその経緯も記載されて（翻訳されて）おり、destructorの方は「解体子」、finalizerは「終了化子」と訳されている。「化」は必要なのかなあ、でもないとちょっとおかしいのかなあ。うーん。

finalizerに対応するものといえばinitializerだろう。これは当然「初期化子」ということになる。これはまあ見覚えある気がするな。

次にiterator。これはどうなるだろうか、考えてみてほしい、がそれほど意外性はなさそうだ。「反復子」という言葉が入っている。

iteratorといえばgeneratorというものもあることがある。ただC#にはないので訳語はあるのかどうかわからない。自分なら「生成子」とでも名付けるだろうか。constructorと紛らわしいかなあ。難しいですね。

他にも色々な-erや-orがありそうだ。ありそうだと言いつつ、考えてみると意外と思い付かないものだけど。

逆にJISX 3015を眺めていて「おっ」と思った日本語の単語の方を二つ挙げておく。

「添字子」。これはindexerといったところだろうか。

「アクセス子」。えーと、accessorといったものだろうか、しかしもうちょっといい訳語はなかったものだろうか。さらにアクセス子の中には「イベントアクセス子」というのもあるようだが、もうそれなら全部カタカナ語にしちゃえよ感があって味わい深い。

だらだら読んでたんですが結論としてはとても面白かったです。

作家を志して編集者になったもののあまりうまくいかず仕事もクビになった主人公が、デビュー作で一世を風靡した匿名作家のアシスタントに抜擢される。ところが……という話。

序盤のあまりうまくいっていない編集者生活とそれが破綻するまでの部分は（これはこれで面白いものの）ちょっとかったるいなと思っていたのだが、中盤あたりでおきるとある事件で物語は急展開をみせる。そしてそこからの展開が無茶苦茶で素晴らしい。とても良かった。

https://amzn.to/3ynRwdU