カテゴリー: 古いポエム

 現在所有しているアイテムから2023年に読みたい本、プレイしたいゲームを大雑把に見繕った。本がおよそ150冊、ゲームが50本となった。本は文庫の小説から1000ページを超えるプログラミングの大著まで様々だ。ゲームは大体PS4のばかりになった。

 150冊というのは熱心な読書家なら不可能な量ではない。2〜3日に1冊読めれば達成できる計算になる。文庫の小説だけならできそうだ。しかし、1000ページ超の、気軽に読めるとは言えないような本まで含まれると、それだけで数週間〜数ヶ月はみておかないと厳しい。つまり、これは無茶な計画だということだ。少し下方修正しておこう。見繕った読みたい本のリストは、読破するのではなく、全編を読むべきか、切り上げてしまうべきかを判断できる程度までに読むところまでとしておく。これなら2〜3日あれば判断できる。本当は全部読みたいのだけど、無謀な計画は立てない。読む必要がないと判断できたら、ひとまず押し入れに入ってもらうことにする。

 書いてて思い直した。見繕ったリストは、どうも優先度が高い本ばかりのようだ。読まないといけないという本ばかりが選ばれているので、2〜3日かけなくても現時点で読むべきだという判断ができている。小説も同じだ。なので、数を減らさないといけない。半分くらいにしないと厳しい。それだと5日に1冊になるが、まだ厳しいかも知れない。小説のリストと解説書のリストに分けたほうがいいだろう。1冊当たりに必要な時間がかなり違ってくるので、同列に扱わないほうが分かりやすい。

 修正した。解説書が71冊で、小説が58冊になった。解説書はおよそ5日に1冊、小説はおよそ6日に1冊のペースになる。小説の方は割と余裕を持っていけそうだ。解説書はどうだろう。内容の濃さにも文量にもかなりばらつきがある。1000ページ超のを5日で読むのはほぼ不可能だろう。新書の200ページほどのものなら2日あればいけそうだ。あまり新書や文庫のはピックアップしていないので、余りを割り当てるとしても全然足りない。まだ下方修正が必要そうだ。絶対に読破したい本と、手を付けるところまでにとどめておく本の2段階にしてみよう。

 修正した。さっきの解説書の中から、2023年中に読み終える本を12冊だけ選択した。これなら十分達成可能に思える。1ヶ月に1冊のペースになるが、1ヶ月もかからなそうなのがほとんどで、1ヶ月で終われるかどうかというのが3冊ほどといった感じになった。とりあえずはこれでいってみよう。

 ゲームの方に目を向けてみる。50本を見繕った。ほとんどPS4のものだ。1本あたり7.3日の配分になる。1日中やってていいなら可能だろうけど、そんなことはできないし、たぶん苦痛になってくるだろう。そうなると、さっき提案したような、一度そこそこ手を付けてから、最後までやるべきかどうか判断するという方法を取らざるを得ない。ゲームの場合は本よりかは判断するのは簡単だ。本の場合は面白くないからやめるという判断は少し危険が伴う。最初だけで面白く感じられるかどうかがわからないし、必ずしも楽しみのためにやっているわけではない。ゲームの場合は楽しめるかどうか感じたままに判断しても、そんなに危険はない。後半になってじわじわと面白くなってくるというゲームもあるだろうが、最初の方でつまらないと感じたものを、そこまでやり込むことはできない。しかし、自分のゲームに対する評価は結構甘めだし、そんなに面白いと感じなくてもなんとなくプレイできてしまう性格なので、思い切って途中でやめる強気な判断ができるかどうかはちょっと不安だ。

 最初のリストよりはだいぶマシになった。それでも、計画通りに進めるのはやはり難しいだろう。読書やゲームにすべての時間を使えるわけではなく、かなり限られている。ちょくちょく計画を見直してリストを更新していかないといけない。できれば毎週くらいやったほうがいい。いっそ毎日やってもいいくらいだ。

 改めてこうやって来年の読書ゲームの計画を立ててみたあとに今年を振り返ってみると、なんとも無計画だったということが露わになった。今年新たに増えたアイテム数は159だ。そのうち30くらいはマンガだと思うから、130くらいだろう。コンプリートできたのは、マンガを除くと40くらいだ。約70%が未消化で、大体全体のアイテム数の未消化率と同じくらいになっている。これではいつまでたっても進歩しないわけだ。来年はアイテムを一切増やさない、くらいの決意がないと、同じことを繰り返しそうに思える。しかし、幸か不幸か、来年も出版が予定されている本で読みたいのがちょくちょく目についている。それらを入手しないという選択肢はない。なんとか増殖し続けるのに歯止めをかけたい。購入するのは新しい本だけという制限を課したらどうだろう。今年入手したアイテムの中で、今年に発売されたものは20くらいだ。雑誌のようなものも含まれているので、本はもうちょっと少ない。この程度なら増えても許容できそうに思える。でも難しいだろうなという気がする。

 必要なものを買わないでおくのと、未消化のアイテムが増え続けるのとではどちらが精神衛生上良くないのだろう。どっちもどっちに思える。表面上の消化率の問題よりも、必要だと判断してそれをちゃんと活用できたかということのほうが大事だ。いつか必要なときが来そうだから、という理由ならば入手しないほうがいい。金銭的な面でも無駄だし、脳にその本を所有していることを記憶させるスペースを浪費させてしまう。そもそも、本を読むこと自体が目的なわけではない。書いてあることを理解して、プログラミングの糧にすることが目的だ。本棚に本を並べるだけでプログラミングが上達することなど決してない。どこまで本に頼ればいいのだろう。もう、十分なだけの本を所有しているように思える。

 このままずるずると消化できたとかできなかったとか続けるくらいなら、いっそのこと、管理をやめてしまって、1年間くらい本を読まずにひたすらプログラミングだけをし続けるという荒業に出てはどうだろうか。プライベートなプログラミングではゲームプログラミングをやっているのだけど、どう考えてもこれまで作ったゲームの数も質も不足している。それは、必要な基礎知識や経験が不足しているからと言うよりも、ゲームを作ることそのものに取り組んでいる時間が少ないからのように思える。結局の所、ゲームを作れるようになるにはゲームを作るしかない。その時間を削ってまであの本を読んだとか読んでないとかに振り回されたり、精神をかき乱されて集中できなくなってしまうようでは、逆効果だ。そうはいっても、1年間何も読まずにいられるほど強い意志があるわけでもない。まだまだ修行が足りない。

