ソフトウェアの世界は、日進月歩である。
いや、その慣用句すら生ぬるい。
1日は24時間だ。Webアプリケーションフレームワークとして有名なRuby on Railsは、多い日で一日あたり12回の修正が加えられている。この単純な事実を2つ合わせると、ソフトウェアの世界は2時間進日歩と言えるくらい、変化が早い。
朝6時に早起きをして、朝食を済ませ歯を磨き、用意を整え朝8時に仕事場に向かう。その間にあなたが知っているオープンソース・ソフトウェアのどれかが進化している。2015年現在は、それぐらいの感覚を持つといい。
プログラミング言語でも類似の状況だ。Rubyは2015年8月12日に15回分のコミットがプッシュされている。
「無料なら最新版を使うのが当たり前だよね」と最新版のプログラミング言語を使うのは必ずしも最善策ではない。それは必ずしも初心者にとっての「最善」の版ではない。新しいバージョンは、ネット上に答えが記載されていないバグを含むかもしれない。
だが、ソースコードはまだいい。
問題は入門書である。
第一には、今挙げた速度の問題がある。書籍の修正スピードは、オープンソース・ソフトウェアと比べると新幹線とハイハイぐらいの差がある。2ヶ月で新版を出したとしても、先ほどのなぜか計算しやすい偶数な算出を考慮すると、その間にソフトウェアは多くて60 × 12 = 720回ぐらい修正されていることになる。仮に1ヶ月で新版を出したとしても360回である。なぜか計算しやすい。今日出版された入門書は、2ヶ月後には720コミット分くらい最新の世界からビハインドしているかもしれない。
だから端的に言って諦める必要がある。
（´ ・ω・） ＜ いやいや、いくら初心者でも、僕だって入門書で最新のことが学べるなんて思っていないよ。それくらい諦めてるさ。とりあえず、何でもいいから、きちんとした作品が一つ作れる程度のことを知りたいんだ。
（・ω・ ） ＜ いや、入門書で諦める必要があるのはむしろ、その「きちんとした作品が作れる程度のことを知る」ことだ。
（´ ・ω・）
（´ ・ω・） ＜ えっ
（´ ・ω・） ＜ そんなわけないでしょう。入門書なんだから、ゴールは「きちんとした作品を読者が作れるようにする」ことに決まってる。それを推進する方向に書かれていない入門書なんてあるわけないでしょう？
（・ω・ ） ＜ そう、そこにこそ真に残念な、ソースコード文化と書籍文化の乖離がある。
どういうことか？
書籍は一定量（あえて「かなり多くの量」と表現する）を越えた内容しか書けない。数ページで終わるプログラミングの本は存在しない。同人誌ではないから、そんなものに数百円の値段は付けられない。
プログラミング入門書にとって、むしろこの数百円に足る商用的価値を担保するという制約が致命的に学習者のゴールと相反している。
たとえば正直な話、print文一つだけでも「きちんとした作品」は作れる。
実行結果
（´ ・ω・） ＜ こ、こんなの「きちんとした作品」に入らないでしょ？
（・ω・ ） ＜ どうして？
（´ ・ω・） ＜ だってこんなの、「でーたべーす」も使ってないし、「うぇぶ」も関係してないし、要するに何のむずかしい技術も学んでないし、そもそも誰の何の役にも立たないじゃない？
（・ω・ ） ＜ むずかしい技術はあとでいくらでも加えられる。何ならやる夫のAA部分はWebから自動取得してくるようにしてもいい。単なるテキストだからね。取ってきたAAをデータベースに格納するようにしたら、それで少し使い方も勉強できるだろう。
（・ω・ ） ＜ 「役に立たない」ことはないと思うよ。友達がなにか口うるさく言ってきた時に手元でそっと実行して見せれば、意図が伝わって、いい。
（´ ・ω・） ＜ あなたの友達関係はどうやら崩壊しているみたいだけど、それはいいとして、私はWebアプリケーションとかTwitterのBotとかクールで実用的なものを作りたいの！
（・ω・ ） ＜ でも、WebアプリケーションだってTwitterのBotだって、文字を表示するだろう？
（´ ・ω・） ＜ えっ
（・ω・ ） ＜ このプログラムを完成させたあと、君がこのやる夫を二度と表示させなかったとしても、その過程で学んだ「文字列を扱う際の小問題」とその解決策はそれらの「作りたいもの」と共通だ。プログラミング初心者が取り組むべき「きちんとした作品」とは、必ずしも「作りたいもの」それ自体ではなくて、「作りたいもの」と同じ部分要素を持つより小さなプログラムのことだと僕は思うよ。
（´ ・ω・） ＜ 確かに、TwitterのBotを何も考えずに作り出すと、今回作っていた最中に遭遇したのと同じSyntaxError: Non-ASCII characterが出るわね。日本語で作るときに出るエラーね。解決策は、 # -*- coding: utf-8 -*- と書かれた一行を挿入して、文字コードをutf-8にしてあげることだと。
（・ω・ ） ＜ やる夫で直した経験を思い出せば、原因の特定も早いだろう？それこそが「経験を積む」ということだ。入門書を一字一句読むことと、print文一つでやる夫を一つ作ることは、後者の方がより直接的で、個人的には楽しいアプローチだ。
（・ω・ ） ＜ 冒頭で「早すぎる進歩」の話をした理由は、この「やる夫で使われる文字列処理の関数(replaceなど)」と「作りたい作品で使うことになる文字列処理の関数」は共通で、そして共通だということは世界でどれだけのスピードでコミットが行われていたとしても変わらないということだ。あるビジネスマンは「本質とは時代を通して不変のもののことであり、そういうものこそ学ぶ価値がある」と言っていたが、プログラミングに関してはまさにそうだ。関数名ぐらいは変わるかもしれないけどね。
（・ω・ ） ＜ 以下は僕の意見だけど、あれだけ分厚い書籍を途中で挫折せずに初心者が終えることは無理だと思う。プログラミングは何か一つ躓くと「動かなくなってしまう」。だから、書籍より小さな単位で「きちんとした作品」を作り、技術に囚われないで作品を構成するマインドを育てることが大事だと思うんだ。
（´ ・ω・） ＜ でも、こんなショボくれたプログラム書いて勉強してます、って何だか恥ずかしい…
（・ω・ ） ＜ TwitterのBot書いてても「どうせ誰かの書いたライブラリを利用してるだけだ」と卑下することは可能だし、そんなことはどうでもいい。ある哲学者の本にバスケットボールを揶揄して「あんなのは体育館の床をダムダム言わせてるだけだ」という表現があるが、それは違うだろ？僕らはショボくれたプログラムを書いてるんじゃなくて、ショボくれたプログラムの中にある、処理の世界を見て勉強しているんだ。
（・ω・ ） ＜ 自分の書いたプログラムの価値が分からなくなったら、世の中にはSL列車をターミナルに表示させるだけのslっていうプログラムが存在しており、
（・ω・ ） ＜ 凄腕のプログラマが、このslコマンドにいかにすれば音を付けてシュポシュポ走るようにできるか詳細な説明記事を上げていることを思い出すといい。
（´ ・ω・） ＜ なんという才能の無駄遣い…
（・ω・ ） ＜ それもプログラマへの賛美だ。
まとめ
- プログラミングの世界は高速に変化する
- 最善 ≠ 最新
- 入門書のサイズは、学習者のためのサイズというよりは、流通用のサイズ
- 入門書が目的とする「きちんとした作品を作れる経験と実力を付ける」を達成するには、書籍よりも遥かに小さな単位の文法事項や作品サイズで習作を作ることが重要
（書いてて、文法を縛っているタイプの入門書ももう出てきているんじゃないかな…と思い始めた）
参考にした記事
デザイナがエンジニアリング（プログラム）を学ぶコツ | fladdict
質問コーナー
AAが少しズレてない？
