カテゴリー: 古いポエム

 1ヶ月とちょっとぶりに動画を撮って投稿してみた。今日は書くことがないのでそれについて書いてみることにする。以前raylibを使ってみるというテーマで30本ほど撮った。どれも1時間超えのプログラミング実況といった内容だった。何も準備なしでやる自信はなかったので、予め、一度コードを書いてから、それをもう一度実況を交えながらやり直すといったものだった。raylibの機能に焦点を当てたかったのだが、成り行きでゲームを作る方向にシフトしていった。1回やったことをもう一度繰り返すのと、確実に何をやっているかを確かめながらコーディングするということで、学習効果はそこそこ高かったのではなかったかと思う。それで目的は達成できていた。そこそこの成果が得られたと思っている。

今回はRustでゲームを作るというテーマで撮っていく。すでに3本アップロードした。前回のように、すべてを実況するのではなく、その日その日の要点だけをアップしていくというものにするつもりだった。前回のは長すぎて、密度が低すぎると反省しているからだ。今日の3本のうち、最初の1本は良かった。15分で終われた。これはいける、と思ったのだけど、2本目は30分、3本目は1時間と、結局前と同じになってしまっている。これは良くない。明日から修正していかないといけない。どうやったら短時間で必要なポイントだけ記録することができるだろう。コーディングを実況というタイプの動画だから、どうしても長くなってしまうのだろう。コーディング実況は録画でやってもあまり面白みがない。やるならライブ配信の方が面白そうだ。しかし、ライブ配信は敷居が高い。まず、誰も見てないのにライブ配信するというのがちょっとしんどい。これまでの録画してきてアップロードしたものは、再生回数を稼ごうなどという気はまるっきりなかった。そのはずだったのだけど、あまりに再生されなさすぎなので、残念な気持ちがまったくないと言ったら嘘になる。自分でページを開いてしまうとカウントされてしまうので開かないようにしていたので正確な数がわかる。1本につき大体5回といったところだろう。再生時間は1分未満がほとんどだ。本音をいうと、100回とは言わないが、30回はほしいところだ。

不本意ではあるが、なぜ再生されないのかを考えてみよう。喋りが良くない、声が良くない、内容よくないといったところだろう。一言でいうとつまらないからだ。アイコンがデフォルトのままだしチャンネルページの見栄えも良くないし、タイトルや説明に情報が少なすぎて検索にもかからないだろう。不運にも動画を開いてしまった人はこいつは一体何がしたいのだろうと不審に思うに違いない。何をしたいか、自分でもよく分かっていない。動画として残すことで、そのために行ったプログラミングを定着させる効果が見込めると思っていたのだが、だんだん動画を完成させることの方に意識が持っていかれる。確かに多少の効果はあるだろう。しかし、もっとも良い手段とはかけ離れている。もっとも良い手段とは何だろう。現実のプログラムを書くことだ。ゲームを作ることがゲームプログラミングの能力を向上させる最高のプロセスではなかろうか。その過程を取り繕ったように動画に仕立て上げることに本当に価値はあるのか、疑問だ。前回のraylibの動画から得られた教訓は、そのようなことに時間をかけるくらいなら、さっさとゲームを作れ、技術をみにつけろ、ということだ。今回も同じようなことをやっていたら、まるで成長していないということになる。今日やってみてそれに気づけたことだけでも良かった。

実をいうとさっきまで、この投稿を書くまではそうは思っていなかった。これからしばらく、Rustが使えるようになるまで、同じようなサイクルでこつこつアップロードしていこうと考えていた。たった今、こうやって振り返ってみることで、それに気づけた。このブログは特に目的もなく始めたのだけど、かなり自省を促す効果があるようだ。 これは続ける価値がある。YouTubeはどうだろう。何か得るものがあるだろうか。さっきも書いたけど、その日行ったコーディングを繰り返すことによって、プログラミングを定着させるという効果は見込めるものの、もっと良い手段は他にもある。ゲームプログラミングができるようになりたいならゲームを作るのが一番良い。今日の動画をアップロードするまでに準備なども含めて費やした時間は、おおざっぱに5時間くらいではないかと思う。この間に何ができただろう。これからもこのように時間をかけていていいものだろうか。

だんだんと動画を投稿し続けることが否定的な方向に向いてきた。学習効果だけを期待すると、良いものとは言えないことが明らかになってきた。しかし、それだけが理由でやってきたわけではなかった。動画を取り終えてアップロードしたときの、やってやった感、達成感はなかなかのものだ。数時間の作業の見返りとして得られる達成感は中毒性がある。それにもし再生回数までついてきたらもうどハマリしてしまうだろう。もしかしてドハマりする前に気づけてよかったのかもしれない。もうちょっと冷静になってやるべきだ。動画を投稿するのは楽しいだろうかと言われると、そこそこ楽しいと思える。それは良いことだ。過酷なトレーニングの合間の僅かな楽しみとして、ちょっと趣味としてやるだけなら、悪くない。ただ、全力で、半日や1日かけてやるようなことではない。ゲームの完成を動画の投稿と同一にしてしまうべきではない。もし続けるならもう一度やり方を見直す必要がある。