一昨日、アマゾンで本を買った。本当に欲しかったのはUNIX Network Programmingの第3版だった。その他には、Introduction to Algorithm 第4版、Modern Operating System、Computer Networkなどが続く。大体欲しいのは英語の本ばかりだ。今は円安が続いているため、洋書は和訳書と比較して軒並み高くなっている。 原著とその和訳書が並んでいると、どうしても価格を比較してしまって、和訳書の方を買ってしまうことが多い。本当は原著のほうが欲しいことが大半だ。価格だけが問題ではない。洋書の新品も中古もマーケットプレイスでの海外の出品者からしか買えないことが多い。その場合、当然、手元に届くまで日数がかかる。それは仕方がない。それだけではなく、本当に届くのかと不安な気持ちで待たなければならないのが厄介だ。安心して変えるなら迷わず買っているというものがいくつもある。今回も、そういう理由で購入を見送った。

 必要としている本にかかる費用をケチるのは良くない。高いからと言って読まずにいたら、より多くの損失を出す可能性がある。費用をけちらないとしても、必要のない本を買うのも良くない。本棚のスペースと脳の記憶スペースも浪費する。脳の記憶スペースの浪費してくと、その本を早く読まないといけないと駆り立てられるような心理状態に追いやられる。スペースには限界がある。いつまでも放置状態のままスペースを所有していることはできない。あまりに長い期間放置しておくと、そのうち気にならなくなってくる。そうするとまた新しい本を受け入れるだけの余裕が出てくる。そして、またスペースを浪費して、とループに入る。もうこんなことをずっと繰り返してきているように思う。駆り立てられているのが通常の状態なのか、そうではないのかわからなくなっている。

 数年前に初めて電子書籍のサブスクリプションに加入した。必要のない本を購入しないようになる効果は絶大だった。ちょっとした分野の解説書は大体揃っている。例えば、Python入門とかDocker入門みたいな本はたくさんある。そのため、大量に出回っているそういった類の本を購入しようという気持ちは完全になくなった。その分本を買う量が減ったというのではなく、サブスクリプションでは提供されないような本に目が行くようになった。どんなのかと言うと、最初に上げたような重厚な本がそうだ。料金として支払っている分だけ回収しようという気持ちは不思議と湧かない。料金が安いせいもあるだろう。良いことなのか悪いことなのかどうかというと、良いほうだろう。必要ならいつでも読めるという安心感を与えてくれるだけでも料金分の価値はある。必要のない本を買って、無駄に駆り立てられるような状況になる機会はぐんと減った。

 ここ数年の間で、本とゲームソフトの買い物の仕方が随分変わった。以前は、大型の中古本屋によく足を伸ばして物色しに行ったものだ。今ではせいぜい月に1回、もしかしたら半年に1回とかそのくらいしか行かなくなってしまった。お店に入ってなんか気になるものがないかと物色すると、かならずちょっと気になる程度のものが目に入ってくる。そうなると、今買い逃したら二度と手に取ることはなくなると駆り立てられて、それまでは全く欲しいなどと思ってもいなかったものを買ってしまう。そうやって手に入れたものは、大体は本当に必要なものではなかったと後で気づく。そんなことをしばらく繰り返していた。全部が全部不要なものというわけではない。中には本当に自分にとって価値があって、買えて良かった、偶然出会えてよかったというのもいくつかある。でも、残念ながら多くはそうではないようだ。いくつかの中から一部を取得するための必要経費とも言えなくもないが、あまり回収効率は良くない。

 ゲームソフトもよく安くなった中古のソフトを買い漁っていたのだけど、もうそれも全然やらなくなった。それも、メインのゲームプレイ環境の中心を、PS4のダウンロード販売に完全に移行してしまったからだ。ダウンロード販売の場所であるPS Storeでは、常に何かのセールをやっていて、かなり安く買える。大体中古ソフトにつけられている価格と同じくらいになっている。セール中に買わないといけないと駆り立てられるのは、中古ショップを徘徊していたときとあまり変わらないかも知れない。実際、かなりの量のソフトを購入して未プレイのままだったりする。そう考えるとあまり買い物のスタイルは変わってないのかも知れない。本当にプレイしたいゲームを買うのではなく、セール価格を見て、今買わないともう買わないかも知れないと、自分で選択していると言うよりは買わされている感じがしないでもない。しかし、限定的にはなってきた。以前は中古ショップのラインナップを一通り舐め回していたので、所持している古いハードのソフトまで手を伸ばしていた。ショップに行かなくなったので、もう古いハードのソフトが増えることはあまりなくなった。PS4の中だけで完結している。

 所持している本、ゲームソフト、音楽ソフトはブクログで管理している。今の状況は、全アイテム数が2241ある。そのうち未消化のものは大体1600だ。およそ70%が消化できていない。ゲームはもっと顕著で562本中493本が消化できていない。およそ87%が未消化となっている。少しは手を付けたものは、予想ではは50%くらいだと思う。それにしたって半分は全く手を付けていないということになる。これは、買うだけ買って開封すらしていないのと同じ状態だ。音楽ソフト、大体はCDのことなのだけど、これはあまり買わなくなった。買ったとしても少なくとも1回は全部聴いている。そんなに悪い状況ではない。マンガもあまり買わなくなった。そして、買ったとしてもやはりちゃんと1回は読んでいる。問題なのは本とゲームソフトのようだ。

 来年は、本とゲームを消化することを頑張りたい。ゲームをプレイするのに頑張らないといけないというのはおかしなことに思える。でもそうしないと新しいゲームも買っても、また増えた、と思うだけで、ハッピーな気分になれない。しかし、1年で500本消化するのは不可能だろう。1年どころか生きている間に可能なかどうかも疑わしい。ここは思い切った決断が必要だ。処分しようという気にはならないけど、一度、最初だけやってみて、直感で面白いか、面白くなる可能性があるかどうかを判断してしまう。本当はちゃんとプレイしないと面白いかどうかはわからないものだけど、500本に対してそれを行うのは不可能だ。割り切るしかない。不幸にも合格ラインに到達しなかったものは、押し入れで眠ってもらうことにする。これでまずは100本くらいにまで絞ることを考えよう。本も同じように500冊くらいまで絞ろう。本の場合はゲームソフトほどには手放すことに抵抗はない。いくらかは手放すことも必要だろう。

 今年も残り2日となった。大掃除ということで、来年読むべき本とゲームを整理して、気持ちよく新年を迎えるようにしたい。

 停滞気味だ。ブログの目標に1日1本をを掲げた。これを書いている時点で、今日を含めてあと12本足りない。一昨日から他のことをほっぽりだしてブログだけに集中したが、4本しか書けなかった。1日1本、1ヶ月で31本をきっちりこなさないといけないわけではない。あくまで目安であって、数本不足しても特にサボっていたと責められることはない。10本不足するとちょっと多い。なぜこんな不足してしまったかと言うと、12月16日から26日の間に、集中して読書に時間を割り当てたためだ。その間がすっぽり抜けてしまった。それよりも前にも、1日か2日は空いたりはしていた。一昨日から2日で4本で、2日分回収した。それで現時点でぴったり10日分不足となった。

 10日分回収するというのはなかなかの大仕事だ。また、こっちに時間を使えば、別の日課の方にも影響が出る。そうすると、今度はそっちを回収しようとしてまたこちらに影響が出ると、行ったり来たりになる。並行して進めないといけない。並行処理は苦手だ。並行処理とまで行かなくても良い。1日の終わりにアイドル時間を使って、ちょいちょいと処理してしまえばいい。アイドル時間は確実に確保できるとは限らない。スケジュールしておくと良い。この時間に処理を開始すると決めておく。余裕を持って1時間くらいみておこう。23時から24時の間に、1日の振り返りとして投稿する。ブログといってもポエムだと前置きしているので、ポエミーになっても恥ずかしくない。それならば、思いついたことをサクサク書いていけるだろう。とにかく、あまりにビジーになっていないでもない限り、その時間にきっちり処理を走らせるようにすることだ。これは来年からの計画だ。

 計画通りにいかなかったときのことを考えよう。今のように10本も溜まってしまった場合をどうするかだ。単純な方法は、他のことに割り振っていた時間を削って、遅延している部分に割り当てるという方法だ。これは安直だ。何も考えずに他の時間を削れば、当然、そちらの方が止まってしまう。止まっても支障のない部分を削っておけば良いというのも難しい。止まってもいいものは、最初からやる必要もないことではないか。はじめから計画に入れる必要がない。計画を見直すべきだ。仮に計画に無駄なものが含まれていなかったとしよう。その場合はどこにも削ってしまっても良い処理がない。遅延は許されるかも知れない。その遅延はまたどこかで回収されなければならない。一つが遅延すれば、それを回収するためにまた別のところを遅延させなければならない。こうして連鎖して計画全体が遅延してしまう。

 もう一つ安直な方法について考えてみよう。それは、遅延させるのではなく、限られた時間内で不足した分を回収できるように、処理の負荷を下げるように、クオリティを落としてしまうことだ。ブログの場合、取ってつけたような、お茶を濁したような投稿をでっちあげることだ。こうして形だけ取り繕って、割り当てられた時間で、本来かかるはずだった時間を短縮して多くのタスクを処理していく。最初の計画のところまで到達したら、通常のクオリティに戻して、計画全体を通常運転に戻す。この方法はブログのような、クオリティを上げ下げすることで、必要となる処理時間も柔軟に制御できるような処理でのみ可能ととなる。他にそのようなことが可能な処理は、コーディングもそうだろう。クオリティを下げれば、悪い設計で良いのならば、必要となる時間を短縮することが可能だ。もちろん、コードのクオリティを下げるのは許容されるものではない。今、自分が書いているブログのように、クオリティを下げてもおそらく誰にも迷惑がかからず、何の影響も与えないようなものなら、少なくともコードのクオリティを下げるよりは許容できるかのように思える。このブログのクオリティを下げて処理時間を短縮して、数を稼ぐというのは、一見妥当な方法にも思える。しかし、実はそうではない。2つの点で考えてみることがある。

 まず、クオリティを下げても何の問題も発生しないようなブログは、もともとそれ自体やる価値のあるものなのだろうかという疑問だ。このブログは何かを求めて始めたわけではない。クオリティなど追求していなかったし、今も追求していない。それなのに、1日1本というノルマを課したせいで、毎日の計画の一部に組み込まれようとしている。大体、夜11時から12時の間に書こうと思っている。この1時間というのはかなり貴重に思える。もしやっていなければ、かわいい猫と遊んだり、気がかりなドラクエを進める時間が確保できる。この貴重な時間を削ってやっているのだ、いかに何の見返りも求めないポエムであったとしても、意識的にクオリティを下げても良いのだろうか。あまりにクオリティを求めすぎるのも問題だ。6時間かけてやるようなら、そんなものはやらないほうがいい。限度がある。1時間でやると決めたら、それだけでやるのが良い。その時間内でできるだけのことをやるという程度にとどめておけば良い。素早く文章にまとめ上げられるというスキルはなかなか貴重だ。だが、クオリティを落としてでっち上げるというスキルは重要じゃない。もし、ノルマを課したことによる義務感からでっちあげようとしているなら、そのブログには価値がないように思う。

 もう一つはより深刻だ。クオリティを下げて時間を短縮するというスキルが身についてしまうことが、逆に悪影響を及ぼす可能性がある。別のところの重要な処理、例えばコーディングでもブログと同じようなノリで、時間を短縮するためにゴミみたいなコードを書いて、とりあえず動くだけの取り繕ったようなコードを生産してしまうことに罪悪感を感じなくなってしまうことはないだろうか。否定できない。コーディングにかける時間も、ブログと同様に限度があるが、例えば、Hello Worldに10時間かけたらやりすぎだ。もし、目的がプログラムを動作することを確認するためだけというのなら、たぶんやりすぎだ。一方、目的がHello Worldを真に理解することであるなら、それでも全然足りない。その場合は、最初から目標をそこに設定しておく必要がある。時間がかかるからといって、分かったようになったつもりになってコードを書き続けるのは危険なので、十分な時間を確保する必要がある。もし、時間内で終わらせるためにクオリティを下げる悪習があると、時間をかけようとする気すらなくなってしまうことだろう。

 この2点の問題を考えると、数を稼ぐためにクオリティを下げるという選択肢は考えられない。 今月のノルマ達成は諦めるのが良さそうだ。反省点としては、計画の不完全さだ。ブログに対する優先度がかなり低かったのもある。それよりも、抜けてしまった日をどこで回収するべきかという、保険をかけていなかった。予備の時間を確保していなかった。また、12月16日から10日間、道を逸れて読書にハマってしまうという予想外の出来事があった。そのときは、後で回収すればいいかと思っていた。まさかポエムを書くのがこんなに大変な作業だとは思ってなくて、軽くみていた。厳密に計画通りに進める必要はないのだが、こまめに計画を見直して、重要なのが何かを確認していったほうがいいだろう。少なくとも1週間、できれば毎日がいい。

 

 Linuxでのゲームプログラミングについて書いてみよう。このテーマは自分にとって重要なので、定期的に考えてみるのが良さそうだ。

 ゲームプログラミングの前に、ゲームプレイについて考えてみることにする。一口にゲームといっても、その形態や規模や目的やによって様々だ。コンピューターを使わないゲームももちろんある。しかし、もっぱら関心があるのはコンピューターを使ってプログラミングで作ることができるコンピューターゲームなので、ここで単にゲームといったら、コンピューターゲームのことを指しているものとする。

 ゲームの需要や市場は昔に比べてはるかに拡大してきて、同時に多様化している。ゲームプレイヤーの数は増加しているように思える。一方、ゲーム開発環境が整備されてきたために開発の敷居がぐんと下がって、リリースされるゲームの数も増えてきている。どちらかというと現在は供給過多で、プレイヤーを取り合うような状況にあるように思う。その要因は何なのかということには触れないでおこう。ともかく、ゲームをプレイする人も作る人も増えてきていて、今も傾向は続いているという事実だけを受け止めておこう。このことは肯定的に受け止めることができる。昔はもっとよかったなどとは思わない。テクノロジーの発展によって、昔は技術的に実現不可能だったことが可能となったり、製作者の多様化によって思いもしないような発想のゲームが登場したり、プレイヤーの多様化によってその要求を満たすために、多様なゲームが作られたりする。一部のマニアだけに与えられた特権のような楽しみではなく、多くの人がゲームを楽しむことをできるようになるのは、良いことだ。

 ちょっとポジティブ思考すぎるかもしれない。それに、自分は何も貢献していないのに良いとか悪いとか語るのもおかしなことだ。しかし、ゲームをプレイする人が増えて、社会的にも受け入れられるようになったりする状況を好ましく思っているというのは本心だ。この場合は社会的という言葉に悪い含みは入れていない。社会的に受け入れられているという具体的な状況について、何をイメージしているかと言うと、例えばeスポーツを始めとする舞台でプロゲーマーが活躍している状況だ。なぜこれが社会的なのかというと、生産性があるからだ。生産性とは富を生み出すということだ。社会では生産性のないものよりもあるもの残そうという力が働いている。プロゲーマーのプレイを中心に、名誉と報酬を巡って生み出されるストーリーや演出は、ゲームをやる人はもちろんやらない人にも魅力的であって、惹きつけるものがある。これはアスリートや棋士が社会的に果たす役割と何の違いもない。それらのような伝統的な勝負師の世界の見世物のように完全に成功しているかどうかまでは知らない。少なくともファミコンしかなかった時代に、将来プロゲーマーになりたいと言う狂気じみた少年少女が拒絶されたほどには、現代で将来プロゲーマーになりたいと言っても狂気だとまではみなされないではないだろうか。

 eスポーツはゲームの中でも特殊な環境だと言える。もっと多くの人が楽しんでいるゲームは、プレイすることによって直接的な報酬を得たり名誉に繋がるものではないものが多い。極端な例をあげると、マインスイーパーでハイスコアを競っている人は、おそらく何も見返りは求めていないだろう。オンラインで世界ランキングがあったりすれば、もしかしたら話は違ってくるかも知れないが、あまり一般的ではない。大体は、デスクワークに飽きて眠くなったときに、気晴らしにプレイしたりして、ついついやり込んでしまうということが多い。戦略的にどのようにやれば上達するかということについて考えを巡らすかも知れない。それでも、そのことで報酬を得ようと考える人は、いたとしてもごくわずかだと思う。大体、それなりに長いゲームの歴史の中で、世に送り出されてきたゲームはこのようなものから発展してきた。このようなゲームの特徴は、失敗しても失うものが少なく、成功したときにはそれなりの達成感が得られる、という特徴がある。単純なゲームの場合、失うものというのは、大体そのプレイに費やした時間と作業のみになる。このリスクが0だと、成功したときの達成感というのが0に近くなってしまうので、望ましくない。ゲームをプレイするのは、クリアしたときの達成感だけがゲームの目的ではない。ただゲームの世界の中に入っていくだけで没頭できるというのがある。マインスイーパーの場合は、地雷原を慎重に探索するという、現実ではなかなか味わえない緊張感のある世界を味わうことができる。目の前の作業から逃れて現実逃避したい場合にマインスイーパーを起動してしまうのはそういう理由もある。

 ゲームの世界にどれだけ入り込んでいけるかを表す感覚は、没入感などという。ゲームの面白さを決める要因としては重要だ。古典的にはゲームのグラフィックスやサウンドがその大きな役割を担ってきて、よりリアリスティックに、あるいは表現豊かになろうとしてきたのは、それによって没入感を高めようという狙いが見られる。ゲームのハードウェアの進化は、より高い表現力を求める力に引率されてきた。現在のゲームはマインスイーパーのようなゲームとはかけ離れているように見えるのだが、没入感という点においては、根っこは同じところにあるとみなしてもいいだろう。その時代において、ゲームはハードウェアとソフトウェア技術の限界で世界を構築して、プレイヤーを引き込もうとする。他のゲームと差別化するためには、もっとこうこうしたい、という要望がうまれ、すぐにハードウェアの限界に達してしまう。そして、新しいハードウェアが生まれ、ハードウェアによって制限されていたソフトウェア技術が解放されて、新しい表現が可能となる。この繰り返しによって発展してきたわけだけど、どうやらこの進化モデルは大成功を収めているようだ。最近のゲームをプレイする人で、現在のゲームの表現力に驚かされたことのない人などいないだろう。しかも、この進化はまだとどまることを知らない。最先端のゲームの技術を研究開発しているリーダーたちは、おそらく、現実世界と区別がつかなくなるようなところまでを視野に入れているのではないだろうか。それには、ハードウェアとソフトウェアという技術的な進化だけで達成できるわけではない。いつかは、現実世界と区別できなくなるような表現が可能な技術が手に入ることは期待できる。そのとき、その世界に移り住むことができるかどうかはまた別問題で、現代社会ではまだ良しと見なされないだろう。先にゲームが社会的に受け入れられるようになってきたのを肯定的にとらえているという理由がそこにある。まだ、生産性のないゲームプレイに没入することまでを良しとする風潮ではないが、一部は良しとされるようになった。テクノロジーの進化と同様に、規範もゆるやかに進化していくのならば、いずれ受け入れられる時代が来るかも知れない。

 Linuxとプログラミングについて書くつもりが全然違う方向に行ってしまった。今から取ってつけたように書くのも、場を取り繕うだけになってしまうので、今回は書かないでおこう。またこのテーマは何度も再利用するだろうから、その時にとっておくことにして終わる。

 How Linux Worksという本の和訳版を読んだ。和訳されたタイトルは、スーパーユーザーなら知っておきたいLinuxの仕組み、というのだけど長いのでそうは呼ばない。色々と学んだことがあった。特にデバイスのようなカーネルに近い部分や、systemdによるサービス管理の方法などの領域に対するスキルポイント配分が完全に不足していたということを認識した。今後その不足分を補っていくように意識していかないといけない。別のところでは、ネットワークを扱っていて、そこは割と読みやすく感じたので、そこまでスキルポイントが不足していたことはなかったと認識した。積極的に割り振った記憶はない。日常的にネットワークの設定を行ったりするから、身近な話題であったというのが読みやすかった理由だろう。ネットワークの設定といっても、専門的なことではなく、インターネットに繋がらないと家族などに頼まれたとき様子を見にいったりする程度だ。それだけでも結構違ってくる。普段は自分のPCのLinuxでネットワークの設定をしたりもするので、それも影響していただろう。これも大したことしていない。ちゃんとインターネットに接続できるか、確認して調整したりするといった程度だ。その程度でもちゃんと話しについていけた。合格基準が低いように思われるかも知れないが、デバイスの章なんかは、全く意味不明だったので、それと比較してしまえば、遥かに合格だったとみなしている。

  デバイスがだめだったので、次やるべきことはデバイスについて強化するのが順当な学習プランだ。あとsystemdにもうちょっと親しんでおくというのも忘れてはいけない。その一方で、ネットワークについてもっと知りたいという欲が出てきた。これは良い傾向なのだけど、時間配分が難しい。デバイスをまず先にやるべきなのだが、ネットワーク程は関心がないというのが本音でもある。試しにやってみたらいいかもしれない。デバイスドライバのプログラミングが良い入口だろう。そもそもデバイスってなんなんだという疑問さえある。/devにあるデバイスファイルと、現実のデバイスとの繋がりが全くイメージできない。あとはカーネルだ。カーネルとデバイスは近いところにある。この2つについて学習する必要がある。全くやったことないのだけど、どういうわけか、カーネルやデバイスドライバのプログラミングの本を所有している。今、ちょうど必要性を感じたので、これを機に取り組んでみるのがベストタイミングだと思われる。ネットワークはどうするか。これも今やってみたいと思っているところなので、またベストなタイミングだと思われる。

 ネットワークプログラミングにはバイブルのような本が存在している。UNIX Network Programmingというタイトルの本がそうだ。初版を所有しているが、かなり内容が古いようで、第2版では大きく書き換えられて、原著は第3版まで出ている。しかし、残念なことにもう新品の入手が困難で、中古でもそれほど数が出回っているわけではないようだ。ただ、入手不可能と言うほどではない。これを期になんとしても入手しておきたいという欲が湧いている。

 書いている途中にAmazonを物色し始めた。やはり第3版の中古が割と安く出品されているので買ってしまおうと思ったのだが、他の出品と比べて異様に安いのと、レビューをみると不安が捨てきれなくて、断念することにした。信頼できる国内の出品もあるのだが、価格が1万円ほど高くなるので躊躇してしまう。その代わりにVolume 2の和訳版を中古で安く出品されているのを購入しておいた。今は円安ということもあって、どうしても洋書が高くなってしまう。高くなるだけならまだしも、事実上入手が難しいことすらある。もっとKindleで電子書籍化が進んでくれれば安心できる。UNIX Network Programmingのような、定番で重要な本はぜひ電子書籍化してほしいと願う。

 というわけで、目当てのものを入手しそこねた。今所持している初版でなんとか好奇心を満たそうかと思う。どの程度古くなってしまっているのかわからない。ネットで新しい情報と見比べながら読めば、なんとかなるだろう。そもそも、今はデバイスとsystemdをちゃんとやっておくべきだ。本格的にネットワークプログラミングを始める機会を失ったことは、ある意味好都合だ。自分で気の向くままに興味のあることばかりやっていたら、いつまでもバランスの悪い偏った不格好な装いになってしまう。定期的にちゃんと鏡を見て見た目を正す機会を設けることも必要だ。鏡と言っても、前に立つだけで姿を移してくれるような便利なものもないし、問いかけるだけで世界で一番美しいのは誰か答えてくれるような魔法の鏡もないし、テクマクマヤコンと謎の呪文を唱えるだけで変身できる秘密の鏡ものなどありはしない。今どんな見た目をしているのかは、何かの判断基準に沿って、比較してみることが良い方法だ。もし、その基準が歪曲されていたら、誤った判断をしてしまう。例えば、魔法の鏡に世界で一番美しいのは誰か答える鏡に問いかけるのは危険だ。そんなことをしてみても間違った感情しか生まれない。判断を鏡に委ねるのではなくて、できるだけありのままの姿かたちを移してもらうことだけを期待して、どこが不格好なのか、バランス良い見た目になるのはどこを修正すらばいいのか最終的な判断は自身が下すべきだ。そのような道具というのはあまりない。本はある分野に特化していて専門的であるのが普通だ。専門的なことを求める読者の要望に応えようとしていて、だからこそ価値がある。平均的なところにとどめておきたいという変わった要望に答えるような本はあまりない。

 この本に関して言うなら、タイトルが示す通り、Linuxの仕組みについての専門書と言える。もし、他のメジャーなプラットフォームである、Windows、Web、スマホなどについてもバランス良く身に付けたいと考えている読者にとっては、これはLinuxの専門的な内容であって、バランスを整えるための道具とはならないだろう。同じような本をそれぞれの分野にも見つけ出さないといけない。しかし、Linuxに限定して、その領域内でバランスをよく身に着けたいと考えているのなら、この本は専門的というよりも平均的にバランス良く解説した内容だと思える。どの章も平均的な水準で解説されていると自信を持って言うことはできないのだけど、そういう風にみなしておこう。そうしておくことで、もし、読んでみてどこかが難しすぎたり、逆に簡単すぎたりしたら、本の方に偏りがあるとみなすのではなく、それだけスキルポイントの振り分け方が偏っていたと解釈する。もし全部簡単すぎると感じたのなら、時間を無駄にしたと考えずに、十分に基礎を身に着けていると自信が得られたので有意義だったとでも思っておくのがいい。全部難しすぎると感じたら、スキルポイントよりもベースとなるレベルが不足しているので、経験値稼ぎが必要な兆候かもしれない。最も理想的なケースは、ある章は簡単だったけど、別の章は難しかったという感想をもつ場合だ。この場合は、難しかった章の分野にスキルポイントを振り分けるようにすることで、偏りを正すための道具となる。定期的にこういうもので見た目をチェックしておくことも悪くないという新しい視点が得られた。ちょっとばかし前向きで肯定的な考え方すぎるかも知れない。

 .NETをちょっとだけ触ってみた。きっかけは、Packtのライブラリを眺めていたら、新しい.NET 7の本がおすすめに表示されたことだ。.NET 6のころから、同じ本の前の版がおすすめに出てきていて、頭の片隅にその名前はちらついていた。それよりももっと前にから.NET Coreの名前は知っていて、クロスプラットフォームになってLinuxでも利用できるようになったことは前から知っていた。そうはいっても、基本はWindowsでVisual Studioを使って開発する環境だろうという先入観があるので、なかなか手を出そうという気にはなれなかった。今回も、本格的に取り組んでみようという気はまるでなくて、どんな感じか軽く味見してみるだけのつもりだった。.NET Coreに対する誤った先入観は、これまでの.NET Frameworkのサブセットであって、すべての機能を提供するものではなく、完全なものではないというものだった。そうではなくて、どうやら従来の.NET Frameworkに取って代わって置き換えてしまうロードマップが示されているようだ。そして、順調にその筋書き通りに進んできていて、もはや新規に.NET Frameworkをベースに開発を始めるような状況ではなくなってきている。とりあえず.NET FrameworkをmacOSやLinuxでも使えるようなオプション的な扱いではない。Windowsでも主流の開発プラットフォームとなっていくのだろう。もともと.NET Coreという名前で区別されていたけど、Coreの単語はなくなって、単に.NETだけに改名されたことからも、もう試験的な段階を終了して順次置き換えていく段階に来ていることが分かる。.NETが登場したのが大体2000年頃だっとすると、もうおよそ20年以上経過している。この時間はソフトウェア時間にするとかなり長寿だと言える。もっともWindowsやVisual Studioはもっと長寿ではあるが、それはソフトウェアというより製品として長寿であると捉えることができる。何にしても、この20年のという時間は十分に長く、ついに訪れた最も大きな転換期だと考えられる。

 ここまでで.NETがどうとか書いたけど、.NETの経験はほぼない。 経験もないのによくそんな偉そうに語れるなと、自分でも思わなくもない。なぜこうやって.NETを外観から眺めようとしているかと言うと、ただ大きな流れに身を任せたまま開発環境を乗り換えていくのは多少の危険が伴うからだ。逆に全く流れに乗らないというのもそれはそれで危険だ。少しは波に乗っていかないと、楽しくもないし、時代から取り残された古物になってしまう。やり過ぎはだめだ。大体、目に入ってくる、流布される情報は自然に発生したものではなく、何らかの意図が含まれている。大げさな広告には警戒する必要がある。何でもかんでも無警戒に新しいものに飛びついていったら、本当に自分がやりたいことは何なのかをすぐに見失ってしまう。たとえ広告に飛びついたとしても、もし、その対象が自分に合っていると判断できたのなら、それは悪いことではない。買い物をするとき、例えば新しいキーボードが欲しいとしたとき、店頭で買うにしろネットで買うにしろ、他の製品と比較したり、情報を仕入れたりして判断を下す。商品の情報には購入してもらおうという意図が含まれているし、店頭に並んでいるものも買ってもらおうと工夫して展示されているはずだ。それを全部否定する必要などまったくない。問題が発生するのは、判断を見誤らせるほどに過剰な広告が行われることだ。プログラミングに関連すると、昔だとJavaとオブジェクト指向は過剰だった。今ならPythonとAIやデータサイエンスがだろうか。これらの情報は、正しい判断力を失わせるだけの十分な誇大広告がなされているように思える。それでも、繰り返すと、判断力を失わずに冷静に接することができるのなら、全然悪いことではない。AIの技術やデータサイエンスがこれからのソフトウェアの領域で大きな位置を締めるようになっていく流れには逆らい難い。市場価値を高めるとか、自己ブランド化というくだらないものを無視しても、それらの技術を習得していることは、なかなかおもしろい経験になりそうだ。

 .NETに話を戻すと、そこまで過剰な広告は行われていない。どちらかというと控えめだと言っていい。これを使えばあなたはハッピーになれますとか、世界平和が訪れますみたいな怪しい文句は含まれていない。ちゃんと自己判断を下せるような情報だけを提供しているように見える。判断を開発者に委ねているように見える。今の時代に合ってはなかなか珍しいことにも思える。大量の新しい開発者を呼び込んで、一世を風靡するようなムーブメントを起こそうなどという意図はないだろう。警戒しておきたいのは、クロスプラットフォームになったことで、Windows以外のプラットフォームでの囲い込みを行おうとしているのではないか、ということだが、どうもそのような動きにも見えない。まったくないということはないだろう。誰にも使われないソフトウェアを開発したい企業などないだろう。しかし、Linuxのアプリケーション開発やWeb開発すべてを置き換えようなどという野心的な動きはないし、選択肢の一つして追加されただけに見える。むしろ、もっと積極的なサポートを期待する人も多いのではないだろうか。例えば、Windows.Formsに変わるクロスプラットフォームなデスクトップアプリケーションの開発環境などだ。もし実現してしまったらLinuxのデスクトップ環境に混乱をもたらすかも知れない。なので、あまり良いものではないかも知れない。それはちょっと保守的すぎるかも知れなが、そういう要因に加えて、企業によってもたらされる、言いすぎかも知れないが独占的な技術によってもたらされる変化は好まれないかもしれない。とにかく、一概に歓迎されたり排除されたり極端な反響をもたらすものではないようだ。あまり大きな反響がないのは、もはや、それほど革新的な技術というわけではないと言うのもあるのではないだろうか。.NETは言語を選ばない環境ではあるけど、中心になるはC#であって、それ以外の選択肢はオプション扱いだろう。C#が決して革新的な言語であるとは言えない。神の存在・不在を証明したり、世界平和をもたらしたりはしないだろう。そんな言語はこれまでも、おそらくこれからも存在しなかったが。

 肝心の開発環境を使ってみた感想はどうなのかというと、かなり良い感じだ。dotnetというコマンドラインインターフェイスを通して、プログラムのビルドや設定や管理を行うようになっている。コンパイラはこのdotetツールの裏側で仕事をする。もはやVisual Studioのような制約の多いソフトウェアに縛られることはなくなっている。いま主流となっている現代的なプログラミング環境のスタイルから大きな影響を受けた結果だと言える。Visual Studioは必須ではないが、もちろんサポートされているようだ。そして、その代替として、VSCodeに一極集中していく未来も見えるが、それは単にVSCodeが扱いやすく広く使われているから来る結果に過ぎないだろう。もし、VSCodeより扱いやすい開発ツールがあれば、自然とそれにシフトしていくことになる。

 今後、C#を中心にプログラミングをしたいとは全く思わない。しかし、.NETをツールボックスに入れておくことで、何かしら必要なときが来たとき引き出せるようにしておきたいとは思う。それに、なかなか楽しい。目眩のするような巨大なライブラリと言語仕様が組み合わさって絶妙なバランスで成り立っている。その中に飛び込んでみるのはなかなか新鮮な体験だ。

