QConTokyo2013 KeyNote1 プログラミング・スタイルと私たちの脳

こんにちは。

今日はQConTokyo2013に来ています。
まずは、KeyNote1 プログラミング・スタイルと私たちの脳」から。

とりあえず講演の中のメモをそのまま貼り付けたもののため、
内容的なまとまりはいまいちですし、抜けもあるとは思いますが、とりあえずとして。
後で気が向いて時間があれば整形します。
・・・と書いた時点で既に整形しない宣言しているようなものですが、お気になさらずにw

経済学を学べば学ぶほど人間は何も成就できない！
・・・なぜ？

視覚処理は非常に高度なのだが、人間は自動的に行っている。
だが、それだけでは人間は何も解消できない。
かつ、さまざまな錯覚を生んでしまう。
これをうまく利用したのが広告。

タバコ業界がもっとも長けている。
体に悪いはずの過程をよいものかのように錯覚させて、没頭させるのがタバコ。

・・・というような誤解にあふれた頭脳を用いて人間はプログラムを行っている。
そのため、人間は自動的にプログラミングをさせるという試みを行ってきた。
だが、一部しかできていない。

上記の補助を行っているのがプログラミング言語。
抽象化を進めるごとに人間の直観をコンピュータに伝えやすくなる。

だが、プログラムは完璧でなければならない。バグである。
で、その原因は人間にあるのだが、プログラムが完璧という証明はできない。
完璧という状態も判断できない。

プログラミングは理性・論理を用いて行うが、直観も利用して行っている。
情報がすべてそろってない中で進めているため、直観も含めたうえで進めている。

例としてJavaScriptを用いて説明する。
JavaScriptにはJSLintというツールがあり、静的解析が可能。
でも警告が出ると人間は傷つく。

プログラマが集うとコーディングスタイルについて論争が起きる。
しかも絶対的な正解、根拠もないため結局結論も出ないことが多い。

ただ、JavaScriptにおいては言語仕様から一定の正解が存在してくる。
たとえば、中括弧を右側に置くことで多くの問題を防止できるため、
JavaScriptにおいてはそうするべき。

人間はプログラミングのほとんどの時間をプログラムを見つめて考える時間に費やす。
すばらしい機能と講演をした後、実はそれが誤りだったこともわかる。

「ほとんどこんなことは起こらない」と考えて行ったことも、
実際のデータを持っているわけではないため直観にしたがって判断をしている。
→　言語の設計者であってもそれでミスを犯す。
ただ、実際に重要なのは最終的なエラー率を削減すること。
データを確認した上で決めるべきだった。

上記の古典的な例として、
英語はもともとすべて大文字で単語の区切りもピリオドもなかった。
結果、写本を作成した際に大量の誤記が発生した。
この問題に対応するために単語の区切り、小文字、ピリオド、カンマなどが発生した。

JavaScriptでもコンパイラのためだけでなく、人が読んだときに正しく理解できる構文を構成している。
withステートメントではプログラムを書いた際には実行するときに実際どう動作するか
確定できず、実行時にしかわからない。
これは人間の混乱を招く悪である。使うべきではない構文。

言語にある構文があり、それをより信頼性の高い構文で置き換えることができるなら、
常に置き換えるべきである。

実例として下記のようないくつかの例がある。

if (a = b) {...}は実際は

a = b;
if(a) {...} と同様だが、普通そう読めない。

プログラミングの偉大な発明としてスコープがある。
お勧めするのはすべての変数をfunctionの頭で定義すること。
それによって変数の見通しがよくなる。

グローバル変数はスコープを利用できず、使うべきではない。
使う場合は大文字で表現して明記すること。

これらのように、
「意図を伝えられるよう明瞭にプログラムを書く」
これが重要。

時間がないという人も多いが、最終的には時間をかける価値がある。
最近アジャイルが広まっているため、プログラムにはより復元性が求められる。
＃復元性＝後でほかの人が誤りなく修正可能であることを示す性質を指して話している模様

信頼性の高い文体でかかないひとには下記の傾向がある。

綺麗な文体はパフォーマンスが劣るという人もいるが、
たいていの場合、パフォーマンスにあまり差はない。
書き方の些細なことを突き詰めるよりもアルゴリズムを最適化するほうが重要。

そんな経緯もあって、プログラミングスタイルを確立する際、もっとも重視すべきは「エラー率」を削ること。
そうでないと奈落「The Abyss」でいつまでもデバッグで苦しむことになる。

JSLintはこれらの問題を検出するために開発している。
「ばらつきが発生する可能性がある」場合にも警告を出す。

JavaScriptには上記のようなばらつきが発生する構文が含まれているが、
言語設計者の立場としてはいまさらそれを取り除くことはできない。

だが、皆さんには私とは違い、「使わない」という選択肢がある。
JavaScriptのSubsetをよりよいプログラム言語として用いてほしい。

夢とガラクタの集積場