完全にやめてしまうのはちょっと惜しい。せっかく見つけた密かな楽しみなので、も少しやってみたい。理想は、1日30分くらいの時間を確保して、その時間内にすべての作業を完了させることだ。30分ではその日の成果をリプレイすることは不可能だろう。また、そんなものの需要は皆無であることはもう前回のシリーズで身を持って知っている。動画の長さは重要で、10分程度でないといけない。その時間では実況コーディングは不可能なので、もうやらない。その日作ったゲームのコードに解説を加えて再考するというのはどうだろう。これなら10分程度で終わるのではないだろうか。振り返ってみることで定着を測るという目的にもあっているように思える。悪くない、しばらくこの方針でやってみよう。ライブ配信はどうだろう。今はやる価値がなさそうだ。もう少しうまく喋れるようになってからのほうがいいように思える。練習としてやるのはありだけど、それ以外の成果は期待しないほうがいい。まずRustがまだ全然馴染んでいないこの状態でやるのは、無謀に思える。ということでなしだ。学習過程をオープンにするというのは新鮮で試してみたい気もする。しかし、中毒性が高そうで、前と同じ罠にハマってしまいそうだ。危険なのでやめておこう。

だいたい方針が決まったので満足した。

 Rustで少し書いてみた。やったことは、SFMLを使ったゲームプログラミングの本を読みながら、C++で書かれたコードをRustで書き直すといったことだ。まだRustでどのように書けばいいのかわからなかったので、何かしらガイドになるものが欲しかった。題材はゲームがいいだろうというのと、SFMLのRustのバインディングが公開されている、SFMLの本を選んだ。オリジナルのSFMLのAPIとは異なるところが多々あって、思うようには書けない。それはまだ想定内なので何も問題ではない。懸念しているのは、C++のコードをそのままRustに書き直すということで、間違ったRustの使い方をしてしまうのではないかということだ。読んでいる本は、C++のクラスをベースとした設計、要はオブジェクト指向のような設計になっている。継承を多用していないのであれば、データ型とメソッドでそのまんま書き直すことができる。それが問題に思える。まだ、Rustらしいといえばいいのだろうか、よいRustのコーディングスタイルを身につけていないので、こういうときはこう書くべきだというのが何もない。何もないからこそ、下敷きになるものが欲しくてC++のコードが手に入るSFMLを選んだのだけど、もしかしたら逆効果なのではないかという気がしてきた。SFMLのRustバインディングを使うことは、それほど悪い選択肢ではない。問題なのは、C++をそのまんま書き直すということでRustを身につけようとしていることだ。今はまだまっさらの白紙に色を塗るような、あるいは吸収力の高いスポンジのような状態であって、今からインストールする習慣は何の抵抗もなく受け入れてしまうことだろう。良い方向で考えれば、高効率で身につけることができる。悪い方向で考えれば、良いか悪いか判断ができず、間違った習慣までもすんなりと受け入れてしまう。また、間違った習慣のためを記憶してくために、空間を無駄に消費してしまう。

 プログラミングの学習は、反復と修正を繰り返すプロセスだ。かならずしも良い方法、グッドパーツだけを回収することだけで上達するものではない。間違った方法を経由することもあり、しばらくしてから間違っていることを認識して、これは間違いだったと身体と頭に刻むことで、同じ間違いを繰り返さないようになっていく。実験的なプロセスとも言える。だから、一度に正しい方法だけを選択するよりも、失敗も数多く経験することによって学習を繰り返しながら身につけていくのも有効な手段だと言える。通常はそうだ。しかし、今はちょっと状況が違う。

刷り込みというのがある。今はまだ卵から孵ったひな鳥のような状態だ。この状態で見たり触れたりしたものは、たとえ姿かたちがまったく違っていたとしても、同じ巣にいる親鳥を親として認識してしまう。これはもしかしたら危険かもしれない。SFMLを選択したのは、本があるからといのもあるが、もう一つはC++で慣れているからというのがある。まずRustそのものになれるために、練習として何も考えず書き直すということで、文法を身につけようという算段だ。文法だけを身につけることができるのならば、これは悪くないように思える。しかし、余計なものまでついてくる。C++でこう書くところはRustでこう書けばよいのか、という情報だ。これはC++とRustの公約数だけを使ってプログラミングすることを意味する。今は孵ったばかりのよちよち歩きの状態で、この状態でそのようなプログラミングをやり方を覚えてしまうと、まさに刷り込みの効果により、これからもそういうやり方から離れられなくなってしまう可能性がある。修正が難しくなってしまう。SFMLの資産を有効活用できないのは残念だが、諦めたほうがいい。初期投資をけちって、大きな機会を損失出してしまうことになりかねない。

