プログラマーとは誰か

ちょっと書き殴りが流石に酷すぎたので後日いろいろ整えます

はじめに

「プログラムはこうして作られる プログラマの頭の中をのぞいてみよう」を読みました

プログラムはこうして作られるプログラマの頭の中をのぞいてみよう

普段はUnityでC#かいてる。業務でも。ほかの言語まともにさわったことない

ちゃんと言語の勉強したことないし、プログラムの考え方がしりたいなといってたらizmさんから教えてもらったので読み始めた。

紹介していただいてありがとうございます。

本の名前で検索をかけるといろいろ書評は出てくるが、自分の頭の整理のためにもどのような本か、かいておきたい。

全くプログラムを書いたことがないひとのために書かれたほんで、作者が作った言語を用いてテトリス(言っちゃった)のようなゲームを作ることを目標に、話が進んでいく。

まず専用の言語が特徴的だ。日本語である。

さらに、一般的なプログラミングの用語がほとんど出てこない。変数説明して、if文説明して、for文説明して、といった流れで進まない。

最終的に完成させたいあのゲームをつくためには、まず何をしなければいけないだろうか、というところからスタートし、「では次に何をすべきだろうか」といった風に流れが進んでいく。

さらに特徴的なことが、その話の進み方だ。良く言えば丁寧かもしれないが、おそらくほとんどの人が非常に長い・まどろっこしいと思うほど長いだろう。

特に少しでもプログラミングをかじっているひとなら、なんでそんなに冗長に書くのか。すぐ終わる説明では、と思うだろう。

例えば、ざっくりいうとfor文の説明にまるまる一章数十ページ使う。

しかも、話の流れであえて最初に不適切なプログラム例を提示することさえある。

ゆっくりゆっくり階段を上っている感覚を覚えた。

もともとプログラムのことが全然わかっているわけではなかったのでその階段を上るのも決して楽だったわけではない。evernoteにメモをとりながら、参考になりそうな考え方をメモしながら日々少しずつ読み進めた。

プログラムをつくるための考え方が知りたいと思っていた自分には合っていた。

以下改めて頭を整理する意味でも参考になるなと思った記述を軽く抜粋したい

・思い通りの動きにならなかったら、いま出ている結果から考える

・新しくプログラムを作ったさいはまず小さなプログラムで正しく書く。もし間違っていた場合、原因を探す手間が楽

・問いかけが大事。上手に変形する

また、本書の序盤ではいやというほどメモリをいじることになる(実用言語のメモリという概念とは少し違うかもしれない)

身の回りの人がメモリへの理解の重要さを呟いていた理由が少しわかったきがするとともに、プログラムというものの輪郭がぼんやりと見えてきた気がする。

たとえばfor文を書かずに同様の効用を持つ実装を、基本的にはメモリをいじるだけで実現する節がある。

なるほど、普段ぼんやりと書いていてるUnityC#はつまりそういうことだったのかと思った。

すこし脱線するが、本書において番地指定のメモリと名前付きメモリ(番地が自動的に指定される)を使うことになる。

UnityC#で書いているint hogeって、つまり名前付きメモリをいじっているということなのだろうか。

型を宣言したとき自動的にメモリが確保されているのだろうか。

そういえばC言語にはポインタというものがあるらしい(どうやらポインタは理解するのが難しいと風の噂で聞いたことがある)。

書いたこともないのでただの推測だが、これはつまり名前付きメモリのことではないだろうか。使うメモリの番地(アドレスと言った方が適切か)を指定しているだけなのではないだろうか。

多分本書に書いてある”考え方”を全て理解するにはまだ時間はかかるだろう。継続してコーディングしていく中で身に着けていくのだろうなとぼんやり感じている。

たぶん、これはスタートラインもスタートラインなのだろう。

先にも書いたがUnityC#以外まともに書いたことがないので実際のCPUやメモリの挙動といったレイヤーの話は全然分かっていない。

まだまだ知らないことがあまりにも多い。これからの道程を思うと眩暈がする。

ようやく最後の章も読み終わりそうだった。

「終わりに、そして感謝」と書いてあった。

かなりヘビーな本だったがようやく読み終わる、よかったよかったと軽い気持ちで読み始めた。

しかし、なんだかハッとする内容だった。

というか、これを読んだからいま記事を書こうという気になっている。

以下、軽く引用したい。

　プログラム作りが特殊な技術とみなされている状況を、私はずっと理不尽だと思っていた。

　読み書きは当たり前だが、そうでない時代もあったし、今でもそうでない国がある。三次方程式を解ける人は万単位でいるが、何百年か前には門外不出の秘伝だったという。

　プログラム作りも、そういうもになってしまえばいい。まともなプログラムを書ける人間が掃いて捨てるほどいて、何の自慢にもならないような世界になればいい。なぜそうならなかったのかと、ずっと思ってきた。

(中略)

　プログラムに向ていない人と向いている人の間には大きな違いがある。

記憶力がいいとか、頭が回るとか、算数ができるとか、そういう単純な話ではない。考え方の違いであり、世界の見方の違いだ。優劣というよりは性格、あるいは個性の問題である。「向いた人は勝手にできるようになるし、向いていない人にはいくら教えても無駄」という意見は良く聞くが、性格の問題と考えればそれも納得できる。

　しかし、それで済ませていいのだろうか？何か手はないのだろうか？

　ずっとそう思っていた。しかし、私の仕事は教育ではない。ゲーム作りである。何もしないまま時が過ぎた。

　そうしてしばらく経った2010年、九州大学の牛尼剛聡先生から、講義をやってくれないかというお話があった。

　これだ、と思った。

　私はSunaba(注:本書で使われる独自言語)を作り、授業に臨んだ。そして知った。教えても無駄だなんて、真っ赤な嘘だ。プロになるには程遠いレベルとはいえ、プログラムとは何か、どのように頭を使えばいいか、という根本を教えることは不可能ではない。

　2011年、2012年と講義を続け、私はこのやり方に効果があると確信した。もっと多くの人に試してもらおう。しかし、やはり私の仕事は教育ではない。ゲーム作りである。本を書くくらいならできるかとも思ったが、時間が取れずにまた時が過ぎた。

申し訳ない、軽い引用にはならなかった。

「向いた人は勝手にできるようになるし、向いていない人にはいくら教えても無駄」という意見は良く聞く

確かに自分もよく聞く。

このような意見を聞くたびちょっとつらさを感じていた。

正直昼夜淀みなくコードを書けず躓いてばかりで、自分はおそらく「向いている側」ではないだろうな、とぼんやり感じていたので。

「しかし本当にそうなのだろうか、いやもしかしたら本当かもしれない」と思っていた。

勇気づけられた。

(ここに書くのは本当にまあとんでもなく恥ずかしい話だが、)事実、本業の方で数週間かかっても結局完成させられなくて放っていた機能が、本書を9割ほど読み進めた段階で再び実装に挑戦してみたところ半日で9割がた完成させることができた。

 

 

プログラミングが楽しいと思えた。

同年代の人と比べると周回遅れもいいところ...どころのレベルの話ではないけど。

とりあえず、昨日よりはましなどうしようもなくガラクタなコードを書いていきたい。

 

最後に、改めて本書を紹介してくれたizmさんに多大な感謝を。