要するに、ASN.1について少し、Dについて少し、コンパイラについても少し話したいと思ったんだけど、まとまった形が思いつかなかったんだ。だから、半ば関連のあることを適当にまとめて、これをブログ記事って呼んじゃおうと思った。あらかじめごめんね、あんまり質が良くないのは認めるよ。でも、こんなにたくさんのことを短く話すのは本当に難しいんだ（特に、もっと深く話したかったことをたくさん忘れちゃったし :(）。

少し前にSwiftでASN.1コンパイラを作ったんだ（swift-asn1じゃなくて、俺のはCodableを使ったやつ）。HeimdalのJSONコンパイラを使ったおかげで、ASN.1をもっと解析しやすいJSONのASTに変換できて、時間を節約できたよ。 [1] https://github.com/PADL/ASN1Codable [2] https://github.com/heimdal/heimdal/tree/master/lib/asn1

Dが大好きなんだ、私のお気に入りのプログラミング言語の一つだよ。今、Raylibだけを依存関係にして、ゼロからVim風のテキストエディタを作り始めたんだけど、思ったよりも進んで、テストカバレッジもかなり良かったことに驚いてる。 私がDの好きな機能はこれだね：

• ユニットテストをどこにでも書けるから、メソッドや関数のすぐ後にユニットテストを書くことが多い。
• version(unittest) {}のようなブロックがあるおかげで、テスト用にコンパイルすべきものを簡単に除外/含められる。
• 列挙型、共用体、アサート、契約プログラミングも全部素晴らしい。

Dを学ぶのに苦労したことはあまりないかな。やりたいことはドキュメントで見つけられるし、ChatGPTに聞けば、いつも素敵な方法が見つかるんだ。

OMG ASN.1。これを見逃した人のために、インターネットの成長過程で面白いことがあったんだ。あの頃、人々はIETFを通じてプロトコルを進化させていた。今頼りにしているもののほとんどは、その時に生まれたものなんだよ。ある日、メールがあって、FTPがあって、TCPがあって、バン・ジェイコブソンのTCPの改良もあった。あの時、企業の人たちはインターネットに全然注目していなかった。学者たちやIETFが、私が見た限りでは主な開発者だったね。

でも、ある日企業の世界が「これでお金が稼げるかも」と気づいたんだ。でも、プロトコルの開発プロセスは企業文化とはまったく理解できない（そして互換性もない）ものだった。TCPは明らかに混乱していて、DNSのようなプロトコルもめちゃくちゃだった。企業の視点から見るとね。そこでプロトコル戦争が始まったんだよ。https://en.wikipedia.org/wiki/Protocol_Wars

ASN.1がその戦争の産物なのか、単に企業のメンタリティの産物なのかは分からないけど、企業の世界と学問の世界の違いを示す強力な例になっている。戦争の残骸はあちこちに散らばっているよ。もしX.somethingプロトコルを見かけたら、それはその遺物の一つかもしれない。いくつかのX.系は採用されて役に立ったけど、夢に出てくるようなものもあった。これは古代の歴史で、今はほぼ企業の視点から語られているけど、企業の思考プロセスがIETFや学問の代替手段ほど効果的ではないことを示唆しているんだ。

一つはレシピ文化のようなもので、レシピを書いてみんながそれに従って、みんな幸せになる。もう一つは機能文化のようなもので、パンを作って食べられれば幸せになる。パンの味が良くない時は、直すんだ。今アメリカで一般的に手に入るパンの種類を考えると、レシピ思考やレシピ文化、企業文化についていくつかの結論を引き出せるかもしれない。これをAIのような新しいものにも当てはめることができるかもしれないし、できないかもしれないね。

普通、何かの標準を実装する時は、計画した時間の20%で機能の80%が得られるって言えるけど、ASN.1の場合、残りの20%が人生の残りを占めることもあるからね。

俺もいろんな文脈でこれを扱ったことがあるよ… パーサーがない深く埋め込まれたシステムとか、ちゃんとしたものが合わないところでね。だから、基本的なパーシングと生成を手書きしたことも何回かある。あ、非準拠の実装もあるよ。例えば、一部のパスポート（そう、チップ付きのパスポートはASN.1をたくさん使ってる）では、大きな整数の取り扱いが間違ってることもあるんだ（最小の2の補数であるべきなのに、固定の非補数フォーマットが0x02 INTEGER型に引きずり込まれてることもあった... 一部のライブラリにはそれに対処するための特別な非準拠パーシングモードがある）。

ASN.1のウィキペディアの項目によると、ASN.1をサポートするツールのほとんどは以下のことをするらしいよ：1) ASN.1ファイルをパースする、2) プログラミング言語（CやC++など）で同等の宣言を生成する、3) 前の宣言に基づいてエンコーディングとデコーディング関数を生成する。これらの作業は、データエンジニアリングプロセスやライフサイクルの一部らしいね。21世紀初頭の頃、Pythonはただの解釈型の汎用プログラミング言語の一つで、ウェブ用（PHP）でもなければ、コマンドツール用（TCL）でも、システム用（C/C++）でも、データ処理用（Perl）でも、数値計算用（Matlab/Fortran）でも、統計用（R）でもなかった。DもおそらくPythonと同じような軌道を辿るだろうけど、本当に特別なキラーアプリケーションが必要だね。それがDを前面に押し出す瞬間になると思う。リアルタイムデータのストリーミング、処理、エンジニアリングがDのキラーユーティリティになって、Dはデータのためのものだってことを定義できると思ってるよ。

すごく面白い記事だね。俺もASN.1コンパイラに何時間もハッキングして、X.681、X.682、X.683の機能を追加して、1回のコーデック呼び出しで全体の証明書を再帰的にデコードできるようにしたことがある。だから、似たような作業についての投稿を見るのはすごく嬉しい！ASN.1は本当に素晴らしい。たくさんの批判を受けてるけど、それは全然正当じゃない。ASN.1は単なる構文やエンコーディングルールのセットじゃなくて、強力な型システムなんだ。

トルコのことわざに「人間はこれを使う、人間だ！」っていうのがあって、これはその物が異常すぎて人間のために作られているように見えないことを示すんだ。動詞は文脈によって変わるよ。例えば、食べ物を作りすぎたら、動詞は「食べる」になる。これってデザインにとって素晴らしいモットーだと思う。ゲーム・オブ・スローンズのセリフ「判決を下す者が剣を振るうべきだ」って覚えてる？これも仕様に適用されるべきだと思う。仕様を考えた人は、その仕様のパーサーを開発する最初の責任者であるべきだ。動作するパーサーコードとユニットテストがなければ、仕様は承認されない。こういう要求があれば、仕様が実際に改善されるかもしれない。

わお、俺はたった一つの小さなASN.1を一つの値（署名一つ）でパースする必要があったんだけど、ASN.1には仕様があって、それを元にパーサーを生成できるって知らなかった。だから、その特定の256ビットのために自分で解決する羽目になった。でも、セキュリティ関連のものには過剰に仕様を定義する方がいいと思う。JSONやXMLはあまりにも曖昧で、パーサーが予測できないからね。