SFMLを使うことに問題があるわけではない。SFMLのRustバインディングは、たぶんRustのイディオムに適合するように書き直されているだろうから、姿かたちのまったくことなる親に対する刷り込みが起こるということにはならないかもしれない。それでも、C++が頭にあるので、それを振り払うのを意識を持っていかれる点は無視できない。もしかしたら、それはまだ許容できるかもしれない。一番まずいのは、C++で書かれた本をRustに書き直すという学習方法だ。Rustの何の経験もない状態でこれを行ったら、確実に刷り込みが起こる。非常に残念だが、今回はこの方法は諦めざるを得ない。もう少し経験を積んで、良いか悪いかの判断くらいできるようになってからにした方がいい。

 今日はそういうことをやっていたのだけど、早い段階で気づけたのはラッキーだった。最初良さそうに見えた方法が、実はあまり良くなかったというのはプログラミングではよくあることだ。学習方法にも同じことが言える。もっというと、何かしらの方法を選択しなければいけないという状況においては、分野を問わず似たようなことが発生するのかもしれない。なので一度立ち止まって、本当にこの方法は正しいのだろうかと自問してみることは大切かもしれない。急がば回れ、とはこういうときに使うのかと学んだ。

それで、どうやってRustを身につけるかをもう一度考えてみよう。ベストはRustを使ったゲームの本があると良い。Packtのライブラリを見ると、一応あるにはある。ただ、それはWebAssemblyとタイトルがついている。これはちょっと手に負えない感じがする。難しいとかじゃなくて、むしろ、WebAssemblyはやりたいくらいなのだが、まだRustがままならないうちにWebAssemblyに手を出すのは時期尚早ということだ。一度小規模なプロジェクトを経由してから手を付けるのがいいだろう。それ以外にはゲームの本は見当たらない。ここは本かゲームかどちらかを諦めよう。二兎を追う者は一兎をも得ずという警句もある。本を選択する場合、言語解説中心のものは今は良いだろう。オライリーのを読み終えたばかりなので、まずはこれを血肉にするために、リファレンスとしてオライリーのを活用しながら、プログラムを書くのが良い。白紙状態からプログラムを書くというのは流石に効率が悪いので、プロジェクトベースで解説を行う本があると良い。Packtのライブラリに2冊ほど良さそうなのがあるので、それが選択できる。ゲームを選択する場合の方法は、Rust純正のゲーム用ライブラリを使って、その環境の中でゲームを作るというものだ。ライブラリはいくつか選択肢がある。そのライブラリの利用方法を学びながら、Rustのプログラミングスタイルを定着させようという狙いだ。まだ二兎を追っているような気がしないでもないが、大丈夫だろう。ゲーム専用のフレームワークでなくても良い。汎用的なGUIライブラリであれば、シンプルなパズルゲームなどは作ることができる。

