基礎と低レイヤーは混同しがちという現象をみかけたのでメモ
よくあるのが、「IDEを使うと基礎が勉強できない、メモ帳でコードを書いてコマンドラインでjavac / javaするところから始めるべき」みたいな話。
ツールを使わずツールが隠してる部分を自分でやって勉強せよ、フレームワークを使わずフレームワークが隠してる部分を自分でやって勉強せよ、という話は、これ自体は間違いではないのだけど、これを「基礎」と言ってしまうと違った方向に行ってしまう。
これは基礎ではなくて低レイヤーではなかろうか。
そして、低レイヤーは「ツールを使わずにやれ」と言ってる人の想定する「ツールを使わず」というのもすでにツールを使っていたりする。ほんとに低レイヤー知りたいなら、javac使わずハンドコンパイルでしょう。Javaバイトコード知っておくべきでしょう。 と、だんだんマニアックなこと知ってる自慢になっていく。 こういうのは、知っておくほうがもちろんいいんだけど、それを勉強するのはある程度わかってからでよくて、最初にやることではないと思う。
じゃあ、基礎はなんなのかというのをちょっと考えてみた。 基礎というのは、楽器演奏ならスケールだったり、絵であれば球とか立方体のデッサンだったり、プログラミングなら条件分岐とループでロジックを書くことだったり、アプリケーションつくるなら入力を受け取って加工して表示とか保存とか。
つまり、基礎というのは、単純で退屈だけどこのパターンは必ず出てくるな、というものではないかと。
そういったパターンをまとめて共通部分を抜き出して抽象化したものは、より強い基礎になる。けど難しい。
なのでまずは具体的なパターンをいくつかやってみて、なんだか共通部分があるなと気づいたくらいで抽象的に考えるという具合に勉強を進めるのがいいのだと思う。
一方で低レイヤーは、細かくてめんどくさくて裏側こうなってたのかーというやつ。
これは勉強したほうがいいのだけど、やりたいことの実現が何に支えられているかという話で、やりたいことをいかに実現するかというのとは別。
楽器演奏なら楽器の仕組みだったり絵であれば画材の特性とか人体解剖図とか、プログラミングならライブラリの実装やアセンブラやCPUとか。
基礎の勉強として、もしかしたら何にでも通用するかもしれない注意点を思いついた。
「最後までやる」ということ。
基礎の教科書を最後までやるという話ではなくて、絵であれば球を書き始めるのであれば途中で失敗したとしても書き上げる、スケールも途中で音をはずしても最後のドまでとりあえずやる、ロジックを組むなら正しい処理がわからなくてもとりあえず結果が出るところまでは組む。簡単なアプリケーションを作るならアプリケーションとして成り立つところまで作る。
サッカーで、試合形式での攻撃の練習は必ずシュートで終われみたいな話があって、それは途中でどんなにうまくパスまわしできてもシュートにつながらないなら意味がないしゴール前までボールをあげれてもシュートする人が走りこんでないならただのバクチだし、守備がうまくてパス回しをさせられたボールを蹴らされたというのがあるかもしれない、みたいな話。
これが結局いろいろ通じて、楽器のスケール練習にしても途中までうまくできるんだけど詰まるのならうまくできてないし、うまくできなくても最後まで音をつなげるというのは大事。絵で、途中で失敗したと思っても書きあげたらつじつまがあうということもある。アプリケーションで、実装が簡単なところだけ作って途中で作業が進まなくなるなら、それは完成させない前提だから簡単だっただけということもある。
まあ、なんにせよ基礎はちくちくとやっていくと100日もやればなんなりか力になるし、やっていくといいんじゃなかろうか。
