ここ最近マジで忙しく、 crowbarをどこまでいじったのかすら忘れてしまうほど放置してしまったので、 恒例のごまかし駄文です。
確か10年くらい前、bitとかを読んでると、 「Cではブロックを{}(中括弧)で表すが、これは目立たなくてけしからん。 ソースプログラムにとってブロックは重要な区切りなんだから、 Pascalのようにbeginやendを使い、ソースの中で黒々と目立たなければならない」 という主張を複数回見かけたような記憶があります(曖昧な記憶ですみませんが)。
が、最近の風潮としては、「中括弧の方が見やすい」という意見も多いようです。 langsmith-ml(私は参加してません。 たまにアーカイブで読んでいるだけです)ではこんな意見が出ています。
http://www.atdot.net/~ko1/w3ml/w3ml.cgi/langsmith/msg/45
ぱっとソースを見た瞬間に { から } までが
ひとつのブロックというのはすぐわかりますが（おそらく
アルファベットと記号の区別は一瞬でわかるのでしょう）、
begin .. end だとちょっと間をおかないと、どこからどこまでが
ひとつの単位なのかが把握できないです。
確かに、「黒々と目立つ」ったって、変数名などで「3文字程度の英字の並び」 なんてソース中には山のようにあるので、beginやendが特に目立つとは思えません。 Modula-2のように「予約語は大文字で書く」 ということにするとまたちょっと違うかもしれませんが。
というわけで私はどちらかといえば中括弧派(?)です。 昔、begin〜end形式のスクリプト言語をメンテしなければならないことがあって、 エディタがviしかなくて、 しかもちょくちょくインデントが腐ってて泣きたくなったというトラウマもありまして。
色づけなどエディタの支援があれば、endでもよいかもしれない、 というのはわかりますが、 endよりも1文字の記号である括弧のほうが 多くのエディタでより手厚い支援を受けられるように思います(自動インデント機能等)。
まあ見やすさに関しては、 インデントさえちゃんとしていればなんでも一緒、という話もあって、 じゃあインデントで構造を表現するPythonが最強か、という気もするんですが、 インデントで構造を表現するのはよいとして、 下がっていった階層を閉じる要素がないってのはどうなんでしょうか。 K&RスタイルのCに慣れた身としては、わかりにくそうに思うのですが。
Cなどでは、if文で中括弧を付けない書き方(ぶら下がり文)を許しているために、 以下のような形でelse if〜を並べて書くことができます。
if (a < 10) {
…
} else if (a < 20) {
…
} else if (a < 30) {
…
} else {
…
}
たまに、CやJavaにはこういう構文が特別に用意されている、 と勘違いしている人がいますけど、 別にelse ifのための専用構文があるのではなく、 elseの後ろに中括弧なしでif文が続いているだけです。
しかし、crowbarではぶら下がり文を廃止しましたので、 この形式のelse ifは書けません。 そこで導入したのがelsifなのですが、これまた言語によってちょっとずつ違っていて、 頭が痛くなってきます。
| Bシェル、Python, Cプリプロセッサ | elif |
| Perl, Ruby, MODULA-2, Ada, Eiffel | elsif |
| Visual Basic, PHP | elseif |
まあ、elseifでもよかったようにも思いますが、 crowbarは「Perlのようなもの」を目指しているはずであること、 および「私の主観による多数決」でelsifにしました。
黒須教授のUser Engineering Lecture/プログラミング言語の使いやすさより。
さらに、特に奇妙に感じたのは、制御文でelsifという綴りを使わせる点だ。 他の場合にはフルスペルを使うことが多いのに、 なぜelseifではなく"e"を省略させるのだろう。 タイプする労力を削減したつもり、とでもいいたいのだろうか。
この文章に関してはあちこちで散々ツッコミが入っていて (Content-typeの話はPerlとは関係ないってば)、 今更ではありますが、別にelsifを使う言語は珍しくないです。 上に挙げたようにPerl以外にもたくさんあります。 まあ、elsifよりelseifがよいという意見もあってよいと思いますが、 目くじら立てることかなあ、と私としては思います。
この手のネタは探せばいくらでもあって、 宗教戦争の元になったりもするものですが、 結局すべては「慣れの問題」に行き着く程度の話だろうと思っています。
もしそうだとすれば、 crowbarのようなスクリプト言語のあるべき姿を考えると、 既存のメジャー言語に似せておくというのが 結局最善の策なんじゃないかと思います。
PythonとLispの関係についてで指摘されているように、 この手のスクリプト言語を使ってくれる人 (crowbarはまだ致命的に機能が欠けているためそんなユーザーベースはないですが) は、往々にして昼間の仕事ではCやJavaやC++やC#を書き、 夜や休日にスクリプトで遊ぶのでしょう。 だったらCやJavaやC++やC#に似た言語のほうが違和感が少なくて済むのではないか。
Perlあたりは文字列操作が強力なので、 仕事でも、ちょっとしたデータ処理のために使うことはあるのですが、 やはりあの複雑怪奇な文法にはなじめません。 最近ではJavaでも正規表現が使えるのでJavaで書いてしまいます。 Perlの自然言語原理によれば、
自然言語は一度学べば、何度も使うものである。 ここから言語の設計者が学べるのは、言語は学びやすさではなく、 表現力の方に最適化されるべきだということである。 ゴルフカーの運転を学ぶのは簡単だが、それではやりたいことを表現することはできない。
とのことですが、私にとってはPerlはそう頻繁に使う言語ではありません。 言語の強力さなんて結局ライブラリに依存するんだし。
というわけでcrowbarは、CやらJavaやらといった 「主流派」の言語に似せてみたわけですが…
「似ているがちょっと違う」というのは、 「まるで違う」よりもずっとストレスがたまるんじゃないか、 という反論は可能ですし、 その反論の方が正しいんじゃないかという気もしたりして。
前の雑記 | 次の雑記 | ひとつ上のページに戻る | トップページに戻る