大体今後の方針が固まってきた。本をベースにプログラムを書くのと、Rust純正のライブラリを利用してゲームを書くのどちらかだ。同時進行は可能だが、一緒くたんにしてはいけない、別々に進める必要がある。

 今後Rustに移行するにあたって、オブジェクト指向プログラミングの世界からどうやって離脱するかを考えておきたい。Rustはオブジェクト指向を採用していない。これは良い知らせだ。オブジェクト指向にはずっと馴染めないでいた。C++では、それが可能だからという理由でお付き合いをしていただけで、可能ならもっとシンプルな方法を取りたかった。C++にとってオブジェクト指向は重要な要素であり、また有用であることを否定することはできない。現実の問題を解決するときに、特に設計段階においては、強力なツールとなる。プログラミングを始めたばかりの頃は、これが唯一のC++の使い方だと思いこんでいて、必死になってその技法を身につけようとしていた。それを今でもずっと引きずっている。C++は別のプログラミング方法もサポートしている。現に標準ライブラリはオブジェクト指向をベースにしたものになっていない。オブジェクト指向は自分に合わないというのは割と早い段階で気づいていた。だから、バッサリと手を切ってしまって、別のプログラミングスタイルを身につけることにしても良かった。だけど、それはできなかった。C++がオブジェクト指向を全面的にサポートしている以上、何を書くにしても常につきまとう。何を書くにしても、例えばHello Worldを書くだけにしても、常に頭の片隅にはオブジェクト指向がある。これはもう強迫観念と言っても良い。もう10年くらい前になるだろうか、突然、少なくとも自分には突然に思えたのだが、関数型言語が注目浴びるようになった。このときは嬉しかった。もしかしたらオブジェクト指向をもうやらなくてもいいのかもしれない、と思った。今そのようなキャンペーンは終了したのか、さほど関数型言語が取り上げられることは少なくなってきたように思える。自分の中でも落ち着いてきた。しかし、今でもやはりHaskellのような言語を使えるようになりたいという思いは消えていないし、今も学習を継続している。本当は、関数型言語は突然現れたのではない。昔からずっとあったものだ。ただ、視界が狭かったから見えてなかっただけだった。もし、最初にオブジェクト指向に疑念を抱いたときに関数型言語が目に入っていたら、その時点で乗り換えることができていたかもしれない。そう話は単純でないかもしれない。C++をどうしてもやらなければいけない理由があった。ゲーム開発で利用される言語だったからということを真に受けて、それしか選択肢がないと思っていた。もし、ゲーム開発でもっとも利用される言語がHaskellだという情報があったら、とっくにHaskellに乗り換えていたことだろう。

 これは10年以上前の話だ。現代では、まだ圧倒的な優位にあるのは変わりないが、ゲームプログラミングならC++一択だというほどではなくなってきている。それでもC++を使い続けている理由の一つに、言語に対する執着や愛着というものがある。一方でオブジェクト指向に対する嫌悪感もある。その相反する感情が入り混じって、どうにもすっきりしない状態がずっと続いていた。C++ではオブジェクト指向を採用しなくてもいいという逃げ道がある。そこへ逃げればよかったのだけど、それもできなかった。オブジェクト指向を採用しないプログラミング技法についてのガイドラインがイマイチ不明であったため、なかなかものにできなかったからだ。簡単な方法がある以上、そちらの方へ流されてしまうのは仕方がないことだ。C++を使うけどオブジェクト指向は絶対採用しないという強い意思がないと、STLのような素晴らしいライブラリを発明するのは無理だろう。普通の人間にはなかなかできないことだ。良いガイドラインがないといったけど、Boostライブラリのような優れたライブラリのドキュメントは結構あるものだ。ただ、オブジェクト指向を採用しないアプリケーション開発についてのものはそんなに見つからない。ゲームプログラミングにおいては、書籍とかだとまず何かしらオブジェクト指向的な手法を使っている。そういったものをすべて無視して、独自の技法を編み出してやらないといけないというのは、自分の熟練度じゃちょっと厳しい。もしかしたら、そこを模索して考えだすのが楽しいのかもしれない。今から始めてもいいけど、今までやらなかったのだからこれからもやらない可能性がある。いや、きっとやらない。

 オブジェクト指向をやりたくないからC++をやめるというのは、極端な選択だ。それだけが理由ではないが、もしRustがオブジェクト指向を中心に据えた言語だったら、たぶんそれほど魅力を感じなかったのは間違いない。Rustがオブジェクト指向を完全に排除しているわけでもないように思える。先日、GTKのRustバインディングであるgtk-rsをいうのを触ってみたのだけど、それはオブジェクト指向をベースとしている。GTKはGObjectをベースにしたちょっと特殊なライブラリであるので、参考にはならないかもしれない。しかし、可能だということだ。ただ、これは、Cでオブジェクト指向が可能といっているのとさほど違いはなく、Cを使うときにオブジェクト指向を意識するかというと、通常はしない。それと同じことで、Rustを使うときにオブジェクト指向を意識するかというと、たぶんしなくて良いと踏んでいる。C++を使うときオブジェクト指向を意識するかというと、おそらく悟りでも開かなければ、どうしてもしてしまう。Rustも、データに関連付けられたメソッドを中心に何かを行うというのはあまり変わっていない。さらに、継承、多態、カプセル化といった要素も含まれているように思える。しかし、従来のオブジェクト指向とは随分異なっているように見える。何より、Rust自身がオブジェクト指向言語だと公言していないので、きっとそうなのだろう。

 オブジェクト指向から離脱したあとに何が残るか、まだ分からない。関数型言語であれば、きっと関数型言語のプログラミングスタイルを身につけることに没頭すれば良くて、分かりやすい。Rustの場合はどこへ向かえばいいのかまだ良くわかっていない。登場して10年と少しといったところで、最近急激に成長した言語で、ユーザー数も多く、そこそこのノウハウが蓄積されているだろうから、まずはそういったところを吸収していくのが良さそうだ。プログラミングスタイルを身につけるのはいいとして、もう一つ重要なのが、設計手法だ。オブジェクト指向による設計を諦めるということは、何かしら別の方法をまた身につけないといけないということになる。問題をクラスに分割して、サブルーチンに分割して、といった手法があまり通用しなくなるのではないか。もっとも、設計についてちゃんとした訓練をしてきたわけでもないので、それほど失うものはない。これからまたリフレッシュしてやっていけばいいだけだ。

 「プログラミングRust 第2版」を読み終えた。これでRustを使い始める準備はできた。スタート地点には立てたのではないだろうか。記憶は風化していくものなので、ここで満足せずに継続的にプログラムを書いていくことが求められる。どんなプログラムを書いていくのがいいのだろうか。Rustはシステムプログラミングの分野でCとC++を置き換えることを考えられて作られた言語だ。なので、システムプログラミングをやることがRustを知るには最も良い方法となるのだろう。最近の動向では、システムプログラミングとは呼べないような色んな分野で活用されているようだ。例えば、WebAssemblyやマイクロサービスによるWebアプリケーションとかでの活用だ。他にも、GTKは公式のバインディングが提供されていたりして、デスクトップアプリケーションでの活用も、実際にどれだけ利用されているのかは置いておいて、進んできている。ゲームもそうだ。「プログラミングRust」では、システムプログラミングとは何かというのが書かれていて、その中にゲームも含められている。ゲームは比較的速度が求められる。おそらく、どんなゲームというわけでもないだろう。ここで想定されているのは、最新のグラフィックスハードウェアの性能を限界ギリギリまで引き出そうとするような、一部のトップタイトルのことを指しているのだと思う。1日で書けるようなクラシックでシンプルなゲームをシステムプログラミングと呼ぶことはないのではないかと思う。今作りたいのはそういうシンプルな練習用のゲームだ。そういうゲームにRustの安全性は過剰だし、効率性はオーバースペックなように思える。本当にRustが必要とされるのは、やはりシステムプログラミングなのだろうから、システムプログラミングを題材としてトレーニングしないとRustの真の性能を引き出すことはできないかもしれないし、良いプログラミングのスタイルは身につかないかもしれない。でも、そんなに構えて、こうあるべきだ、とかならなくてもいいかもしれない。まずはシステムプログラミングにも、そうではない、普通のプログラミングにも当てはまる、公約数の部分のプログラミングを身につけることを目標にするといいだろう。ちょっと回りくどい。わかりやすく言うと、今までやってきたことをRustに置き換えてやっていって、徐々になれていくということだ。その一環として、シンプルなゲームを作っていきたい。

