どなたかが note で「書くこと」について書かれていたので，私も書いてみる。私は職業プログラマ（programmer）なので「書くこと」とはすなわちプログラム・コードを書くことである。

若い人は知らないと思うが，昔は「コーダー（coder）」という職業があった。プログラムを書くだけの人のことである。つまりプログラムを考える（設計する）人とプログラマを書く人は別々で分業していたのだ。なんでこんな面倒臭いことをしていたかというと，当時は「プログラムを書く」コストが高かったのだ。もちろん今はコーダーという職業は存在しない（はず）。書くコストなんかほぼゼロだからね。

（余談だが，私が最初務めていた会社のボスは紙テープが読めると言っていた。読めるということはつまりデバッグできるということだ。大昔は紙テープを切り貼りして（これが「パッチ（patch）」の語源）デバッグしてたらしい。手で紙テープに穴あけるとかw んで，コンピュータを起動するときは8つのリレースイッチを使って手でブートストラップ・コードをツッコんでたそうだ。だからプログラマはみんなブートストラップをソラで覚えていると言っていた。ものすごい時代だったようだ）

私がプログラマになった経緯は以前ブログに書いたので省くが，最初に仕事をもらって言われたのは「フローチャートなんか忘れろ」だった。「え～，研修でさんざんフローチャート書かせてたくせに」と思ったが，その理由は簡単で，仕事で書くプログラムはフローチャートなんかでは表せないからだ。その代わりに山ほど書かせられたのが状態遷移図だ。「状態」と「イベント」がマトリクスになってるあの図である。

当時は「プログラムを書く」とはすなわち「全ての状態とイベントを記述する」ことに他ならなかった。文字通り，余すところなく記述するのだ。なぜなら，記述していない部分があるということは，そのプログラムが正しく動作しない，少なくとも正しく動作することを証明できないということだったからだ。

この「正しく動作することを証明する」というのが，組み込みソフトウェアでは重要な要件なのだが，ちょっと考えれば分かると思うけど，この要件を満たすのは死ぬほど難しい。ていうか，無理。でもこの要件を満たすことに当時のエンジニアは血道を上げていたのである。

ここで転換期（paradigm shift）が訪れる。いわゆる「オブジェクト指向（object-oriented）」のプログラミング言語の台頭だ。「オブジェクト指向」とは，ぶっちゃけて言うなら，組み込み変数を含めたあらゆるもの（object）に内部構造，つまり「状態」と「イベント」が存在する言語体系もしくはそれを使った設計を指す。

しかしこれは古いタイプのエンジニアにはかなり困った事態となる。なぜなら（プログラマに対して）隠蔽された内部状態を持つということは，そのプログラムが「正しく動作することを証明する」ことができないことを意味するからだ。

で，どうしたかというと，あらゆる事象で「正しく動作することを証明する」ことを放棄した。あっさりと（いや，まぁ，いまだに組み込みでアセンブラや C/C++ で書いてる人たちは違うと思うけど）。だってそれは「不能解」だもの。その代わり限定された事象（運用条件）で「正しい」ことを求めるようになる。

実際，「オブジェクト指向」のキモは「いかに記述するか」ではなくて「いかに記述しないか」なのだ。プログラマにとって「記述しない」ことは「記述する」ことに含まれる。その言語体系における言外の文脈を読み取るのが今のプログラマの要求スキルなのだ。

これがプログラマにとって書く ...いや，記述することである。