Diary?

(19:35)

今日は朝から腹の具合が悪くて炒めものなど油を使った料理を食べる気にはとてもなれなかったので、湯豆腐らしきものを食べることにした。元は「天体戦士サンレッド」9巻に載ってた鶏の挽き肉鍋で、そこに豆腐を加えただけ。作り方は

1. 鶏のももの挽き肉を練って団子にする
2. 白菜を適当な大きさに切る
3. 豆腐を適当な大きさに切る
4. 煮込む

以上。十分に火が通ったら、すりおろした玉ねぎをポン酢に加えたものにつけて食べる。

(23:36)

基本的に今の仕事で作ってるテンプレート言語やスクリプト言語などの大元の設計者は檜山さんで、俺は基本的に設計に関わるところでは強い意見を言わず、実装者の観点からの意見に留めることを心がけてる。設計に関わる人間が増えた結果どうしようもなくなってしまったプロダクトをいくつか見てきたし、ぶっちゃけ「船頭多くして船山に登る」という諺はいつだって正しい。それでも俺が設計上の観点から口出しをする部分はあって、それは不要な「省略可能」という言葉を仕様から外すことだ。

俺の経験上、「書いてもいいし書かなくてもいい」という要素は、結構な割合で問題を引き起こす。例えば C 言語のような文法の言語の場合、 if 文などのブレースが省略可能なものが多い。つまり次のようなコードが合法ということになる。

if (cond1)
  ...
else
  ...

このようなコードを書くと、後の修正で思わぬバグを入れ込むことになるというのはよく言われているが、それと同じぐらい文法を教えるときの障壁という害悪も含んでいる。

俺はとあるソフトウェアハウスに勤務していたころ、何回か新人研修の担当官を務めたことがある（言語は Java）。当然新人連中はいろんなところで躓いたのだが、先のブレースのような「省略可能」という要素はそれら躓きの一つであった。初学者というのはどうしても自分の書いたコードに自信が持てないし、自分の書いたコードの意味も把握できないから、「省略可能」という事がどういうことなのか、本当に省略していいのかわからずに悩むことがある。結局俺は「省略可能と本や Web には書いてあるが、省略するな。バグの元だ」と言って終わりにしていた。

実際には C や Java のブレースは省略可能ではなく、 if 文などはボディに一つの文を受け付けることができ、ブレースによってブロック（複文をまとめて一つの文にした物）を与えることもできるという説明の方が正しいのだろうが、それをいきなり初学者に説明して納得させるのは絶望的だ（なので「書かなくてもこういう場合は思った通りに動く」程度の説明から入らざるを得ない）。相手が本当にできる奴で、計算機科学にマジに興味があると踏んだときはこういった説明を特別にしてやったりしたが、殆どの新人はそうじゃない。こういった「書いてもいいし、書かなくてもいい」というのはまず間違いなく学習者にとっての障壁でしかない。

他の障壁としては「暗黙に定義されるシンボル」があって、例えば C++ や Java の this キーワードは殆ど悪夢に近い存在といっていい。「this はどこから来るの?」という質問に対して嘘を付かずに答えようとすると、多くの場合は相手の理解を越える説明をせざるを得なくなった。そこからさらに「何で this なしでもアクセスできるの?」まで来ると、ねえ。

実際のところどんな言語を使ったとしても初学者に教えるという行為は困難だと思うし、それは汎用言語でなくて特定目的のための DSL でも変わりはないだろうが、だからこそくだらん syntactic sugar で躓かせるような文法にはしたくない。

……そうはいっても、まったく syntactic sugar なしというのはアレで、その辺の見極めは実際に使ってもらってみないとわからんのだが。でも先に出したブレースとか this は、「書かなくてもいい」という事が問題しか引き起こしてないと思うんだがなあ。