新しいことにもチャレンジしたい。さっき書いたWebAssemblyは興味がある。Rustじゃないとだめなのかどうかは知らない。ただ、Rustの本でそういうのを見かけたというだけ。今の時代、ゲームの最大のプラットフォームはスマホだろうけど、次点でWebが来るのではないだろうか。ゲームの規模や特徴にもよるけど、シンプルな練習用の2DゲームにPCやPlayStationなんかは大げさ過ぎる。そういうのが存在していても、あまりプレイしたいという気にはならないだろう。プレイしてもらうことが目的ではないのでそれはそれでいいかもしれない。しかし、誰にもプレイされないゲームというのは虚しいものがある。Webはそういう心配はあまりない。つまらないゲームでもページを開くだけでプレイできるというのは、考えられる最も手軽なプレイ環境ではないだろうか。積極的に面白いゲームを探している人でなくても、何かの弾みでついそのページにたどり着いてしまうということが考えられる。経緯はなんであれ、作ったものが使ってもらえることは嬉しいもので、次のステップへの弾みになる。今の時代、よっぽど目を引くようなルックスをしていて、プレイヤーを誘致するような仕掛けがされていないと、わざわざダウンロードしてきてPCの記憶領域の一部を専有するようなインストール手順を踏んでまでしてプレイしようという気にはならないものだ。それにWindowsもMacも持っていないので、Linuxユーザー向けのゲームとなるとさらにプレイしてもらえる可能性は低くなる。スマホもインストール手順をふまないといけないし、記憶領域を必要とする点ではPCと変わりないのだけど、圧倒的にユーザーが多い。老若男女問わず、多くの人が利用しているプラットフォームだということで、インストールの面倒さを帳消しにしてくれる。でも、スマホの開発をやりたいとは全く思えない。今の所Rustでやるのは無理だろうし、そうでなくても、予め決められた環境の中で、一定の手順を踏んで組み立てているだけのような感じで、プログラミングの占める割合が低い、という先入観がある。決められた枠内でというと、Rustも制約が多く、自由な環境を重視するならRustを選択する理由にはならないのではないかということも言える。Rustは安全性のために制約を課し、スマホは便利なデバイスを利用するために制約を課すという違いは同質なものとは言えない。プログラミング言語のほぼすべてが、プログラマーに何らかの制約を課す。ifはこう書かないといけないとか、そういう取り決めがなければ、何もすることができない。CPUのレベルに至ってもそうだ。このビット列はこのように解釈するという決まりがなければ、CPUは何もすることができない。Rustによってがんじがらめにされるというのは、その延長だと言える。プログラマーの自由な精神活動を妨げるようなものではない。なんか大げさなことを書いてしまったようだけど、 ただ単にスマホにはあまり興味がないというそれだけのことだ。

スマホをやらないとすると、PCかWebAssemblyなんだけど、どっちもやればいいだろう。まず基本はPCだろう。利用できるライブラリが豊富にあるので、学習にも向いている。このプラットフォームで十分に経験値をためてから、WebAssemblyに移るのが良さそうだ。PCはLinuxのマシンしかない。なので、プレイしてもらうという考えは捨てて、レベル上げのためだけにやるということになる。競技プログラミングとかやるのとあまり違いがない。モチベーションを維持できるかどうかが問題となるだろう。何かしら外部にアピールして自己欲求を満たす仕組みを用意しないと、継続するのは難しそうだ。単純なのはGitHubのようなところでソースを公開するとか、YouTubeでライブ配信するとかそういう手段がある。そういうのはPCでもWebでやるにしても同じことなので、早めに手段を確保してしまうのがいいだろう。しかし、目的を違えてはいけない。ゲームを作ることあるいはプログラミングそのもの目的であって、それ以外は付属的なものに過ぎない。

