2024-10-14

模様替えした。机を片付けてリビングを生成した。ソファと本棚、ベランダに続く窓で余白を三方から囲む間取り。寝室にはベッドと着替えに関するものがある。

机がないのはどうなのだろうと思ったが、ここ1年くらいは家でパソコンするときはノートパソコンだけで完結させることが増えたし、そもそも読書が中心なので机をヘビーユースしない。数学の本を読むみたいな読み方をしにくくなることと、在宅ワークしたくなったときに面倒そうなのがネックかな。リビングの空間がいい感じで嬉しい。

Goは静的解析のためのパッケージを標準で提供していて静的解析ツールを作ろうと思うとコンパイラが扱うデータ構造を割と見ることになる。 AST、その型、SSAが代表格だろう。型は単体でプログラムを表現するわけではなく、 ASTに対してつく(かもしれない)メタデータだと思えるかもしれないが、これらのデータ構造はGoコードのいろんな表現の中の一つだと思えそう。アセンブリ言語もその中の一つなのだろうけど、アーキテクチャに依存したりランタイムのあれこれが入ってきたりして抽象度以外の違いも入ってきそう。

静的にコードを解析すると一口で言っても解析の内容にはいろんな抽象度の違いがある。多分ぼくは型レベルの話までは適切な抽象度を選んで使えるのだけどSSAで表現するようなレベルだとまともに使えないと思う。使えるようになるにはどんな表現があって、どんな解釈をするのかとか他のレイヤとのどんな対応づけをするかを把握すると良いのだろう。

philosopy of software designとかに書かれてる。コンストラクタとかメソッドの定義とか引数の型とかでいい感じにできる。でもたまに辛いこともある。変更するのがだるいとか、そもそも人が管理しているやつで変更のためのコミュニケーションが面倒とか。あとは既存ユーザが多すぎて変更が大変とか、そこまで設計でカバーするのは大袈裟とかも入るかな。型パズルすれば間違えられないけど、定義をメンテナンスするのが辛くなるとか読みづらいとか。

そこで静的開発ツールを入れてしまう手がある。便利なツールがあるのはいいけど失敗すると辛いので、静的解析で(多少雑に)防ぐ方法。

TypeScriptなんかはそれをめっちゃ頑張った例だし、Goの未使用変数を許さないやつは頑張れば型システムでなんとかなるけど、そこじゃないでしょうということで静的解析ツールの領分になっていそう。型システムちゃんと作るのめんどいし。

上手な設計をする他にeffecttiveな使い方を促進する方法としての静的解析を推したい。

静的解析ツールというと何を思いつくだろうか。

学習による能力の獲得による喜びと課題解決に対する喜びでは、課題解決の方がでかいように感じる。それらは相入れない楽しみではなく課題を解決するために必要な学びをすることで、途中では学ぶ喜びを手に入れつつ、最終的には課題解決の喜びを得られる。さらに学ぶ途中では課題解決のために前進する喜びを追加で味わうことができる。

なお、それが本当に自分が学びたかったことだなのだろうか、みたいな悩みを抱くことはあるかもしれない。