編集部イチオシ

(ユーザ受けする)プログラミング言語の構文について考えてみた

多くのユーザに受け入れられる構文にはどのような要素が必要なのかを、だらだらと考えてみたものです(残しておくためにセルフまとめにしました)。根拠が極度に私個人の経験依存で、データの裏打ちもないのでツッコミ歓迎です。あと、駄文22から33に番号飛んでいますが、眠いせいでミスしただけです…。
25
kmizu @kmizu

おはようございます。今朝はちょっと日頃考えている構文(具象構文)というテーマについて、経験と印象(偏見ともいう)に基づいた駄文を書き連ねてみたいと思います。(続く)

2019-01-20 07:02:59
kmizu @kmizu

(駄文1)あるプログラミング言語のある構文がよしとされ、別の構文がよくないとされる。あるいは、ある書き方がよしとされ、別の書き方がよくないとされる現象について。何故、を問うのは私の知識が不足している気がしますので、関係する要因について考えてみます(続く)

2019-01-20 07:05:49
kmizu @kmizu

(駄文2)まず、最初に思うのは、どうも同じ処理をフラットな見た目に(あるいはリスト的な見た目に)書くことができる場合と、ネストした(あるいはツリー的な見た目に)書くことができる場合、どうも(私も)フラットな見た目に書くことができるのを好むようです。 (続)

2019-01-20 07:07:25
kmizu @kmizu

(駄文3)例としては、普通の手続き型言語で何故早期returnが良いイディオムとされること。ネストしたletのようなものより、フラットな変数定義の連続が好まれること。モナディックな処理をネストして(>>= などで直で書く)より do (やfor)で書くことが好まれること。 (続 )

2019-01-20 07:10:16
kmizu @kmizu

(駄文4)Scalaを例にすると、xs.flatMap{x => ys.flatMap{y => zs.flatMap{z => x + y + z }}} より for (x <- xs; y <- ys; z <- zs) yield x + y + x で後者が読みやすい(とされる)ことが多い。(続)

2019-01-20 07:13:32
kmizu @kmizu

(駄文5)これは、flatMap が陽に出てこないこともそうだけど、このような処理を書くのに木は「力が強すぎ」て、リストは「ちょうどいい」のだと思う(フラットな見た目でも実際には木にはなるけど、見た目的にリストっぽい)。 (続)

2019-01-20 07:14:55
kmizu @kmizu

(駄文6)他の話としては、(私から見て) usingやtry-with-resources で、扱うリソースを並べて書く方が、たとえばRubymでopen() do | ... | をネストさせるより読みやすく見えます。 (続)

2019-01-20 07:17:06
kmizu @kmizu

(駄文7)この辺から言えそうなこととしては、プログラミング言語の具象構文の設計者は、ある処理をフラットな見た目(UI)で書けるとき、その方法を可能であれば用意すべき、ということになろうかと思う。人間はおそらくネストが苦手なのだ。(続)

2019-01-20 07:18:50
kmizu @kmizu

(駄文8)証拠はないけど、多くのプログラミング言語が(無意識にか)この方法を採用している気がして、この仮説は割とただしそうだという実感を持っている (続)

2019-01-20 07:20:30
kmizu @kmizu

(駄文9)構文の類似性について。既存の言語、たとえばC系はシェアが圧倒的だが、それと見た目を似せるべきか。結論としては、似せることによって、印象が「とっつきやすく」なる(おそらく表面的な類似性によって親しみやすさを感じるため)ので、変にこだわらずC系に似せることには利がある。 (続)

2019-01-20 07:23:16
kmizu @kmizu

(駄文10)一方で、似せるのならできるだけ似せるのが良い。中途半端に似ているけど細部が違うとかえってわかりにくいと思われる。それくらいなら、たとえばRubyでもPythonでもだけど、C系と違う見た目を選ぶことを検討する。 (続)

2019-01-20 07:25:04
kmizu @kmizu

(駄文11)これは完全に偏見だけど、プログラミング言語関係の研究者(のしばしば)は、抽象構文(木)を考えていても、具象構文(木)が読みやすく書きやすいかは割と頓着しない人が多いように感じる。アカデミック発の言語が普及しづらいのはこのような事情があるのでは。 (続)