昨日はRustに乗り換える計画について書いた。そんなに書くことないかなと思っていたのだけど、書き始めると意外と指が動いてそこそこの文量を確保することができた。もう今の段階で書けることは書き切った感がある。それでももう一度書いてみることにしてみようと思う。書き始めればなんとか文字を埋めることができるかもしれない。今、オライリーの「プログラミングRust 第2版」を読んでいて、残すところあと2章となった。今日はこの本でおそらく一番難しいところと思われる、並列性と非同期プログラミングの章をなんとか読み切った。記憶が風化しないうちにそれらのことについて書くのが良いのかもしれないけど、さすがに経験不足のため、何も書くことがない。Rustの並行処理のサポートは充実していて、並行プログラミングについて学ぶにも良いプラットフォームになっている。もし、C++で並行プログラミンの経験を十分に積んでいたら、書くことはたくさんあっただろう。何の経験もない自分でも、Rustのマルチスレッドの扱いは、言語の方向性とぴったりと合致して、自然な感じで統合されていることに感動すら覚える。そういう感覚的な、これは良いとか難しいとか感触を確かめることはできたのだが、言語化できるほどは体得できていないので書くことができない。具体的にどういうケースでマルチスレッドを採用したほうがいいとか、非同期処理にしたほうがいいとか、そういうのがない。

並行プログラミングは自分の中でボトルネックとなっている部分でもあると思っている。こいつをなんとかしないとこれ以上先に進めないのではないかとすら思っている。マルチスレッドもごく小さな範囲に閉じ込めて、他のどこにも影響が出ないようにしたような、限られた利用の仕方くらいならなんとか扱えるかもしれない。それだけできれば、現実、なんとかなってしまうようなケースがほとんどという状況にある。もしくは、並行プログラミングなど全く必要ないというケースが大半だ。これで悪循環が生まれる。並行プログラミングができない、したがって、並行プログラミングを扱う開発はできない。しかし、並行プログラミングができなくても達成可能な案件はたくさあるので、そういったものをこなしていけばいい。結果、いつまで立っても経験を積むことはできず、並行プログラミングを身につけることはできないままになる、というサイクルに陥る。この悪循環を断ち切るには、積極的に並行プログラミングを身につけるトレーニングをするしかない。

並行プログラミングのトレーニングが必要なことは分かった。では、具体的にどういうことをすれば良いのだろうか。プログラミングにおいて、わかりやすく、効果も期待できるトレーニング方法は、実際にプログラミングをすることだろう。さらに、実験的なプログラムではなく、ちゃんとした実用性のあるプログラムであればなお良い。実用性のあるプログラムというのはなかなか難しいかもしれない。そんなに大したものを考えなくても良い。他人が使って便利だと思うものでなくても、自身の日々のタスクを効率化してくれるような、小さなものをたくさん作ってみるところから始めるのがいいだろう。実用性というものの解釈を広げて、作って楽しいものとか、遊んで楽しいもの、要はゲームをつくればいい。ゲームには並列化するような要素がたくさんあるのではないだろうかと思う。これまでは、ゲームを作るときに並列化するかどうかなど検討もしなかった。そこを意識的に、どうやったらこれを並行処理させることができるだろうと、考えていくことにする。おそらく、無駄に複雑化して間違った設計になってしまうこともあるだろうけど、そうやっていかないと、最初から可能性を捨ててしまうといつまで立っても並行処理を行うかどうかの判断力もつかないし、プログラミングもできないままになる。例えば、小規模なミニゲームなんかでは、伝統的なシングルスレッドのプログラミングモデルで十分達成可能なことがほとんどだ。並行処理でなければどうしても達成できないことなどあまりないので、意識してやらないと永久に打順は回ってこない。

 そういことで、これからしばらく、おそらく来年は並行プログラミングを身につけることを目標にやっていこうと思う。言語はC++からRustに移行することを念頭に置きながらやっていくことになる。これは並行して進めていく計画なので、一種の並行処理といえなくもない。C++の標準ライブラリには並行処理のサポートが含まれている。比較対象として療法を同時にやっていくのも悪くなさそうだ。目標はRustに移行することなので、Rustを基準にしながら、C++のプログラミングも並行していく、これもまた並行処理と言えなくもない。こうしてみると、現実でも、人間の脳も並行に何かを行うができるようになっていて、割と自然に効率良くできるようになっているようにも思える。こじつけだけど。比較対象はC++に限定する必要もないだろう。現代的なプログラミング言語やそのライブラリには何らかの形で並行プログラミングをサポートするツールが提供されている。それらに広く手を出してみることでも、成果は得られそうだ。例えばGo言語にはgoroutineというのが言語に備わっている。以前Goをやっていたときは、その存在を無視していた。もうGoに対する関心は薄れてしまったのだけど、改めてそこに着目して、並行処理に特化して学んでみるのも悪くない。

 あと、並行プログラミングのアルゴリズムを学ぶ必要もありそうだ。 アルゴリズムはライブラリが提供するものとして、軽視されがちなところがあるけど、基本的なアルゴリズムを学ぶことによるコーディングスキル上昇値はかなり高い。逆に、重要だけどしばらくは学ばなくても良さそうだと思うのは、OSに近い低レイヤの部分だろう。Linuxカーネルがどうやってスレッドを管理しているかとかは、興味はもちろんあるけど、しばらくは保留しておく。言語とライブラリによって提供される、表面にまずダイブして、徐々に下に潜っていく、トップダウンのアプローチが良さそうだ。