今日3本目の投稿。キーボードについて考えてみる。今、主に使用しているPCは2台ある。そのうち1つはUS配列で、もう一つは日本語配列のキーボードを使用している。この状況は良くない。ずっと日本語配列のキーボードを使ってきていた。そこそこ値が張る代物で、打ち心地も素晴らしいくてとても気に入っている。最近、といってももう1ヶ月以上経っているけど、新しいPCを購入した。そして、ひょんなことからUS配列のゲームミングキーボードが手に入ったので、それを利用している。打ち心地はそこそこだけど、無駄に光るのがなかなか良くて、しばらく使っていたらこれにも愛着が湧いてきた。そして、このUS配列のキーボードがメインとなった。このブログもそのPCから書いている。

 US配列にもだいぶ慣れてきた。最初はEnterや角括弧を何度も間違えていた。プログラミングでは多用するのでこのような基本的なタイプミスは思考が中断されて、効率が悪すぎる。さっさと買い換えればよかったのだけど、US配列のほうが良いところもある。@や引用符なんかの位置はUS配列のほうが良い。また、テキストエディタなどのキーバインドはUS配列が基本に考えられているので、そちらの方が自然に感じられる。そういう理由で、しばらく使ってみることにしていた。もうほとんど日本語配列のを使っていたときと同じような感じで使えるようになってきた。

