日経バイトの記事の後半。今回は後半の3分割のうちの最初のものだが、 残りも明日以降順次公開される。 前半のときも書いたけど、正確さよりもノリを重視した文章なので、 あくまでもエンターテイメントとして読んでほしい。
mputさんから。
続く議論が「シフトが入るからストローク数は互角だよね」とか「{}はホームポジションから遠い」とか、いぜんミクロな論点に終始している感じがしてちょっと拍子抜けであります。
えー、わざわざミクロな話をしているのは、 結局「}」も「end」も大差ないことを示して、 最後の「意識のスイッチ」を強調したかったからなんだけどなあ。 伝わらないってことは、失敗だったってことだな。
実は「 Ruby では変数の接頭辞 '@' やブロック変数代入構文の '|' など、他に記号が出現する場所が多いから、ブロックの終わりは '}' ではなく 'end' のほうが、記号とアルファベットの割合がよいのだ」という反論を想定していたのですが、どうやらそういうことを考えて end が採用されてるっていうわけじゃないようですね。
Rubyがendを採用している真の理由は
というものだ。もちろん、意識のスイッチもちょっと考えたけど。
あと、カーソルの移動には
ESC C-a ruby-beginning-of-defun ESC C-e ruby-end-of-defun ESC C-p ruby-beginning-of-block ESC C-n ruby-end-of-block ESC C-f ruby-forward-sexp ESC C-b ruby-backward-sexp
などが役に立つのではないだろうか。カーソルキーでだーっと移動するよりは。
あ、よく考えて見ると、Rubyのendの良さってのは
からこそ、意識のスイッチに役立つという点にあるのであって、 あまり喧伝して他の言語がどんどんendを使うようになっては優位性がなくなるような気がするな。 みなさん、昨日書いたことは忘れてください。
で、begin/rescueやcase での brace はどのへんが美しくないかというと、 randyさんのおっしゃるように、
case val { when a ... when b ... when c ... }
または
try { ... rescue IOError ... rescue SyntaxError ... ensure ... }
のようにブレースの中で区切るのも変だし、とはいえ
case val when a { ... } when b { ... } when c { ... }
あるいは
try { ... } rescue IOError { ... } rescue SyntaxError { ... }
のように細かいブレースの連鎖になるのも気に入らなかったということです。 学生時代にOOSCに影響されてcomb styleに憧れていたのもありますが。