最初は並行プログラミングについて書こうと思っていたわけはなかったのだけど、書き始めたら結構指が動いたので、今回はそのまま続けてしまった。その結果、だいたい今後の方針が固まってきた。来年は並行プログラミングの1年になるようにしよう。

昨日はなんとか文字数を稼いで、それっぽい投稿に仕上げることができた、たぶん。今日は何を書こうか良いアイデアがない。それで、今Rustの本を読んでいるのでそのことについて書こうかと思う。まだ本を読んでいるような学習中の段階で、実際に何か開発した経験があるわけでもないので、思い込みや勘違いも含まれるだろうけど、それもいいだろう。

今読んでいる本は、オライリーの「プログラミングRust 第2版」というものだ。第1版は数年前に読んでいる。その時からRustにメインでしようする言語を乗り換えることの可能性を考えていた。長いことC++を使ってきたけど、C++が完璧な言語だと思ったことなどなく、いろんな欠陥を抱えているということは認識していた。それでも、近年の標準仕様のアップグレードによって、良い方向に向かってきているようにも感じていた。仕様が膨れ上がっていって習得するのが大変になってきているという問題はこの際考えないでおこう。もし十分に学習と訓練ができて、正しいプログラミングが習得できるならば、C++は悪い選択肢ではないと思っていた。

しかし、この本ではC++、それにCが抱えている重大な欠点を明らかにしている。それはCとC++だけの問題ではなく多くの言語に当てはまることなのだろう。他の言語では問題にならなくても、CとC++だけは、現実でシステムプログラミングで使用される特別な言語であるから、そのような欠点は無視できないということだ。システムプログラミングと呼ばれる領域で開発をしたことがないので、この本を読むまでそういった視点でC++を眺めたことはなかった。この本が指摘しているCとC++の欠点は、説得力があり、納得できるものだった。それは何なのかと一言でいうと安全性ということになる。CとC++では、どうしても解決できない本質的な問題を抱えている。それを解決するためには、抜本的に言語を見直して、CとC++のシステムプログラミングに適した性質を引き継いだ上で、さらにまだどの言語でも採用されたことのないような、革新的なアプローチが必要となる。Rustはそれをやってのけている。

Rustの安全性は無償で手に入るわけではない。安全性を担保するために、厳しい制約をプログラマーに課している。 そのため、がんじがらめのルールの中で仕事をしないといけない。それって楽しいのだろうか。楽しくないかもしれない。でも、C++で書いていたときだってそれは同じことだった。奇妙なルールやあまり簡単ではないテクニックや注意を身につけるために、膨大なトレーニングを必要とする。もうかなり長いことC++を使ってきていると思っているのだけど、全く終わりが見えない。Rustのがんじがらめのルールは、C++でプログラマーが自主的に身に付けて、正しくプログラミングすることを期待していた部分を、言語の方で強制してしまうためのものとも言える。C++は、自分で自分を強制的に安全なルールに従うようにするのに対し、Rustは、言語がプログラマーを強制してしまう、という違いではなかろうか。どっちのアプローチが優れているかは分からない。少なくとも、システムプログラミングにおける安全性という面では、Rustの方に軍配が上がるように思える。

Rustは安全だというのが、C++を捨ててRustに乗り換えることを検討するようになった理由なのかというと、ちょっと違う気もする。先に、C++は一向に終わりが見えないといった。もしかしたらRustはそうではないのかもしれないという淡い期待があるからだ。プログラミングの旅には終わりはないだろうとは思う。しかし、使用する言語にすら全く終わりが見えないってどうなのだろうと考えてみたくもなる。Rustには厳しいルールがあるが、それは一度習得してしまえば、そして経験を積めば、自然とプログラミングできるようになるのではないだろうか。C++で正しいプログラミングをするために、終わりのないトレーニングで身に付けたことというのは、もしかして、Rustによって強制されるルールの範疇ではないのだろうか。Rustでは、無知あるいは不注意を原因とした、正しくないプログラミングが排除されるため、積極的に言語の終わりのないトレーニングを要求される状態から解放されるのではないだろうか。その夢のような境地立てるかどうかを試してみたい。 

 どのような、一見簡単と言われる言語であっても、何かの目的を達成しようとすると、その目的に相応の難しさというのはつきまとう。しかし、それはプログラミングで解決しようとしている問題に備わっている難しさであって、言語によるものなのかどうかというのは別問題になる。また、ある問題はこちらの言語の方が簡単で、別の問題はあちらの言語の方が簡単ということは普通にあることだろう。Rustの場合、専門はシステムプログラミングということになる。システムプログラミングに特化して設計された言語であるなら、その領域でC++より優れたパフォーマンスを発揮するというのは、ありうることだ。システムプログラミングではRustはC++より簡単ということになるのだろうか。そもそもシステムプログラミングが簡単なものではないので、簡単と表現するのは適切ではないだろうけど。

