プログラミング言語に求めるところ

突然だが、よいプログラミング言語には何が必要だろうか。

おそらく大抵の利用者にとって、コミュニティの大きさが実際のところ最重要だと思われる。

大きなコミュニティを持つプログラミング言語には、数々の整備されたドキュメントや、先人がたいていの問題を解決した後の肥沃な土壌があるためだ。

エコシステムが機能し、毎週、毎日のレベルでライブラリの共有がなされるようなものが理想だろう。

とはいえ、これは逆説的なものよいプログラミング言語であるからこそコミュニティが発展する。 [annotation: よいプログラミング言語であるからこそコミュニティが発展する。] であり、本質ではないだろう。

実際にはセキュリティ的な堅ろうさ、アンセーフな操作への配慮、他プログラミング言語との連携など、それぞれのプログラミング言語がウリにしている「よさ」というものの方向性は遠く、絶対的なよいプログラミング言語が定められるわけでもない。

それであっても、よいプログラミング言語に共通する重要なものはある。

それは一貫性である。

これは開発に対する思想と言い換えてもよく、これがはっきりしているプログラミング言語には、その思想に共感したユーザが集まってくる。

結局のところはその思想が何であってもよい。純粋な関数以外をすべからく隔離Haskellのこと。モナド（Monad）によって副作用を持つ逐次処理を代替する。要は入出力を介した操作のような、外部や内部の環境によって不確定になりうるものを分離しておこう（可能であればなくしたい）という考え方。 [annotation: Haskellのこと。モナド（Monad）によって副作用を持つ逐次処理を代替する。要は入出力を介した操作のような、外部や内部の環境によって不確定になりうるものを分離しておこう（可能であればなくしたい）という考え方。] してもよいし、入力効率を追い求めて謎の記号を大量に導入してもAPLのこと。比較的初期のプログラミング言語であり、数学計算の最適化のために特殊な記号を多数使用する。当然、専用の入力システムを用意する必要があった。そもそも人間がまともに読めるコードではなかったそうで普及もしていない。 [annotation: APLのこと。比較的初期のプログラミング言語であり、数学計算の最適化のために特殊な記号を多数使用する。当然、専用の入力システムを用意する必要があった。そもそも人間がまともに読めるコードではなかったそうで普及もしていない。] 最悪よいのである。

今の時代であってもその根源は尽きず、あまたのプログラミング言語が考案されている。

そういったわけで、そういう思想、一貫性を持ったよいプログラミング言語（の構文）を作ろうというのが本連載の趣旨だ。

連載タイトルにもあるように、ここでいう一貫性とは美しさである。

構文の美しさとは何か

美しさといっても、これが人それぞれの極致であるのは言うまでもない。

少なくとも本連載におけるプログラミング言語構文の美しさを定義しておく必要があるだろう。

• 構文が簡潔でわかりやすいこと
• 暗黙的処理がないこと
• 最小限の要素で構成されていること
• 表記のブレが限りなく少ないこと

「構文が簡潔でわかりやすいこと」はそのままの通りである。複雑な構文を強要してしまうと、どれだけユーザがきれいなコードを記述しようとしても限界がでてくる。

多くのプログラミング言語で重要視されていることは知っての通りで、特筆するまでもないかもしれない。

「暗黙的処理がないこと」はコンパイルの段階における共通コード生成や、例外処理のような特殊なランタイムを使用する機能など、ユーザが直接干渉できない操作の禁止あるいは抑制を指す。

これは前項と真向に対立する概念であり、基本的に暗黙的処理が多ければ多いほど構文は簡潔になる。標準出力関数のみが記述されているファイルのコンパイルが通り、そのまま思い通りに動作する、といったものだ。

一見メリットしかないようにみえるが、たいていの場合、こういった暗黙的処理はそのプログラミング言語に熟達すればするほど邪魔に感じられるようになる。

とくに低レイヤーを扱うプログラミング言語においては、その暗黙的処理そのものが開発のネックになりかねない。すなわち、不都合な暗黙的処理に由来する問題を、ユーザがコンパイラ内部に干渉することなく解決できないという状況が発生しうる。

当然これは特殊な用途に限った問題であることが多い。とはいえ、製作者の都合でユーザの記述するコードに制限をかけてはいけないというのが持論だ。

「最小限の要素で構成されていること」はプログラミング言語の基礎設計の段階において、それを肥大化させてはならないという思想だ。

