programming

このウェブサイトでの制作物でもたびたびプログラミングが必要なものが出てきている．
「デジタル射的」なんかはその最たるものだ．
また，本業でもプログラミングは利用されており，D論はプログラムが自分で書けていなければ成り立たなかっただろう．

じゃあプログラムを体系的に習ったかというと，機械科出身なため，ちらっと習っただけである．

さかのぼると中学校でFM-TOWNSでカメを動かしたような気がする．これはのちにGコード(NCコード)を操る役には立った．

大学の情報の授業は，コンピュータが古かったのと，教員の授業ノートが古かったためN88互換BASICをやった．
これはあんまり役に立たなかった気がする．．

研究室に入ってから，Visual Basic (.NETではない，6.0とかのほう)での開発を勧められたものの，

な　ん　か　嫌　い　だった

ため，拒否．ここから完全自力でプログラミング習得の道を歩むこととなった．
(研究室推奨環境を蹴るってことは，指導できるひとの不在が確定するわけで)

その後，C#で一回挫折しつつrubyで必要なコードを書くことに成功し，
高速化のためにC言語に書き直し，マルチスレッド，CUDAに手を出し，
並行して趣味のデジタル射的プロジェクトでC#も一応まあ何とかなった．
今は結果をグラフ化したりするときの都合で，pythonでコード片を書くことが多い．

言語ちゃんぽんだし，毎日コーディングする仕事ではないので，各々の言語の細かいことはすぐ忘れてしまう．
3日もたてば自分の書いたコードが何を言っているのか解読し直すところからスタートだ．
そこで現在は，コメント駆動開発みたいなことをしている．
コンピュータにやってほしいことを考えながら，コーディングに必要なことを考えるなんて贅沢な脳みその使い方できないんですよ．

まず，一番遠くから見た「これからコンピュータにやってほしいこと」を文章にする．
1行でも，数行にわたってもよい．
これが，「このアプリケーションの説明」になる．コードの先頭にコメントアウトしておこう．

次に，先にコメントアウトした「やってほしいこと」を実現するために必要なことをコメントに書いていく．
学術系のデータ処理だと「ファイルを開く」「データを並べる」「計算」「結果の表示」「結果をファイルに保存」みたいな感じになる．
これらが，このプログラムの骨格となる．
コメントアウトの記号(pythonなら，「#」)を3つか4つ「### ファイルを開く」のようにしておく．

そこからは，頭の固いコンピュータにもわかるところまで(≒コード化できる直前まで)，
徐々に細かい内容に分割しながらコメントアウトしていく．
例えば，「### ファイルを開く」なら，「## プロンプトで開きたいファイル名を入力する」と「## ファイルを読み取りモードで開く」，
「計算」なら，より詳細な処理アルゴリズムについて記述していく．
細かくなるごとにコメント記号(「## 」など)の数を減らしていくことで細かさを表現している．
Shimalithは，このとき最も細かいコメント単位に「## 」を付けることにしている．
(これは，「#」をコードのテスト用コメントアウト#print(hoge)などにとっておくため)

コメントをどこまで細かくしていくかは個人の判断による．コメント書くよりコーディングしたほうが分かりやすいと判断したなら，
コメントする必要はないが，もし調べないと書きたいコードの文法が分からないのなら，
いったんコメントでやりたいことを書いたほうがいいだろう．

また，コメントの深さについてはコメントを書くときに順を追う必要はない．
書いていて「これは細かいな」「これはもっと細かくしないとコードにならないな」という感触は
適宜コメント記号の数で表現，調節していけばよい．

コメントをあとはコードに翻訳するところまで細かくしたら(あるいは，コメントを書くのに飽きたら)，
ググってコーディングを始める．まあ本を開いてもいいのだけれど，検索性が必要なシチュエーションなので．

さて．

このやり方が成り立つには，ひとつ前提があることにお気づきだろうか．

「コードの文法を記憶している必要はないが，そういう書き方があると知っている，
または，そういう書き方が世界のどこかにあると信じるに足る状況証拠を知っている」

必要がある．
全く知らないものは調べられないし，コメントも浅いまま細かくなっていかない．

ここを解消する手段として，「書籍」を勧める．
書籍は順番に従っておおむね連続して体系的に書いてあるので，
「こういうものが世の中にある」ということを事前に確認するのにはとてもよく向いている．
webサイトの記事は断片的となることが多く，事前の勉強には向かない．
毎日使うのでなければ最終的に暗記する必要はなく，「こんなやり方があった」という目録が頭に入っていればよい，
という割り切りが，とにかくプログラミングを前に進めるためには必要．

あとは，，他と同じようなことしか書けないな．
「ノーバグでプログラムが走り切るなんて奇跡を期待するな」とか，
「コンパイラやインタプリタがエラーを吐くのは意地悪じゃなくて親切なんだからコンピュータが言いたいことに耳を傾けて利用しろ」とか，
「本当に大変なのはコードが走り切ったのに結果がおかしくなってからだ」とか，
「ハードが絡むとソフトのバグ取りが急激に困難になるから，切り離す手段を考えとこう」とか．