自分の場合、今、最も関心のあるのはシステムプログラミングではない。OSを作りたいとか（夢には見るけど）、クリティカルなリアルタイムのシステムを作りたいとかはない。アプリケーションのプログラミングの方をやりたい。もっというとゲームプログラミングだ。ゲームエンジンを開発したいわけでもなく、ゲームそのものをプログラミングしたい。それでもRustは良い選択肢となるのかどうか、分からない。Rustは汎用プログラミング言語としても優れているのだろうか。その辺がよく分からない。まだ決断はできてないけど、来年はおそらくRustに移行する方向で活動をしていくことになるのではないかと思っている。C++を完全に捨てるわけでもない。最新の仕様にも興味があるので追いかけたりはするだろうし、巧妙なプログラミングテクニックなんかを身につけるのも楽しいものだ。しかし、空間も時間は無限ではない。興味のあるものすべてを集めていったらいっぱいになってしまう。本当に必要なものを見極めていかないといけない。

ポエム風なブログを書くことにした。

去年は1年間日記を継続して書き続けることができた。まさか1日も空けずにできるとは思わなかった。それはそれで、また続けていくつもり。ちょうど1年経過して、今日は12月1日と区切りも良いので、新しいことを何かやってみることにする。

 題材はプログラミングにする。というか、それしか書くことがない。プログラミングのポエムになる。技術的な話題ではなく、何かしら思うことを書いていく。特に目的はない。プログラミングのことについて文章を書こうとすると、つい作業ログや備忘録のようなのものになってしまう傾向がある。今回はそういうのを意識的に避けていく。何かの活動は行うとして、それに対して感じたことなんかを書くようにしていきたい。

まずは、今年の残り12月は、毎日継続することだけを目標にしよう。かと言って、数行程度のものではなく、ある程度の文字数で埋めたい。一方で、こんなことにあまり時間をかけたくないというのもある。1日の終わり頃にさくっと書き殴るぐらいのクオリティでいい。頭に浮かんだことをとにかく文字に書き出すといった習慣を定着させてしまいたい。一度身に付けてしまえば、そんなに負担にならないだろう。まずは最初が肝心だ。そういうことを書きながらこの投稿も文字数を稼いでいる。こんな感じで進めていきたい。

とにかく文字数を稼ぐというのは良い案なのだろうか。なんかコードの行数でプログラムの規模を測るようで無意味な基準にも思える。これだけ文字を書いたのだから、それなりの文章力が身についているはずだ、ということにはならないだろう。しかし、文書を書くトレーニングを受けたことのない身としては、とにかく書くというのはそんなに悪くないことのように思える。ここでやりたいのは、情報を伝えるということではなく、この場を借りて自分が何を考えていたのか整理したい、あわよくば文章を書く能力をアップさせたいといったことだ。目的はない、といったけど、そういう下心がないわけでもない。

もうちょっと文字数を稼ぎたい。しかし、徐々に書くことがなくなってきている。こういうときはどうするのが良いのだろう。これから先もこういうことはありそうだ。ここで止まってしまうと、モニターとキーボードの前でぼーっとして、時間だけ経過してなかなか進まないという状態になる。物書きになるつもりは全くないが、生業にしている人もおそらくそういうのを乗り越えていかないのではないだろうか。ソフトウェアのドキュメントなんかは、先に書くべきことが決まっているので、良いドキュメントを書くのは大変だが、あまりこう何を書けばいいのだろうというような状態にはあまりならない。ポエムとなると、何を書いてもいいというのが逆に制約になってしまう。

ブログは何度か挑戦したことがある。どれも長くは続かなかった。今回は続くという保証もない。しかし、今回はちょっと違うことがある。こんなに無意味で長い文章を書いてはこなかったということだ。投稿を文字で埋めると、こんだけ書いたんだ、という間違った充足感を得ることができる。これは次の投稿への景気づけになるし、続けていけば段々とブログ自体に愛着も湧いてくる。ここで目的がないといったことに意味がある。目的がないので間違った方向に進んでもそれは間違いではない。ただ、結果として価値のある情報を持たいない長い文章を考えるスキルと、思い浮かんだことを即座にキーボードを通して吐き出すことのできる、条件反射的なスキルが身につく。

それって何か意味あるの、という疑問もある。狙いとしては、ここで止まってしまうのではなく、価値のある情報を文章で表現できる能力につなげていきたい。これは今書きながら思いついたことで、別にそれが目的でこのブログを始めたわけではない。ただ、こういう感じでだらだらと長い文章をかけるようになれば、真面目に、役に立つ記事を投稿したいとなったとき、自分が抱えている情報をすぐさま公開できるようになっていくのではないだろうか。それはまた別に訓練が必要になる。なんでもいいから書くというのと、余計なものを書かず、的確に文章を構成して、それなりに見栄えのするような文章にするというのは、また違った技術になるかもしれない。

結構書いたのでだいぶ満足した。ここまで無意味な投稿を続ける気はない。題材はプログラミングなので、これからはもう少し内容のあるものになるかもしれない。