必要十分な要素の組み合わせによる構文は完成された美しいものであると、LISP系言語リストと呼ばれる単位の操作をベースとしたプログラミング言語とその派生群。実装が小さいことでも有名。 [annotation: リストと呼ばれる単位の操作をベースとしたプログラミング言語とその派生群。実装が小さいことでも有名。] 由来の思想がとくに浸透している。

しかしながらこれを達成することは非常に困難であり、たいていの場合、前項と前々項にも抵触する。

そのため、とくに他項との折り合わせが必要なものだといえよう。

現実的なところでは、特定の状況でのみ使用できる新規構文などを可能な限り導入しないということがあげられる。言い換えるならば、糖衣構文本来の記法をより簡略化するために定められたもの（syntax sugar）。 [annotation: 本来の記法をより簡略化するために定められたもの（syntax sugar）。] を避けるともいえる。

x += 1をx = x + 1の代用として用意してはならない、というようなことだ。

これは後項とも関わってくることだが、ある状況において、適している構文が複数ある状況というのはプログラミング言語の構造として美しくない。

どんなに軽微なものでも、ユーザにどちらの構文が優れているかという判断を迫ってしまうことになるからである。

そうしたコーディングの本筋とは関係のない判断の積み重ねは、扱いづらいプログラミング言語としてのレッテルを無意識化のうちに生み出しかねないのだ。

そういった事情があるゆえに、おそらくどんなプログラミング言語を使う環境においても（必ずしも明示的なものだとは限らないが）、コーディングガイドラインコードの記述手法を統一するための枠組みのこと。インデントの大きさのような単純なものから、名付けの法則など、これを参照しなければ追従できないようなものまで含むことがある。 [annotation: コードの記述手法を統一するための枠組みのこと。インデントの大きさのような単純なものから、名付けの法則など、これを参照しなければ追従できないようなものまで含むことがある。] というものの考案が行われる。

これはとくに複数人で同じコードを操作するときに少なからず必要なものだ。異なる認識で記述されたコードの混在は視認性に劣るだけでなく、それが原因の見落としによってバグの温床にもなりかねないのである。

しかしながら、そうしたコーディングガイドラインそのものが千差万別であり、最悪個人レベルで異なってしまうものなのだ。

ひとたび乱立してしまえば、すり合わせの工程は複雑化し、問題解決のための鍵が別の問題別のコーディングガイドラインで記述された外部ライブラリを統合する場合などに無秩序なコードを記述せざるを得ないことがある。 [annotation: 別のコーディングガイドラインで記述された外部ライブラリを統合する場合などに無秩序なコードを記述せざるを得ないことがある。] を生み出す構図となる。

そのため、コードスタイルに対する責任はプログラミング言語側が持つべきだとここでは主張しておく。

コーディングガイドラインを用意する、というよりはコーディングガイドラインが必要ない程度の明確な構文を用意したいというのが理想だ。

すなわち、「表記のブレが限りなく少ないこと」とはそういったユーザ配慮のための美しさなのである。

以上が本連載における定義だ。

これらを満たすプログラミング言語こそを真に美しいものであるとする。

特筆すべきはこれら美しさの多くが、少なさや小ささ、簡潔さに着目したものであるということだろう。

現代のプログラミング言語は多機能性が重視され、定義そのものが肥大化しやすい傾向にあると思われる。

これは悪いことだというわけではなく、正しい方向性の1つであるがゆえに、美しさと題してミニマリズムを重視する思想は差別化点としても働くのである。

名前のないこの言語

ここまで考案するプログラミング言語の方向性について述べてきたが、次回以降の連載は本格的な構文考案の記事となるだろう。

最低限その前に、本連載で扱うプログラミング言語の名称を定めておく必要がある。

完全に暫定こういう使い方における「暫定」は結局のところ、ほぼ確定に等しい（後になって名称を変更する意義が薄いため）。 [annotation: こういう使い方における「暫定」は結局のところ、ほぼ確定に等しい（後になって名称を変更する意義が薄いため）。] ではあるが、筆者の名義（およびサイトドメイン）からとって、Wyv言語（Wyv Language）としておく。

これで指示語だらけの記事が生み出され続けることは避けられただろう。

以上、Wyv言語の根底である美しさについて述べる記事であった。次回は達成目標についてを扱う予定である。