2019-01-20 07:27:02
kmizu @kmizu

(駄文12)ところで、C系の構文の話を書いたけど、最近は非C系、特にRubyに似せた構文が割とあるので、今はそこまでC系にこだわる(C系というのは、 {} を使うとか、制御構文の書き方についてある程度の互換性があるという意図)必要もなさそう。でも理由がなければ合わせるの良さそう。 (続)

2019-01-20 07:29:21
kmizu @kmizu

(駄文13)新しく(1900年代最後の四半世紀以降くらいの感覚)イケイケ(死語)な言語は、多くの場合、文や式の区切りであるカンマやセミコロンを、実質的にそれを担っていた改行や空白で代替させている。 (続)

2019-01-20 07:32:23
kmizu @kmizu

(駄文14)具象構文の複雑さ、という観点からすると、複雑さを明らかに増す(ほとんど自明に)ので、良くないということになりそうだが、実際には歓迎されることが多い。私も歓迎的です。 (続)

2019-01-20 07:34:18
kmizu @kmizu

(駄文15)ひとつ言えることとしては、よく普及したプログラミング言語の見た目を考えるとき、ただ構文の複雑さを避ければいいというものではないことだ。これは特にRubyやRuby-inspiredな構文の言語を見ると示唆的だ (続)

2019-01-20 07:36:15
kmizu @kmizu

(駄文16)ネストとフラットの話に戻るけど、これは根深い問題だと思っていて、S式族の言語が一定以上のシェアを得られないのは、本質的にS式がネストしているという本質的な部分を全く隠せていないから(というのもあるの)ではと感じる。 (続)

2019-01-20 07:39:50
kmizu @kmizu

(駄文17) そもそも、私達が自然言語の文章を書くとき、木としてはネストしていても、たとえばいちいち全部カッコで囲んでネストした見た目にしないわけで、そういうものかもしれない。 (続)

2019-01-20 07:41:02
kmizu @kmizu

(駄文18) Scalaに関する言説でよく耳にするのだが、別に構文が複雑であることには、(ツール設計者はともかく)普通のプログラマにとってはあまり問題がない。パーザ書く人なんてのは少数なので、複雑な部分を普段意識せずにすめばそれでいい。S式までいくと別のメリットがあるが、 (続)

2019-01-20 07:43:34
kmizu @kmizu

(駄文19)通常は、構文が複雑かどうかにこだわるのはあまり意味がない。抽象構文は単純な方がいいと考える人が多そうだけど、これもたぶん普通の人は気にしない…。 (続)

2019-01-20 07:44:50
kmizu @kmizu

(駄文20)また別の話になるが、どうも、個々の構文の役割がオーバーラップして直交していないよりは、個々の構文の役割が直交していることを好む人がいる(私とか)けど、これもたぶんどうでもいい。 (続)

2019-01-20 07:48:15
kmizu @kmizu

(駄文21)むしろ、直交してない「方がいい」(とみなされる)ことすらありそうだと思う。Golangはたぶん典型的な例。構文は(抽象構文も含めて)アドホックなくらいの方がむしろいい。 (続)

2019-01-20 07:49:47
kmizu @kmizu

(駄文22)シンタックスシュガーについて。シンタックスシュガーが山盛りの言語をあえて好む人はいないだろうけど、それでも、言語に詳しい人ほど、簡単なシンタックスシュガーについてしばしば無頓着なようにも思う。 (続)

2019-01-20 07:51:58
ぽた @PotaSmith

@kmizu 文章で説明文を書いて「わかりにくいから箇条書きにして」と言われることが多いのも同じ事なのかもしれないですね。

2019-01-20 07:52:17
kmizu @kmizu

(駄文33)簡単なシンタックスシュガーは、ごくシンプルな木の変換で書けるので、直交しない複数の構文を用意するくらいならシンタックスシュガーを用意する設計者は居そうだけど、でも、シンタックスシュガーはどうも「一般ユーザー」を混乱させがちらしいと最近思う。 (続)

2019-01-20 07:53:52