しかし、今度は逆の問題が発生する。旧PCで作業をするとき、びっくりするくらいうち間違える。丸括弧や引用符などは、間違えずに打てることの方が少ないくらいだ。この混在した環境はとても良くない。日本語配列かUS配列かという問題が些細に思える。プログラミングでもそうだが、例えば、インデントは4にするか2のどちらが優れているかよりも、 どちらかに統一して、少なくとも同じプロジェクトの範囲では、一貫してそのスタイルを使い続けることのほうが遥かに重要だ。キーボードもそうだ。打ち心地がいいとかよりもずっと重大だ。まず、どちらかに統一できることが大前提になる。どちらかに揃えることできることが可能であって初めてどちらの配列のほうが良いかについて考えを巡らすことができる。

 今、所有しているキーボードの殆どが日本語配列になっている。ラズパイ用のワイヤレスキーボードが2つある。それにラズパイ400も日本語配列で、これは交換不可能だ。あとはあまり使用しない古いノートPCもやはり日本語配列だ。また、US配列のHHKを1つ所有しているけど、PS/2端子なので変換器をかまさないと使えないので使用していない。もしUS配列に統一するとなると、少なくとも3台買わないといけない。そして、今ある3台が不要品になってしまう。どうがんばってもラズパイ400とノートPCはUS配列にできない。こういう状況を鑑みると、日本語配列で統一するのが素直な選択肢のようだ。それならば1台を買い足すだけですむ。

 本当にそれでいいのかちょっと迷いがある。まず、見た目の問題で、どうみてもUS配列のほうがシンプルだ。日本語配列の変換や無変換やカタカナがない分、無駄がなくてスッキリしている。プログラミングで多用するスペースキーがとても広く取られているので、安心感がある。変換と無変換はまだ活用できる。しかし、カタカナキーは無理がある。PCを使い始めてから一度も活用したことがない。CapsLockが重要な位置に置かれているの同じくらい不自然なキーだ。使いみちがないので無視すればいいという考え方もできる。しかし、やはり美的感覚から受け付けがたい。各キーについているひらがなの刻印も無意味な感じがする。かな入力は使ったことないし、将来も使う可能性は極めて低い。何度か言っているけど、@のような使用頻度の低いキーがホームポジションに近い位置にあるのも微妙だ。そして、プログラミングで多用する二重引用符が変わりに@が適正だと思われる位置に押しやられている。美的感覚からも、機能性の面からも、US配列のほうがずっと優れていると思われる。日本語配列を選択する理由となるのは、ただ入手しやすいことと、今ストックがたくさんあることのみで、キーボード本体の設計が理由となるものではない。

 なぜ今こんなにキーボードについて悩まないといけないかと言うと、おそらく、今回下した判断によって、今後数年、下手したら数十年の間ずっとそれを維持し続けることになるだろうからだ。先に書いたように、キーボードそのもののどちらが優れているかよりも、統一して使い続けることのほうがずっと重要だ。統一されているという前提があって初めて、どちらがいいかを選ぶことができる。統一されていればどちらでもいいというわけではない。プログラミングと同様に、悪いスタイルを強制されるのは苦痛なものだ。はじめから苦痛なキーボードを選択する理由はない。

 別に日本語配列が苦痛なだと思っているわけではない。今までもそんなふうに思ったことはなかった。しかし、ここしばらくUS配列を使ってきて、少し考えが変わってきた。1ヶ月程度ではまだ試用段階だったと考えても良い。決断を下せるほど使い込んだとは言い切れないところがある。それを踏まえて、現時点では、先に述べたように、見た目と機能の両方に置いてUS配列のほうが優れていると思っている。ここで、すべてのPCに対して統一するために、今所持しているキーボードに引退してもらって、新たにすべてに対してUS配列を用意するほどまでの優位性があるかどうかを判断しないといけない。

 どうも話がループしている気がする。先に進むことを考えよう。

 今使用しているUS配列のゲーミングキーボードはなかなか気に入っている。これを手放すのはちょっと惜しい。そして、旧PCに接続してある、ちょっと効果な日本語配列のキーボードも、打ち心地の良さから気に入っている。どちらか一方を選べと言われるとちょっと難しい問題だ。しかし、どうにかしてどちらかを除去しないといけない。もし、ひょんなことから新しくUS配列のキーボードを入手していなかったら、こんなに悩むことはなかっただろう。一旦、元の平和な状態に戻してみてはどうだろう。しばらくUS配列ばかりでやってきていたので、日本語配列でプログラミングする感覚を忘れかけている。旧PCで作業するとにタイプミスを連発する原因はそれしかない。一旦戻して、それでもまだやっぱりUS配列のほうが良かったと思えるようなら、US配列で統一する。別に日本語配列でも問題なければ日本語配列で統一するということにしよう。

 10日ぶりにブログを書いている。出だしはなかなか良かったのだけど、やはり続けるのは大変だ。それでもやっていこと思う。厳密でなくてもいいので、できるだけ1日1つを維持したい。今月はもう無理だけど、今日から連投することで数だけ稼いで帳尻を合わせたい。今日時点で12本欠落しているので、今月はあと5日として、30、31日はおそらく使えないので、残り3日で、およそ17本投稿しないといけない。1日に5、6本になる。可能だろうか。かなり大変な仕事に思える。何しろ文字数が多い。今4Kのモニターで表示していて、大体これで、編集画面で上から下まで埋めることを目安としている。どうやら3000文字くらいになるようだ。それが6本なので18000文字必要になる。コードにしたら、1行40文字くらいとして、450行くらい。コードと文章ではまったく質が異なるので、あまり意味はないが、雰囲気はそんな感じになる。不可能ではないような量だ。ただ、こればっかりやっているわけにもいかない。1本30分で、3時間程度で終わらせられたらいいなと思う。ちょっと厳しいか。

 今困っているのは、ネタがないということだ。そんなはずはないのだけど、思いついたやつを下書きにキープしていって、まだ10本程度しかない。もういっそなんでもいい。コーヒーの話とか、ダイエットの話とか、禁煙の話でもいいんではないだろうか。とにかく数を稼ぎたい。

 数を稼ぐというと、プログラムをコードの行数で見積もって水増ししているようで、悪い習慣なのだろうか。そんなことはないだろう。さっきも書いたけど、文章とコードは全く質が異なる。無駄に長いコードは悪質だ。短すぎてもいけないが、十分に読みやすく保守しやすいコードである以上の冗長さは取り除くべきだ。文章の場合そうとも言えない。すべての文章は何かしら文学的な性質を持っている。情報が単に表示されているだけでは良い文章ではない。読み手に伝達したいという意図があるから存在しているのであって、そのためには、文章を工夫して、強調したり、繰り返したりしないといけないことがある。物書きになりたいとは全く思っていないし、このブログでは完成された文章を書こうという目標は立てていない。

 このブログで何をやろうとしているのかというと、前にも書いた気がするけど、何を考えているのか自分でも分からない、思考を書き出すためだ。文章にして初めて自分の頭の中が見えてくるような気がする。大体、こうやって書いていることというのは、常にそういう風に考えているわけではなくて、文章を書きながら思いついたことを書いていっている。文章にすると陳腐にみえるようなことは排除していっている傾向がある。それなりに見栄えのする文章に作り変えている。それって偽物の思考じゃないのかと言うと、そんなことはないように思える。普段、何もしていないときはおそらく何も考えていない。何か活動をしているときには何かを考えているのだろうか。それも怪しい。プログラミングをしているときは多分プログラミングの範囲内でしか考えられていない。そこに落とし穴があるように思う。プログラミングは、それ自体が目的になることもあるが、本来は現実の問題を解決するためのものだ。目の前のコードに集中したり、プログラム自体に集中したりするあまり、視野が狭くなっている可能性がある。一度、距離を置いてやるべきことを見直す必要がある。頭の中だけで整理をするのは上級者向けだ。こうやって文章にしたり、なんか別のツール、マインドマップとか有名だけど、そんなんでも、何でもいいからちゃんとした形にすると良い。

 今さっきちらっと書いた、ここに書いているのは偽物の思考ではないかという疑念をもう一度考えてみる。確かに、文章にする前の段階では今ここに書いているようなことを考えたことがあるという自覚はない。ただ、思いつくままにキーボードを叩きながら出てくる文章を吐き出しているだけだ。現在進行形で文章が作られている。この文章はどこから出てきているのだろう。かろうじて言えるのは、他人によって強制的に書かされているものではないということくらいだ。本当だろうか。どこにも公開するのでもない、秘密のテキストファイルとして書いているのならともかく、ここは一応パブリックな空間で、理由はどうあれ、誰かに読まれることを想定しているはずだ。すると、読み手がどのように解釈するかということを含めて文章が生成されているところもある。とても人に言えないようなことを書いたりはしない。

 このブログの場合、何かを伝えたいという意思はほとんど含まれていない。単に人の目につくところに文章を置くことで、モチベーションを高めようと利用しているだけに過ぎない。それは過小評価しすぎかもしれない。おそらく人の目につくところに置くことで、多少はマシな文章を組み立てようという力が働くところも少なからずある。むしろ願ったりだ。文章の構成は人の読める程度にうまくできている方がいい。これは表現の違い、表面的なところでの話となる。思考そのものの出力である、文章の中身がどこから来るのかをまだ書いている本人が理解していない。だんだん、自分で書いている文章が偽物の思考なのではない、ということに自信がもてなくなってくる。誰が読んでも無難なように、本心を偽っているのではないかという気がしてくる。それは現実のコミュニケーションで人間が当たり前にやることだ。社会性を持った生物は、属するコミュニティで培った習慣に従って、さしあたりのない範囲で活動するはずだ。いきなり誰でも出会い頭にプログラミングの話をしたりはしない。こんにちはとか言うはずだ。そのような、常識とでも言って良い範囲に縛られたからと言って必ずしも偽物の思考だと結論づけることはできない。

 何か思いもよらない方向に話が流れてきた。書き始める前は全くこのような内容にしようとは思っていなかった。なぜこういう方向に話が進んだのか、なかなか興味深い。思考はどこからくるのか、など、典型的な哲学の領域ではないか。今までそんなことを考えたことはないのだが、不思議だ。こうやって文章にしていくことで、全く自覚していなかった、新たな発見があることは少し前から気づいていた。今回の場合で言うと、思考とは何かだ。本気でこのことを追求しようとはあまり思っていない。でも、せっかく気づいたことなので、気には止めておこうと思う。予め用意された入口、今回の場合は哲学になるのだろうけど、そこの戸を正面から叩くのではなく、こうやって自分で掘り下げて発掘するという行為は面白いかも知れない。

 何も期待せずに書き始めた投稿だったが、新しい、ちょっと高等な目的ができた。それは、文章化することによって、今まで気づかなかったことを採掘するということだ。ただ、これは最初から求めてはいけないようだ。書き続けていくことで自然と見つかるもので、そのときを見逃さずに捕まえられればそれでいい。

 

 少し前に、コードコンプリート 第2版 (上)を読み終えた。この本を入手したのはもう随分前になる。ずっと放置したままだった。頭の何処かに、読みたいし、読まないといけない、という意識がずっとあった。それにも関わらず、なぜずっと読まずにいたのか。初めて目を通したときの、最初のいくつかの章のとっつきにくさが原因だったように思う。プログラミングの前段階、要求やアーキテクチャから始まるのだけど、まだプログラミングを始めたばかりの頃には、それらが一体何なのかを現実のプログラミングと結びつけることができなかった。そこをスキップしてしまえば、具体的なコーディングの話が始まって、それほどソフトウェア開発の経験がなくても読み進められる内容ではある。しかし、最初に躓いてしまって、読む気が失せたと言うか、まだ読めるだけの経験値が溜まっていないと判断して後回し後回しになってしまっていた。

 これまでこの本を読まずにいたことでどれだけの損失を出していたかを考えてみよう。読まなかったからといって、コードが全く書けなくなるわけではない。逆に、読んだだけですぐに効果が発揮されて、優れたコードが書けるようになることもない。そう考えると、読んでも読まなくても対して違いがないのではないかと捉えられなくもない。

 仮に、今まだプログラミングを初めて1週間目くらいで、何かの言語を使って簡単なプログラムが書けるような状態になったところとしてみる。さらに、能力的には平均にしておいて、なぜかこの本の内容を理解して吸収できるだけの驚異的な適正があったとしてみる。この架空のプログラマーがこの本を読んだときと読まなかったときで、どれだけコードを書く能力に差が出るかを比較してみる。

 まず、読んだ場合を検討してみる。まだ1週間目なので、ようやくifの使い方が身についてきたというところだろう。そして、ifを書くときに、どうやったら良い条件を作ることができるかというところにも意識が向いてくる頃だ。その状態でこの本を読んだところ、ifの条件をうまく作るための指針が書かれていて、その優れた理解力によって、なるほど、こうすればいいのかと知ることになる。さっそく実践に移そうとするだろう。しかし、まだプログラミング始めて1週間であるという縛りは有効だ。頭の中ではこうしたらいいと分かっていても、身体がまだ作れていない。単純に言うと、経験値が不足している。これからifを書くときには、この本の指針を思い出しながら、注意を払ってコードディングしてくことになる。それを繰り返していくうちに、意識せずとも自然と良いifが書けるようになってくる。

 次に、読まなかった場合を検討してみる。実験台になる架空のプログラマーは、先と同一の条件を備えた人物だとしよう。ifを書くときに、ややこしい条件を扱わなければいけない状況に遭遇したとする。先と同じ能力を備えていると仮定しているので、やはりどうやれば良い条件が作れるかに思いを巡らすことになる。しかし、指針が全く無いので、自分でなんとかならないかを試行錯誤することになる。その結果出来上がるコードは、この本に書かれているような優れたコードの性質を満たしていないかも知れない。最も優れたコードでないことは自分自身がよく理解している。だが、何とかして動作するようにしないといけないので、現状でできる最も良いやり方で妥協して先に進んでいく。その後も、何度もifを使うことになるので、その都度同じように試行錯誤しながら良い条件にならないかを模索していくことになる。そのうちに、自覚はできないかも知れないが、なかなか良いifが書けるようになってくる。

 前者は、先に目標を設定することができ、そこに向かって訓練していくというスタイルになっている。後者は、その場その場で目標を更新しながら、徐々に鍛え上げていくというスタイルになる。前者の優位なところは、最終的な目標に到達するまでの時間を短縮できるかも知れないという点だ。ダイエットをする場合に、最終的な目標体重を定めて、そこに向かって食事や運動を調整するほうが、効果が現れやすい。それは、レールが敷かれているからそこに従っていけばいいと言うだけではなく、目標を立てたのだから、達成できるように努力をするように意識が当たらくという精神論の効果もある。また、目標があると安心感が得られる。どこまで体重を減らせばいいのかわからないよりも、理想的な体重が分かっていた方が圧倒的に安心できるだろう。後者の優位な点と不利な点は、前者のちょうど反対だ。時間はかかるかも知れない、安心できないかも知れない。しかし、試行錯誤の中から自分で見つけ出したものを目標と定めて、それを繰り返していくことで、違った性質の経験値を得ることができる。単純な筋トレのようなトレーニングとは違った、発見的な経験、想像力を養うプロセスから、独特な能力を得ることができるかもしれない。

 もともとの問に戻ってみる。果たして、後者のプログラマーはこの本を読まなかったことで、より大きな損失があったと言うことができるだろうか。 まず、1週間目という仮定に現実味がない。1年目に読むとして、10年後の違いを考えてみよう。10年間読まずにいたプログラマーは、1年目に読んだプログラマーよりも損失はあっただろうか。全く同一の人物で、同じくらい量のトレーニングを行ってきたとするとき、10年目の違いはどこに現れるか。まず考えられるのは、読んだ方は、その後の反復トレーニングによって、目標の能力を完全に獲得しているという状況だ。読まなかった方は、目標そのものが絶えず変化していくので、安定した能力を獲得できていないかもしれない。しかし、目標を自ら変化させていくというまた違った能力が鍛えられていくことになる。時間的なところに目を向けると、読んだ方は、10年も書けずとも目標に到達してしまう可能性もあるだろう。その場合、また新たな目標を立てて、より高いところに進んでいくこともできる。もし損失があったとしたらそこではないだろうか。つまり、この本を入手した時点で読んでいれば、もっと早く良いコードの書き方の目標が定まっていて、そこに到達していたかも知れない。そして、もっと関心のある現実の問題を解決するソフトウェアを書くことに専念できたかも知れない。

 今回、この本を読んでみて思ったのは、それほどまでに新たな発見のようなものが得られたのではなく、これまでの経験と照らし合わせると、とんでもなく道を逸れて、変なところに来てしまったわけではないということだ。そして、ようやく入門者から一歩先に進んで初心者の手前くらいまでは来たかも知れないと、何か達成感のようなものを感じている。もし、1年目に読んでいたら、このような感傷的な感想は抱かなかったに違いない。そして、誰かに与えられた助言ではなく、自身の経験から獲得してきたことであるという事実は、なかなか貴重であるかも知れない。この本を読む一番の理由はそれじゃないだろうか。何か新しいことを身につけたり、いきなり優れたコードが書けるようになることを期待するのではなく、自分がどの方向に向かっているのか、今どのくらいの経験値溜まっているのかを確認するために読むことで、より先に奨めるようになる。

 しかし、まだ上巻なので、あと半分のこってるのに結論を出してしまうのはちょっと早い。でも、たぶんそんなに違った感想は持たないだろうとは思う。

 コードコンプリートを読んでいる。そのサブタイトルが「完璧なプログラミングを目指して」なので、完璧なプログラミングとは何かを考えてみる。何かを目指すにしても、その何かが何なのか分からないのでは目指しようがない。

 プログラミングとはソフトウェアを対象とした領域の活動と考えられることが多い。だいたいプログラミングを仕事としていると言ったら、コンピューター装置の前に座って、コーヒーとキーボードを携えて不可思議な文章を打ち込んでいたりする姿が想像させられることが多い。こうした典型的なイメージのプログラマが扱う領域は、ほぼソフトウェアに限定される。せいぜいハードウェアとのインターフェイスまでだったり、ハードウェアを制御するためのソフトウェアだったりして、直接ハードウェアを製造するものではない。それどころか、現代の最上位のレイヤーで作業するプログラミングは、一切ハードウェアに感知することがなかったりする。厳密には、コンピューターに命令を出していたり、ディスプレイモニターに表示させる画面イメージを制御しているという意味でハードウェアに接しているということができるので、完全に切り離されているというわけではない。しかし、コンピューターやディスプレイモニターの電気的な特性を考慮しながらWebサイトやスマホアプリをプログラミングすることは稀だろう。

 このように、ハードウェアから切り離して、ソフトウェアの領域だけでプログラミングをできるようになっていることは、 抽象化によってもたらされている。現代の複雑なソフトウェアが成り立っているのは、ハードウェアを直接扱わずに、その上に多段に構築されたレイヤーの上で、問題の領域だけを扱えるようになっているところが大きい。もし、今でも直接マシン命令しか扱うことでしかプログラミングができなかったら、現代社会を支えるの多くのソフトウェア基盤はもっと貧弱なものだっただろう。マシン語でプログラミングをするのは開発効率が悪すぎて、複雑な問題を扱うソフトウェアを構築するには時間がかかりすぎる。現実の複雑な問題を解決するだけの複雑さをもったソフトウェアを構築すること自体が困難だったりしただろう。 

 そういうわけで、今の時代、プログラミングとは主にソフトウェアの領域だけの活動を指して言うことが多い。しかし、ハードウェアだけでもプログラミングを行うことは可能だ。スイッチをたくさん取り付けた回路を組んで、手動でそのスイッチのONとOFFを切り替えることで、ソフトウェアなしでも機械の動作を制御することができる。現実に、天井についているライトや、電気スタンドなんかは物理的なスイッチで動作する、ハードウェアだけで構築されたプログラムのようなものと見ることもできる。他には針時計、レコードプレイヤー、エレキギターなどもプログラムのようなものだ。電気的な動力をしようしないものある。楽器はすべて自然界の音に関する性質を利用した一種のプログラムだ。ここまで解釈を広げると、あらゆるものがプログラムに見えてくる。机、椅子は、人間の体型に合わせてプログラムされている。衣類とそれをしまうクローゼット、靴と靴べら、食器と箸、 鉛筆と消しゴム、などだ。別にペアであることを強調したいわけではなくたまたま思いついたから書いただけだ。これらは、現実の問題を解決するために生み出されたという点で、ソフトウェアのプログラムと共通している。そして、人工的に生み出されたものであるという点も共通している。異論は当然あるだろうが、これらをすべてプログラミングによって生み出されたものとし、そして、その活動をプログラミングとしてみなすなら、人工的に自然界に手を加えて、本来の姿形に何らかの別の法則を適用して便利なものを生み出す行為をプログラミングと呼べる。 

 では、プログラミングは人工的な操作を行うものかというと、まだ解釈を広げることができる。 まずは生命だ。生命はコンピューターよりも遥かに高度なハードウェアとソフトウェアを備えている。生体をハードウェアに見立てるなら、遺伝子はソフトウェアといっていい。遺伝子は人工的にプログラムされたものでは、通常はない。しかし、何らかの法則にしたがって、生命単体から子孫を通してその種の生存を制御しようとしている。生命を持たないものでも、プログラムのようなものがある。気象、地形などは、何らかの要因があって、雨が降っているとか、川が流れているというような現象を観測できる。他には、空は青い、東から日がのぼり、西に沈む、夜には月が出る。これらにはすべてなぜそうなっているのかという理由があり、従っている法則がある。これらの法則をプログラムとみなすことにしてみよう。そうしたプログラムを開発することがプログラミングだとすると、プログラミングによって宇宙を創造することができる。こういう存在を神とか創造主とかいったりする。

 ここでようやく完璧なプログラミングとは何か、という問に戻ると、それは究極的には完璧な世界を作るということになる。しかし、そんなことは全く現実味がないし、不可能でもある。そこで、シミュレーションという現実的な選択を取ることができる。世界を完璧にしようなどというだいそれた考えを抱かなくても、自分の好きな形に世界をシミュレーションすることで代わりができる。世界のシミュレーションはコンピューターゲームで実現できる。現実世界と全く同一のゲームというのは、やはり実現不可能という意味で現実味がないのと、面白くもない。逆に、現実で不可能なことを可能とする世界の方が面白い。大部分が現実に近いような仮想世界で、現実で不可能なことができるというのが望ましい。そして、今のゲームはそういう風な方向に発展してきている。これは自分の作りたいものとも一致していて、だからゲームプログラミングの修行をしているというところがある。

 結論を出すと、自分にとって完璧なプログラミングとは面白いゲームのプログラミングだ。いかにコードが優れていても、ゲームが面白くなかったら完璧とは言えない。では、面白ければどんなひどいコードでもいいのかというとそれは違う。ひどいコードのゲームは完璧ではない。完璧なゲームは完璧なコードによって生み出される。ひどい変数名をつかっていたり、ひどい関数名をつかっていたりするコードからは面白いゲームは生まれない。最終的には、読みやすく、誤りがなく、効率的で、保守しやすいコードというありきたりのところに行き着く。そのためには高い技術と豊富な知識と長い経験が必要となる。そんなのは幻想に思えるところもある。実際にどこまで到達できるかよりも、このくらい理想を掲げていないとすぐに堕落してしまう。それくらい完璧なプログラミングというのは難しい。