自転車というものは、一度乗り方を覚えたら忘れない、が、メンテナンスは必要。
10年以上ぶりにCを書いたら
先日、仕事でちょっとしたデモプログラムをCで作ることになった。それは、とあるライブラリの使い方の一端を簡単に示すものである。50行ちょっとくらいの規模と想定される1ごく小規模なプログラム、また当該ライブラリの仕様も概ね把握済みであったので、まあ10分もあれば余裕でサクッと作れるでしょう、と思って始めたら、30分くらいかかった。
想定外に時間がかかったこと自体も少々ショックだったが、その時間がかかった理由が全体的に、実にしょうもないことばかりなのである。具体例を挙げると以下のような有様。
strcpy・memcpy2系列の関数における引数destとsrcの順序を忘れていて調べ直す。malloc3の返り値をvoid*から実際に利用する型のポインタにキャストするのを忘れてコンパイラに怒られる。memcpyやmemsetを使うくせにstring.hを#includeするのを忘れてコンパイラに怒られる。4fgetsで標準入力から取った文字列から改行文字を除けるのに、strchrの存在を忘れ、しばらくstrstr5で文字列検索していて、後から直す。- その
strstrにしても、引数の順序を忘れていて調べ直す。 - ライブラリを使うデモプログラム、を書いているくせに、そのライブラリを指定し忘れて6リンカに怒られる。
本質的にそのプログラムで何をどのような順序でしなければならないかは完全にイメージできているし、そのために使う必要がある道具=標準Cライブラリの機能が何であるかも基本的には思い起こせている。ただ、その具体的な使い方が細々と頭の中から抜け落ちており、いちいち調べなければ7ならず、そこに時間が取られている。かつては、調べることなくスラスラ書けていたものであるのに。
ここに、きちんとメンテナンスされていない、ガタガタの自転車を漕いでいるような感覚を覚えた。自転車の乗り方を忘れたわけではないし、実際に乗れている。ただ、あちこち動きがガタガタで、進み方が辿々しい感じなのである。普段使わない自転車も、たまには油を差しておかないとこういうことになってしまう、ということだろう。
ぱぶりっくすたてぃっくゔぉいどめいんすとりんぐあーぐす
ご存知Javaの「最初の呪文」public static void main(String[] args)である。
先のDI自作のエントリの最後でも少し触れたが、7〜8年ぶりのJavaプログラミングとはいえ、これまでJavaでプログラムを散々書いてきたのに、これをすんなり書けなかったことにはショックを受けた。もっとも、その7〜8年前の時点で既に、このmainメソッドを自分で書く事もほとんど無かったが。サーバサイドJavaをやっていると基本的に自分でmainメソッドを書かない。
そしてそれにも増してショックだったのが、件のエントリの注釈で「String[] argsを忘れてコンパイラに怒られた」と書いてしまっていた事だ。気付いてすぐにさらっと直してはあるが。別に引数の指定がないmainメソッドを定義したところで文法上の誤りではないので、コンパイラに怒られる事はない。ただ、当該クラスを指定しての実行時に、呼び出されるべきmainメソッドが無いのでエラーになる。この違いは十分分かっているのだが、咄嗟の言葉遣いで上掲の正しくない表現が出てしまうあたりに、しばらく触っていないうちに思考が鈍ったか？という残念感がある。
こちらも、最終的には自作DIコンテナ完成させるまでやった訳だが、それでも諸々鈍っている。あんなに手に馴染む道具であった筈なのに。
最近はクライアントサイドJavaScriptばかり
今の私の仕事は、基本的にはプログラムを書く事ではない。仕事で扱っている話題を人に説明するためにちょっとしたプログラムを作って見せる事はあるが、主目的はあくまでも説明であって、プログラミングはその補助手段である。上掲のCで書いたデモプログラムはまさにその例である。
先の例は「とあるライブラリの使い方の一端を簡単に示す」のが目的であり、説明の対象は明らかにプログラマである。Cで実装されたライブラリであるので、Cでちょっとしたプログラムを作るのが、プログラマに対しては分かりやすい。とはいえ、このような対プログラマの解説をする機会は少なく、どちらかというとプログラムの利用者に向けた解説を行う方が多い。そうなると必要なのは見た目の分かりやすさである。
遍歴でも触れたが、その用途のためには、大抵クライアントサイドJavaScriptを使っている。HTMLとCSSでそこそこ簡易的にUIを作れるし、何よりウェブブラウザさえあれば大抵どこに持って行っても動く8というのが良い。静的型付けの型システムを持つ言語の経験の方が長いので、varだのletだので変数宣言するのは気味が悪かったが、すっかり慣れてしまった。他にも例えばPromiseを使った非同期処理なども最初は面食らったが、慣れてみればよく考えられた仕様だと思う。
このJavaScriptのように少しでもやっていると慣れてきて、一方で上述のCやJavaのようにしばらくやらずにいるとかつての慣れが失われている、という事象が見える。この「自転車らしさ」は何となく語学にも通ずる所を感じる。使っていると慣れて来るが、使っていないと、使えなくなる訳ではないものの、慣れが失われる。プログラミング「言語」とは良く言ったものである。
非専業としてどこまで最新動向にキャッチアップすべきか
必要な時にちょっとしたプログラムをさっと作る能力を維持するには、時々であっても、また、小規模であっても、プログラムを書くという事をしなければならないと悟った。現に、時々デモプログラムを作っているJavaScriptを書いている中で、しょうもない理由で手が止まる事は少ない。またCについても、上掲のデモプログラムの後にもう一つ別のプログラムを書いたのだが、そちらは上掲のような手詰まりなく快適なプログラミング過程を辿って完成させた。これは自転車に油を注すようなものと言えよう。メンテナンスが大事。9
ただしかし、どこまで本腰を入れるべきかについては悩んでいる。プログラミングを本気でやるなら、関連の最新動向にしっかりキャッチアップしておきたいものである。しかし先述の通り、仕事の一環で少しプログラムを書く事はあるものの、プログラミングは私の仕事の主たるものでは全く無い。今後もプログラミングを主たる仕事の種にするつもりはあまり無い。また、キャッチアップと簡単に言っても、それを常に続けておくのはそこそこ負荷のかかる事であり、今の仕事や生活に紛れ込ませる余力もないというのが正直な所である。
新しいプログラミング言語や、既存のプログラミング言語に関しても新しいフレームワークが、様々に勃興していて、正直全く追いかけられていない。ただ、根源的なコンピュータアーキテクチャやプログラミング方法論に対するパラダイムシフトでも無い限り、必要になった時に勉強すればどうにでもキャッチアップできるだろうとは楽観的に見ている。思うにこれらは新しい自転車である。これまでの自転車とは違うものなので、例えば鍵の開け方とかギアの上げ方とか、細かい違いに最初は面食らうにしても、自転車である事には変わらないから、少し慣れれば問題なく乗れるであろう、と。それくらいの自信はあるつもりでいる。
一方で、こちらが自転車に乗っている横を、バイクで颯爽と抜かされていく、という未来はあり得る。即ち、全く新しいコンピュータアーキテクチャやプログラミング方法論の登場である。そういった話題は大枠で認識しておくべきなのだろう。例えば量子コンピュータの話題とか。古典コンピュータ10とは全く異なるアーキテクチャであり、これまでの考え方が通じない所ばかりである。専門に扱うのでなくとも11、概要や考え方、展望くらいは知っておかねばなるまい。
量子コンピュータと比べたら近視眼的な話題であるが、プログラミング方法論という点において、生成AIの台頭も捉えておく必要があるだろう。生成AIによるプログラム生成がプログラミング方法論に対する観念的・思想的な転換点たるかは、未来の識者の判断に任されるところではある。しかし少なくとも、今日のプログラミング実務において人の手間を現実的に減らすツールたりうるのは間違いない。
どこまでを追って、どこからは眺めておくのか、の線引きは難しい。
- 完成品はコメント等込みで68行になった。↩
-
ところで、これらの関数って日本語ではどのように読まれるのが一般的なのだろう。私の場合は
strcpy→「すとらこぴー」、memcpy→「めむこぴー」。より面倒臭い例としては、strncpyは私的には「すとらんこぴー」なのだが、流石に伝わらないかと思って人前では「すとらえぬこぴー」。↩ -
mallocを「まろっく」と読むのは一般的なのではないかと思う。意味的には「m」だけ独立なので「えむあろっく」とか読んだ方が良いのかもしれないが。しかし「まろっく」は語感が可愛い。まろっくまろっく。↩ -
mallocがstdlib.h定義なのは覚えていた。↩ -
これらについては、私的読み方は
strchr→「すとらちゃー」、strstr→「すとらすとら」。↩ -
gccを使っているので、有り体に言えば-lオプションの付け忘れ。↩ -
ググるなり、
manを引くなりして。↩ - 各種ウェブブラウザの挙動がここまで標準化されてきた事には隔世の感を覚える。↩
- このエントリの内容にはまるで関係ないが、10年近く乗ってない私の（文字通りの意味での）自転車、乗るとしたら自転車屋で諸々メンテナンスしてもらわないと駄目か。↩
- 量子コンピュータの文脈では所謂現行のコンピュータを古典コンピュータと呼ぶ。↩
- 大学〜大学院時代、量子コンピュータアーキテクチャや量子計算アルゴリズムを研究しているグループがあったが、彼らの発表を当時正しく理解できていたかの自信はない。↩
